light pascal

[devport]

Hello,
I was wondering if it is possible to use FPC (not object-oriented) without ballast in the form of system.pas etc.? The clean program weighs over 4kB from the very beginning, which with a memory size of 32kB is a large percentage of use.

I tried to replace the system.pas files with my versions, but the compiler constantly calls some structures that it uses.

the goal is to achieve output file ~ 1kB maybe less.
in ARM

[marcov]

I assume the avr embedded targets are fairly tight ?

[MarkMLl]

I was thinking that referring to them as a template might be a good starting point.

MarkMLl

[marcov]

For the desperate there is also

https://www.muppetlabs.com/~breadbox/software/tiny/teensy.html

but there they also bypass binutils and resort to assembler directly.

[six1]

...but marcov,
his statement at the end is:
Here, at last, we have honestly gone as far as we can go. There is no getting around the fact that the 45th byte in the file, which specifies the number of entries in the program header table, needs to be non-zero, needs to be present, and needs to be in the 45th position from the start of the ELF header. We are forced to conclude that there is nothing more that can be done.

...can't belive it will be 45... it must be 42   


none insiders must read this:
https://en.wikipedia.org/wiki/Phrases_from_The_Hitchhiker%27s_Guide_to_the_Galaxy#Answer_to_the_Ultimate_Question_of_Life,_the_Universe,_and_Everything_(42)

[MarkMLl]

The King then read from his book: "Rule forty-two. _All persons more
than a mile high to leave the court_."

Non-insiders should give precedence to "Alice in Wonderland" which has been around rather longer :-)

MarkMLl

[devport]

OK, I came to some conclusions without having to get rid of system.pas files etc.

The use of STR in the program increases the size by an average of 4kB !!! (at least that's how I observe)

Using the string variable in function passing increases the result code by ~ 800B once. I must use VAR (reference) reduce the amount of generated code.

In general, I come to the conclusion that most of the optimizations should be kept on my side, not the compiler. So the compiler does as I command it.

[marcov]

Note that such growth tapers off quickly once all language string helper have been used.

Any way, it is hard to suggest anything since you don't explain what exactly you need it for.

[devport]

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.

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

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.

For example:

Code: Pascal  [Select][+][-]

1. function Int_To_Str(buf : PChar; x : smallint):word;
2. var
3.   buff : array[0..5] of char;
4.   p : PChar;
5.   size : longint;
6.  value : smallint;
7. begin
8.   Result := 0;
9.   p := @buff;
10.   value := x;
11.   size := longint(buf);
12.  
13.   if(value < 0) then begin
14.     buf^ := '-';
15.     Inc(buf);
16.     value := -value;
17.   end;
18.  
19.   if(value = 0) then begin
20.     buf^ := '0';
21.     Inc(buf);
22.     exit;
23.   end;
24.  
25.   while(value > 0) do begin
26.     p^ := char(value mod 10 + Ord('0'));
27.     value := value div 10;
28.     inc(p);
29.   end;
30.  
31.   while p <> @buff do begin
32.     dec(p);
33.     buf^ := p^;
34.     inc(buf);
35.   end;
36.  
37.   size := longint(buf)- size;
38.   Result := word(size);
39. end;

If Call where

Code: Pascal  [Select][+][-]

1. var
2. st : string;
3. begin
4.  Int_To_Str(@st, 20);  
5. end.

i get Hard Fault in line " buf^ := p^ "
Any attempt to write to 'buf ^' results in an error.
In C compiller this function it works.

STR I don't want to use because it weighs a lot :/ and requires heapmgr.pas (more kB)

[MiR]

I think you are on the right track now, if you really want to bring down code size you have to check your every move and it's costs.

Strings are very expensive both as ansistrings (possible for e.g. arm, mips targets), there you will in most cases need to add heapmgr (Hint! Hint!) to make them properly work and the code for handling them is quite complex (--> big)
and also as shortstrings (avr) where they consume 256 bytes of precious ram on your stack for every function call that uses strings. Take a look at a function that concats two strings and returns the result, and while doing that say goodbye to 768 bytes of precious stack....

Also, for example using classes also increases code size, they need heapmgr and precious RAM is also used by VMT's when virtual methods are used.

The list goes on, when you want to keep codesize down you need to always check the generated assembler code and prepare for surprises  

The question I always ask myself is WHY people today choose severely cpu and memory limited chips for freepascal...

I can understand it from the educational aspect, you learn a lot when trying to squeeze complex code into 32kb of Flash, but how many of the people using such a small system actually want to go through this learning curve?

There are quite capable and cheap boards out there in the sub-10$ range that offer 64-128kb of flash (look for STM32F103C8T6 or maple mini) and come with a stlinkv2 compatible debugger, there are even more capable boards with STM32F4 Chips (search for STM32F411CEU6) with 128kb RAM and 512kb Flash or ATSAMD21 Boards like Arduino-Zero or clones.

Thoses Chipsets eat through most of the limitations that come with todays freepascal, they have enough flash for some not so optimized code and they have enough CPU power to easily execute the complex string methods in freepascal.

Please do not misunderstand me, I like the smell of freshly generated assembler output of fpc, but I ask myself does everybody want to start that hard?

One could argue that AVR chips and older Arm Chips are easier to understand because of less complexity, but is this really true?
Me, I do not think so, you can also start simple with newer arm or mips chips, but there's a lot more (like DMA, advanced timers) that comes in handy once you have mastered the basics and start with the more challenging stuff.
But until that point you have already had a lot of fun with blinking LED's, OLED-Displays or whatever without hitting the out of RAM/Flash-Memory wall even once.

Michael

[marcov]

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!}

[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!}

Could PicPas example help this discussion?
PicPas, Pascal compiler for Microchip PIC
https://forum.lazarus.freepascal.org/index.php/topic,36595.0.html
https://github.com/t-edson/PicPas

[devport]

However, I will not give up without a fight yet. : P
I will learn the behavior of the Pascal compiler and correct my code first.

[devport]

PicPas, For me, this is a good approach to programming microcontrollers. I thought about it myself in the context of ARM Cortex

[MarkMLl]

To be honest, I don't think it's fair comparing Pascal against C on account of the implicit complexity (support for finally blocks etc.) that Pascal carries around even if strings etc. aren't used.

It's only marginally fair to compare Pascal against C++ (with managed strings support) on account of the flexibility that C/C++ have to recompile stuff rather than making do with precompiled "one size fits all" units.

MarkMLl