Baremetal Pascal dev. environment for RPi

[NorthGuy]

You could write tiny bare metal apps without the VCL if you chose.

I still do, without VCL or IDE. Works quite well.

[hendorog]

You could write tiny bare metal apps without the VCL if you chose.

I still do, without VCL or IDE. Works quite well.

So how do you define bloat??

Unused parts of the VCL were/are removed by the linker which is about as good as it gets.

Certainly way better than VB or Java/.NET etc, and IIRC at the time there was nothing available for C/C++ that came anywhere near the usability and productivity of the VCL.

I guess you could argue it wasn't designed optimally to ensure that nothing was accidentally linked in when it wasn't strictly required. Perfection is an honourable goal but rarely realised I guess...

[NorthGuy]

So how do you define bloat??

Unused parts of the VCL were/are removed by the linker which is about as good as it gets.

VCL was a huge library which wasn't very well thought out. It didn't really provide any benefits compared to using plain Windows API, and sometimes even made such use more difficult. The only benefit was visual design which looks great at first, but then you would notice it didn't scale well across screen resolutions and font sizes, so the benefit was dubious. However, to make VCL compliant with the visual design they added lots of stuff, which increased the amount of compiled code and slowed down execution. I don't know if they fixed all the problems later, I stopped using VCL long time ago. Of course, it still was much better than VB, not to mention Java.

The Pascal compiler which shipped with Delphi had no connection to VCL. It was very efficient, worked fast and produced very good code. I don't think FPC is nearly as good. However, anyone using Delphi would rather think of it as Visual IDE and VCL rather than a Pascal compiler.

As a language, Pascal is good. I would rate it better than C/C++, and I don't really understand why OP says it is slower than C. Unfortunately, there's no standard in Pascal and compilers are not common, so often you're stuck with C.

I think bare-bone RPi programmed with Pascal is a great idea.

[hendorog]

So how do you define bloat??

Unused parts of the VCL were/are removed by the linker which is about as good as it gets.

VCL was a huge library which wasn't very well thought out. It didn't really provide any benefits compared to using plain Windows API, and sometimes even made such use more difficult. The only benefit was visual design which looks great at first, but then you would notice it didn't scale well across screen resolutions and font sizes, so the benefit was dubious. However, to make VCL compliant with the visual design they added lots of stuff, which increased the amount of compiled code and slowed down execution. I don't know if they fixed all the problems later, I stopped using VCL long time ago. Of course, it still was much better than VB, not to mention Java.

The Pascal compiler which shipped with Delphi had no connection to VCL. It was very efficient, worked fast and produced very good code. I don't think FPC is nearly as good. However, anyone using Delphi would rather think of it as Visual IDE and VCL rather than a Pascal compiler.

As a language, Pascal is good. I would rate it better than C/C++, and I don't really understand why OP says it is slower than C. Unfortunately, there's no standard in Pascal and compilers are not common, so often you're stuck with C.

I think bare-bone RPi programmed with Pascal is a great idea.

Ah yes - the changing DPI/font sizes was an issue I remember.

I never found changing the screen resolution to be a problem, on the contrary it was very good, and compare to the many Microsoft developed apps still won't let you resize a dialog to make a tiny list box bigger. If they did let you resize then the list box would stay small.

On Delphi it was trivial to do without butchering the layout by using the anchoring system and panels.

I think you are a bit harsh on using the API directly. I can still remember the culture shock when everyone discovered that a few line C program in DOS changed to a 200 line C program in Windows With Delphi that came back to a few lines of code again - with the flexibility of using the API if you wanted to.

Remember back then the Windows API wasn't very well understood (pre widespread internet), Companies weren't very open and didn't share much information, and you needed the Programming Windows book to be able to get anywhere. Remember the secret API's that MS kept to themselves to make their software work better. 

