Advantages of using PASCAL to develop embedded programs

[440bx]

I wanted to add one thing to the list that isn't only related to embedded programming but still applicable and quite a plus in my mind, that is:

compilation speed.

Depending on how you write your programs, FPC can consistently deliver sub-second build cycles.  Once you get used to that and you go to programming in C/C++ using something like Visual Studio, very quickly you honestly wonder if you live on a planet of programming masochists (which forces you to ask yourself, why am I using this thing ???.)

[marcov]

For me it doesn't matter. Simply because I have source files in the same magnitude as physical cores they are all built in one go, so instantaneously.

[440bx]

For me it doesn't matter. Simply because I have source files in the same magnitude as physical cores they are all built in one go, so instantaneously.

I'm not sure I am understanding you correctly.  Are you saying that your compiles in VS C/C++ happen instantaneously ?... if you get instantaneous builds in VS C/C++, I truly envy you.

[gasensor]

I wanted to add one thing to the list that isn't only related to embedded programming but still applicable and quite a plus in my mind, that is:

compilation speed.

Depending on how you write your programs, FPC can consistently deliver sub-second build cycles.  Once you get used to that and you go to programming in C/C++ using something like Visual Studio, very quickly you honestly wonder if you live on a planet of programming masochists (which forces you to ask yourself, why am I using this thing ???.)

Programming languages with strong data types tend to compile quickly. When processing strings, you don't need to compare whether the current character is "0" character by character.

In order to improve compilation speed, C/C++ often separates out the parts that need to be modified. That's why C/C++ projects have a lot of DLL files. I saw this method in an article written by a programmer at EA.

Of course, there is another way, which is one file per function. In this way, you don't have to recompile all the programs if you modify a few places. But this results in thousands of source files. One of the projects I'm aware of that uses this style is Azure RTOS (formerly ThreadX)

[marcov]

For me it doesn't matter. Simply because I have source files in the same magnitude as physical cores they are all built in one go, so instantaneously.

I'm not sure I am understanding you correctly.  Are you saying that your compiles in VS C/C++ happen instantaneously ?... if you get instantaneous builds in VS C/C++, I truly envy you.

This is about embedded 30kb programs (10-20kloc) in MP Lab X(a netbeans derivative) with gcc.

[AlanTheBeast]

1. It's hard to get out of bounds when accessing arrays/string.
2. The compiler is free for commercial use.
3. It is effective to avoid the macro hell of the C language.
4. It can effectively avoid the trap of local variables in C language.
5. The program is highly readable, even if it lacks comments.
6. This kind of question does not appear: j=++j + ++j;  j= what?

I find it funny that people are bashing Pascal for "small" embedded programs.

The new Arduino R4 (32b) at 48MHz, 32 KB of RAM and 256 KB of flash is a computer with nice I/O attached to it;

In the 90s - such a setup would satisfy the flight management system for a B-747-400.  And, shocker, FMS' for airliners and military use were often written in ... wait for it, Pascal.  (Ada was warming up in the wings with a few projects implemented - A lot of the B-777 and almost all of the F-22 avionics for example).

[AlanTheBeast]

I wanted to add one thing to the list that isn't only related to embedded programming but still applicable and quite a plus in my mind, that is:

compilation speed.

Depending on how you write your programs, FPC can consistently deliver sub-second build cycles. 

I use units a lot, so yes, most builds, post edit, are near instant.  Back in the 90's a moderately sized program could no longer be compiled in the Turbo-Pascal IDE, and with command line took a pretty even 60 s. to build on a 16MHz 386.  On a Celeron it took 1 or 2s.  The Ultibo version (Raspberry Pi target, no OS, runtime Lib) is not as quick though - but I think that is the Lazarus IDE more than the compiler).

When I first worked for a large company, __ the assembler __ for a 65,000 line program took about 1 hour, or 4 hours if the chain printer was converting trees to paper during the assembly.  (I wonder why we never wrote a x-assembler for the 370).

(make sure the whole thing assembles and links once before printing).

This program was spread out over 9 files on the old HP-2100.  When we moved to the HP-1000, we broke it up into about 25 files.  The 2100 was a single user OS; the -1000 multi-user - we had about 10 stations for it.  I also wrote some data reduction s/w (Fortran-77) on there that I really should have moved to the VAX when it came in. 

The HP-1000 OS failed Year 2000 (file system was date dependent on 2 digits) and we retired it.  A cross assembler was written for us by a contractor.  Good PC's could assemble that in a flash.  (Said contractor is now a mega millionaire).

[lainz]

For me it doesn't matter. Simply because I have source files in the same magnitude as physical cores they are all built in one go, so instantaneously.

Can you explain what that means, I don't get it.

[marcov]

For me it doesn't matter. Simply because I have source files in the same magnitude as physical cores they are all built in one go, so instantaneously.

Can you explain what that means, I don't get it.

Simple. A typical project has 8 source (.c) files.   I have PCs with 8 cores, the IDE launches GCC 8 times.  So the whole project builds with the speed of the slowest .c file.

[lainz]

For me it doesn't matter. Simply because I have source files in the same magnitude as physical cores they are all built in one go, so instantaneously.

Can you explain what that means, I don't get it.

Simple. A typical project has 8 source (.c) files.   I have PCs with 8 cores, the IDE launches GCC 8 times.  So the whole project builds with the speed of the slowest .c file.

Cool, thanks for the explanation.