light pascal

[lucamar]

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.

[valdir.marcos]

I have written a similar program in C for uC Cortex-M0. And my point is that in Pascal I haven't even achieved half of the functionality, and I'm already exceeding 5kB Flash more than the one written in C.

With such constraints you indeed need to lay off the automated types. (though I would avoid textual I/O in microcontrollers in general)

It worries me very much
I am slowly beginning to come to the conclusion that Pascal is not suitable for writing in microcontrollers.

Pascal and C are nearly equivalent in theoretical performance. The difference is more in the amount and quality of compilers and what their optimization targets are.
Free Pascal's Object Pascal is like C++. It is high level language, but the lowlevel (in C++ case: C) still lives there.
Just like that, rock bottom Pascal is like C without macros. (iow #define only for constants).
You will need to learn to adjust the level

I have big problems writing in this language ... I do the same thing as in C, and yet I encounter Hard Fault more often than I did in C.

It could be a compiler bug, but 9 to 10 this is some mistake you made. If you are less proficient in embedded Pascal that can happen. Stay critical and try to isolate the problem. It could be as little as translating char  buff[5] into array[0..5] of char; {1 char more!}

Older and simpler Pascal implementations prior to Free Pascal would be more appropriate to beat C results in this case?

[MarkMLl]

Older and simpler Pascal implementations prior to Free Pascal would be more appropriate to beat C results in this case?

No, because Pascal has always- from day one- had up-level addressing and better handling of strings than C has.

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).

MarkMLl

[marcov]

Older and simpler Pascal implementations prior to Free Pascal would be more appropriate to beat C results in this case?

First, there is no universal "C". Some C compilers optimize for size (e.g. Keile), some not.

And no. My remark was primarily about using the optimal subsets, and only secondarily about compiler selection. If you use the wrong subset (e.g. TP4 has a string[] and goes back to 1989 or so), then you still will be bulky.

[FPK]

*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.

[MarkMLl]

*sigh* again the myth of the large binaries. An empty program for avr25 results in
...
Linking tavr
2 lines compiled, 0.0 sec, 38 bytes code, 0 bytes data

The 38 bytes come from the interrupt handlers.

No myth at all: his complaint was about ARM. Somebody else made the point that perhaps comparing with AVR would be worthwhile.

MarkMLl

[Thaddy]

No myth at all: his complaint was about ARM. Somebody else made the point that perhaps comparing with AVR would be worthwhile.

MarkMLl

ARM embedded has similar sizes. But don't expect a Raspberry Pi with a full Debian as embedded. It will have the same overhead that comes with a full OS.
That's a trap less experienced programmers always fall into,

[MarkMLl]

@Thaddy: Good point.

MarkMLl

[PascalDragon]

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.

[lucamar]

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.

Oops! You're right, of course. I mistook buff and buf

[julkas]

*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.

I think without real life project (working code) we can't make objective discussion.

[Hartmut]

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.

In FPC 3.0.4 I did not find a system.cfg in this folder, but a rtl.cfg. Do you mean this?

[julkas]

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.

In FPC 3.0.4 I did not find a system.cfg in this folder, but a rtl.cfg. Do you mean this?

Check trunk

[devport]

OKEY

Gentlemen, and perhaps Lady's, I have already partly understood the operation of the FPC compiler and this action is beginning to suit me. I wouldn't want to create an unnecessary storm here. From now on, I check 2x how the code I write affects the size of the output.
It was my inexperience with this compiler that gave rise to this topic. I apologize in advance.

[MarkMLl]

It was my inexperience with this compiler that gave rise to this topic. I apologize in advance.

Don't. Unless it really is an FAQ, raising an issue which results in core developers updating the rest of us on the state of the art is always valuable.

MarkMLl