The problem with that great compiler was that it became a weight around Borland's neck. They thought that was their golden goose - so they refused to open source it. They never made enough money from it because not enough people were using it.
Had they done so - and charged no royalties, instead charging only for the IDE - they could have increased market share, and I believe they could have survived.

[eugenenine]

200 lines?

I bought Borland C++ 4.0 for Windows (3.1) with my student discount ($129 instead of $459 or something like that).  It took my system several minutes to compile their simple hello world dialog box example and it was something like 20k lines.

[hendorog]

200 lines?

I bought Borland C++ 4.0 for Windows (3.1) with my student discount ($129 instead of $459 or something like that).  It took my system several minutes to compile their simple hello world dialog box example and it was something like 20k lines.

Haha, I was struggling to remember and didn't want to exaggerate - I do think it was about 200 or 250 lines of code minimum to display a window using Windows API only. It was far too scary for me at the time anyway, hence I abandoned Borland C++ and moved to Delphi when it came out, and I started developing for Windows. I probably would have used VB instead, but it was super expensive and I couldn't afford it.
 
The example might include a heap of extra stuff like toolbars, status bars, menus etc? Pre-compiled headers to the rescue

[hendorog]

Rather than debating the merits of historic relics the real question is: Why would someone not already familiar with Pascal choose to use it now? Not in comparison to Fortran or Cobol or BASIC or C like was the choice 40 years ago, but instead of C++ or Python or some other language they are already familiar with.

Pascal has evolved but it is marginalised and needs a compelling case made that hasn't been made. As a choice of language for baremetal programming it is not compelling and hence it is a poor choice if the goal was to excite the masses today.

You are likely correct - I doubt it will excite the masses, as pascal just isn't cool enough anymore.

Bringing it back OT though I'd say someone might be interested in this concept because it is simpler than an OS + blah blah, and therefore easier to learn/be productive with. @Vtile covered it quite well I thought.

It kinda reminds me of the old 8bit home PC's like the Amstrad/C64/BBC so it's interesting from that angle - i.e. no 'ceremony' programming...

Looking ahead, there are many apps in the world which run on an OS on a VM on hardware. Conceptually the OS could go away and the app could run on the VM directly. So from that perspective this is interesting also.

[NorthGuy]

Rather than debating the merits of historic relics the real question is: Why would someone not already familiar with Pascal choose to use it now? Not in comparison to Fortran or Cobol or BASIC or C like was the choice 40 years ago, but instead of C++ or Python or some other language they are already familiar with.

Pascal has evolved but it is marginalised and needs a compelling case made that hasn't been made. As a choice of language for baremetal programming it is not compelling and hence it is a poor choice if the goal was to excite the masses today.

Discussing relics is not such a bad idea. If you don't remember the past, how you can learn from it? For example, we have just discussed how moving from DOS to Windows made simple programs more difficult - things were easier without Windows. Similarly going bare-metal might be easier than working with OS. And, IMHO, Pascal might be a better choice for the novice than C.

Popularity is changing. And old things often get popular again. Who knows - may be Pascal is the next big thing.

[rstofer]

The thing I liked about Pascal was the compiler itself.  I had source for UCSD Pascal and the compiler followed exactly the syntax diagram for the language.  As a compiler project, it was easy to understand.  The UCSD version, like the ETF version, emitted P-code and all that was required for porting was to implement a new P-code interpreter.  This wasn't very hard.

Then UCSD decided to get out of the software business, cancelled all the outstanding licenses and turned the project over to a company that began charging for the package.  Bummer...

At one point, maybe 12 years back, I was implementing the Pascal run-time interpreter in an FPGA.  I basically built on what was documented of the P4 (ETF) compiler.  I didn't quite tumble to how to handle floating point and system routines.  Today I would just use some kind of TRAP mechanism for those routines.

[eugenenine]

Pascal started as an educational language and the rpi started out to be for the educational space so I think its a good fit.

[Vtile]

I'm honestly lost with you gents. One argues historics, one with ms OS, one argues that marketing by language choise sucs.

