I think it would be interesting, though, if there were some way of /completely/ disabling "Delphi-style" strings, and running FPC (with a subset of units/packages) with only "classical" Pascal strings (size predeclared, length in element - , absolute limit of 256 8-bit characters) and possibly with no compiler support for finalisation blocks and exceptions. /If/ that could be done, then it would be possible to compare against say TP5 and against various Modula-2 compilers which as I understand it had well-regarded optimisation (because the user was giving the compiler a bit more information about what he was trying to do).
You don't need
some way to disable Delphi-style strings, because if you don't use them, then the compiler and linker won't include the corresponding functionality (this is especially true for the
embedded target). Same for implicit exception frames: if you don't use managed types then the implicit frames won't be generated.
Also for the
embedded target one can explicitely decide which features should be enabled when compiling the RTL (take a look at
$fpcdir/rtl/embedded/system.cfg), thus avoiding that it's used by accident.
i get Hard Fault in line " buf^ := p^ "
Any attempt to write to 'buf ^' results in an error.
The notation something^ applies only to a pointer: it's meant to dereference it. Your buf variable, though, is an array: you should access/set it by using an index into the array, as in:
buf[x] := p^
In C it's different because an "array" is almost exactly the same as a pointer.
Take a look at the code again.
buf is an input argument of type
PChar and
p is a pointer to the local array
buff.
*sigh* again the myth of the large binaries. An empty program for avr25 results in
<fpc trunk for avr> -Wpattiny28 tavr.pp -O4
Free Pascal Compiler version 3.3.1 [2019/12/24] for avr
Copyright (c) 1993-2019 by Florian Klaempfl and others
Target OS: Embedded
Compiling tavr.pp
Assembling program
Linking tavr
2 lines compiled, 0.0 sec, 38 bytes code, 0 bytes data
The 38 bytes come from the interrupt handlers.
The point you mentioned is
empty program. But once users start to use more features that size obviously increases. So they need to monitor what they use so that they don't break any size constraints.