Make a better one yourself then, so we can start to pick it apart.

[Vtile]

Yes the overall success depents certain things, but succesfull or not the Ultibo is usefull and easy way to start with baremetal programming of RPi. It doesn't make it any lesser if this project happens to die in a few years (aka not being the next big thing). The gained skills and experience do not die and most of gained knowledge will be language indepentend. More so exposure to Wirthian languages (Ada, Pascal variants, scripting languages, industry specifics etc.) is always good, since they aren't going anywhere in a few decades.

[BradC]

There is a project to create a micro-Python bare metal environment for embedded systems. That has a greater chance of succeeding.

Except that a freepascal arm target has existed for years, and this environment exists *now*. People have been pontificating about a micro-Python or embedded python environment for years.
I've been programming in freepascal for something near  20 years now. The direct RPi port sounds kinda neat. If nothing else, users of other languages can use this as a springboard to leverage an understanding of the bare metal requirements.

Don't get me wrong, I like python. But native compiled & optimised beats out interpreted (even when the interpreted is boiled down to compiled bytecode) in my book for any embedded system.

Of course my opinion is worth what you paid for it.

[eugenenine]

I'm honestly lost with you gents. One argues historics, one with ms OS, one argues that marketing by language choise sucs.

Make a better one yourself then, so we can start to pick it apart.

Well, I know I don't come over well but mine was meant as constructive.  it looks interesting so I hate to see it die because of lack of openness.  I've used and supported open source projects for a long time and when the open part is buried deep down and the close part on the second page it tends to hurt projects.

[hendorog]

I'm honestly lost with you gents. One argues historics, one with ms OS, one argues that marketing by language choise sucs.

Make a better one yourself then, so we can start to pick it apart.

Mostly I think we were all just having a bit of a yarn about the good old days

Pontificating about stuff late into the night is the essence of engineering isn't it 

I do think its a cool project and I will probably have a play with it - still doesn't mean it will be a great popular success. It's really hard to hit a winner with something like this nowadays.
I do think the point made by @eugenenine about using them in education is a very good one.

[rstofer]

I kept reading about Ultibo and it caused me to re-evaluate Lazarus.  OK, I can get along with it...  I think it is important to open the Lazarus (Ultibo Edition) rather than Lazarus (Undocked).  Duh...

There is a metric buttload of code provided with Ultibo.  Much of it originated in the Linux world, primarily the device drivers.  Watch the USB video to see how mass storage works.  I'm not sure if/how HID works.

I watched all 6 episodes and the more I saw, the more impressed I got.  So, I reinstalled it.  There is a lot of low level capability in Ultibo.

I haven't tried the networking example (simple web page with OFF-ON buttons to control LED on Pi.  This is a simple example but it shows the scale of the code supplied.  Networking, web serving, GPIO control, etc.  I'm going to run this tomorrow.

Did I mention support for multiple CPUs?
https://ultibo.org/wiki/Architecture#Multiple_CPUs

[thermistor-guy]

...
I haven't tried the networking example (simple web page with OFF-ON buttons to control LED on Pi.  This is a simple example but it shows the scale of the code supplied.  Networking, web serving, GPIO control, etc.  I'm going to run this tomorrow.
...

I'm very interested in a bare-metal dev. system for the rpi.

My local network has a few rpi to perform various networking tasks. My (semi- but increasingly) automated test equipment setup uses rpi for running test scripts and gathering data.

So the idea of embedding the same hardware platform in custom-built test equipment, if/when needed, has a lot of appeal. The "metric buttload" of code is a plus, for getting something working quickly. I'm easy-going about exactly what block-structured imperative language the system uses - Pascal is fine.

Thanks to Vtile for starting this thread.

[brucehoult]

My opinion is not more valuable than yours.  There's nothing in what you say I disagree with. But, the key point I make relates to "20 years now". You're familiar with Pascal. I'd like to see people not already familiar with it show some enthusiasm. That's where my doubts lie.

I programmed in Pascal for most of the 80s (Apple ][ UCSD, PDP-11 NBS Pascal and OMSI Pascal, VAX Pascal, Macintosh Object Pascal). I switched to C++ in 1989 and have never gone back. Pascal vs C is a non-issue, they both do the same thing. Object Pascal is close to equivalent to Objective C (not quite). C++ is in a league of its own.

By far the biggest practical advantage the C family has over Pascal for real world work is the powerful (but horrific!) preprocessor. Which you could steal and use as an external tool with Pascal code too. "Real" Pascals have some kind of conditional compilation, but it's not as powerful.

The debate over compiled vs interpreted is a perennial Internet favorite. Yes, compiled is faster and that too in my view is a 20 year old debate. It is much easier to find a bigger device now and that makes the need to squeeze code to the max less often necessary.

More like 50 or 60 years old, and predating the internet by a long way!

Right from the start, computers have been much faster than I/O, so almost any program that is dominated by I/O could reasonably be written in an interpreted language. That includes the vast majority of business software, but not scientific.

Early computers had really awful instruction sets and very limited memory. The simple compilers they could run generated huge and bad code, and assembler often wasn't much better. Well designed bytecode was much more compact, and a program didn't have to be very big to get back the space overhead of the interpreter.

Mainframes eventually got nice instruction sets (IBM 360 is pretty good, even by modern standards), but then early minicomputers, early microprocessors after them, had really shit instruction sets. It's hard enough at first to fit in enough circuitry to make something that works at *all*. In microprocessors this was the case up to and including the Z80 and 6502.

A great example of the utility of interpreters on such crude machines is Wozniak's "Sweet16" for the Apple ][. It is implemented in 372 bytes of 6502 code in ROM and provides a 16 bit virtual machine with 16 mostly 1 byte instructions and 16 registers (stored in addresses 0x0000 - 0x001F). No other memory is needed for the interpreter.

Wozniak provides an example of Sweet16 interacting with native code:

Code: [Select]

300  B9 00 02           LDA   IN,Y     ;get a char
303  C9 CD              CMP   #"M"     ;"M" for move
305  D0 09              BNE   NOMOVE   ;No. Skip move
307  20 89 F6           JSR   SW16     ;Yes, call SWEET 16
30A  41         MLOOP   LD    @R1      ;R1 holds source
30B  52                 ST    @R2      ;R2 holds dest. addr.
30C  F3                 DCR   R3       ;Decr. length
30D  07 FB              BNZ   MLOOP    ;Loop until done
30F  00                 RTN            ;Return to 6502 mode.
310  C9 C5      NOMOVE  CMP   #"E"     ;"E" char?
312  D0 13              BEQ   EXIT     ;Yes, exit
314  C8                 INY            ;No, cont.

From 30A to 30F is 6 bytes of Sweet16 interpreted code. The rest is 6502 code. Without Sweet16 a direct translation to 6502 of the copy loop would be something like this (using the same memory locations for src, dst and len as the Sweet16 code does):

Code: [Select]

    LDY #0
L0: LDA ($02),Y
    STA ($04),Y
    INC $02
    BNE .+2
    INC $03
    INC $04
    BNE .+2
    INC $05
    LDA $06
    BNE .+2
    DEC $07
    DEC $06
    LDA $06
    ORA $07
    BNE L0

This is 32 bytes of code instead of 6 (really 9, including 3 bytes to call Sweet16). The native code runs about ten times faster than the Sweet16. This is often not important for most of the program.

(You can do better than this by keeping the low byte of length in the Y register and not actually modifying the low byte of the src and dst pointers. But not much better. The fastest solution requires self-modifying code)

Modern instruction sets allow much more compact code, with the current champions being Thumb2 and RISCV, and i386, MSP430, SuperH not that far behind. Over a whole program (not just one isolated loop), Thumb2 is about as compact as any interpreted bytecode, while running at native speed.

[legacy]

By far the biggest practical advantage the C family has over Pascal for real world work is the powerful (but horrific!) preprocessor

Since the preprocessor is not a part of the language, by definition is an external tool that does "pre"-processing, then it means that the language has a huge defects in its foundations!

Then, and now. C, C++. We are still sitting on the border of hell 

[Vtile]

Google "Free pascal preprocessor"

[legacy]

Reducing the preprocessing to something like this may be acceptable.

But people MUST understand how many disasters are caused by the abuse of cpp in C!
and don't repeat the root of mistakes on Pascal!

[brucehoult]

By far the biggest practical advantage the C family has over Pascal for real world work is the powerful (but horrific!) preprocessor

Since the preprocessor is not a part of the language, by definition is an external tool that does "pre"-processing, then it means that the language has a huge defects in its foundations!

It's not true. Go and read the ANSI C standard. One of the first things it specifies is the exact sequence of steps to be used in processing the source file, including jobs done by the preprocessor such as removing comments, inserting the contents of #include files and so forth.

The preprocessor features operate at a different level of abstraction to the parser, or even the lexer, but they are absolutely part of the C language. There has never been a C compiler that does not include preprocessing (at least since C and Unix first escaped from AT&T). I note that the BCPL manual from 1967 specifies the availability and features of the required preprocessor.

It happens that the preprocessor is often implemented as a stand-alone program in a pipeline, or that even if it is built into the C compiler it can be instructed to write out the results of pre-processing and then stop. This makes the C preprocessor usable by other languages -- including Pascal -- but doing so is not a standard thing in those languages.

[brucehoult]

Google "Free pascal preprocessor"

Many Pascal implementations provide preprocessing facilities (typically conditional compilation). Apple Pascal in the 1980s did.

However it is not standardised across compilers like C is.

[legacy]

It's not true. Go and read the ANSI C standard. One of the first things it specifies is the exact sequence of steps to be used in processing the source file

No matter if the hipster ANSI-doc tells you how you have to write #define #if #else #include blablabla

With "language" we mean language-constructs, ways to express what we need, and if you need to use an external "SED", then ... it means there is a defect in the language!

In fact CPP does the same job as SED: it replaces a pattern of text with a pattern of text with neither the intelligence nor the information to understand what it is replacing ... it's just a dummy puppet-tool, which is *THE* point, and it clearly means that the language has a defect since it is not able to express your needs without the help of an external tool!

e.g. #define constant
really which is the type? which is the range?

What The Freak is this?
the ANSI doc says it's ... a dummy pattern of text to be replaced with a dummy pattern of text

Oh, Cool!

There is information lost in the middle of them, with the consequence of disasters! Even an external LINT (which takes the source already pre-processed and it analyzes it before the compiler cc1) is a defect!
!

[brucehoult]

It's not true. Go and read the ANSI C standard. One of the first things it specifies is the exact sequence of steps to be used in processing the source file

No matter if the hipster ANSI-doc tells you how you have to write #define #if #else #include blablabla

I think you mean "yuppie". ANSI C has been around a lot longer than hipsters. And it's very un-hippie.

In fact CPP does the same job as SED: it replaces a pattern of text with a pattern of text with neither the intelligence nor the information to understand what it is replacing ... it's just a dummy puppet-tool, which is *THE* point, and it clearly means that the language has a defect since it is not able to express your needs without the help of an external tool!

e.g. #define constant
really which is the type? which is the range?

What The Freak is this?
the ANSI doc says it's ... a dummy pattern of text to be replaced with a dummy pattern of text

Oh, Cool!

There is information lost in the middle of them, with the consequence of disasters!

No one denies that the C preprocessor is like a very sharp knife -- as are many other features of C such as pointer/array equivalence, lack of bounds checking, type casts that operate at the bit representation level. You just need to take appropriate care. Which, sadly, not everyone does.