User avatar
Gavinmc42
Posts: 2130
Joined: Wed Aug 28, 2013 3:31 am

Re: A Extended Pascal Implementation : CONCEPT.

Fri Apr 20, 2018 1:04 pm

First it compiles itself using the existing compiler on the machine.
Then it does it all again using the new freshly built compiler.
This 1) tests the newly built compiler, and 2) ensures the new compiler is as fast as possible because it is built with the latest code generation.
Add some AI and more recursion and watch it turn into a quantum blackhole or melt your Pi.

Wonder who will write the first and last self-improving compiler?
I'm dancing on Rainbows.
Raspberries are not Apples or Oranges

ejolson
Posts: 2017
Joined: Tue Mar 18, 2014 11:47 am

Re: A Extended Pascal Implementation : CONCEPT.

Sat Apr 21, 2018 10:25 pm

jahboater wrote:
Fri Apr 20, 2018 12:47 pm
When you install gcc, the build is done twice.
First it compiles itself using the existing compiler on the machine.
Then it does it all again using the new freshly built compiler.
This 1) tests the newly built compiler, and 2) ensures the new compiler is as fast as possible because it is built with the latest code generation.
With gcc it is a three stage process where the third stage is to compile the compiler again using the compiler compiled by the compiler compiled by the original compiler to obtain a compiler compiled by the compiler compiled by the compiler compiled by the original compiler.

In the context of making something simple and fun to use for the Raspberry Pi, an interesting compiler to look at might be the Commodore C64 version of G-Pascal. This language was designed for writing games and has built-in support for hardware based 2D graphics and sound. Source written in 6502 assembler is now available. It would be interesting if the P-code VM could be adapted to Raspberry Pi in a way that preserved the built-in graphics and sound. If so, the resulting programming environment might be more appealing to some children than Scratch for making games. It would definitely allow for an easier transition to general purpose programming languages later.

User avatar
Gavinmc42
Posts: 2130
Joined: Wed Aug 28, 2013 3:31 am

Re: A Extended Pascal Implementation : CONCEPT.

Sun Apr 22, 2018 12:10 am

Wow ejolson, thanks for that blast from the past.
I remember those Byte Mag Tiny Pascal articles mainly because I think they were the first Asian named coders I had seen in Byte Mag.
Still got them in a box under the house ;)

G-Pascal with 2D hardware support, sounds very useful.
G_PascalScript for Ultibo?
I'm dancing on Rainbows.
Raspberries are not Apples or Oranges

jahboater
Posts: 3030
Joined: Wed Feb 04, 2015 6:38 pm

Re: A Extended Pascal Implementation : CONCEPT.

Sun Apr 22, 2018 6:54 am

ejolson wrote:
Sat Apr 21, 2018 10:25 pm
With gcc it is a three stage process where the third stage is to compile the compiler again using the compiler compiled by the compiler compiled by the original compiler to obtain a compiler compiled by the compiler compiled by the compiler compiled by the original compiler.
:) :) :)
At least on the new Pi3B+ all that only takes about 4.5 hours.....

ejolson
Posts: 2017
Joined: Tue Mar 18, 2014 11:47 am

Re: A Extended Pascal Implementation : CONCEPT.

Wed May 16, 2018 8:04 am

DavidS wrote:
Fri Apr 13, 2018 4:12 pm
It is looking like I may get far enough to begin sharing soon.
Any news or updates on progress?

Rainier Lamers
Posts: 10
Joined: Fri Jun 01, 2018 10:46 am

Re: A Extended Pascal Implementation : CONCEPT.

Tue Jun 05, 2018 12:23 pm

Just for interest sake, have a look at www.MGLAvionics.co.za or Google "MGL Avionics". You will find a whole host of aviation stuff from small little instruments like altimeters right up to full blown flight deck panels loaded with everything that opens and shuts - like 3D terrain lookahead, navigation in all its complex forms, autopilots, engine monitoring and so forth. Even air traffic communications radios.
Now you may be surprised to learn that all of that is programmed in Pascal. Right down to and including any operating systems.
It's exactly the "light weight" Pascal compiler you are talking about - it has zero "built in" functionality. Your application starts with a couple of lines of assembler text to get things going. It has been used from old Atmel ARM7 STM32 right up to ARM9 and then onto the various ARM cortex flavors (not 64 bit yet).
All this stuff is as embedded as it gets - and Pascal does it just fine.

Now Ultibo is very similar to the compiler I am using (which I wrote myself of course - you're in good company). Don't for one moment assume there is some big bunch of "mini-Linux" between you and the hardware. Your source gets translated into object files you can link anyway you like - it's just the normal GNU toolchain underneath. You don't have to use anything Ultibo provides for you (i.e. the RTL). There is no kernel and no virtual memory (but you can play with the page translation tables to your hearts content).

The reason Pascal was chosen for our avionics projects is its lack of a preprocessor and the "unit" system which does away with headers. The language is readable - in fact very close to the pseudo "pascal like" language often used to document software and algorithms. This tends to aid programming as its kind of "self documenting" without you having to spend an extra effort. Lastly - it is very close to the Ada language (which is based on Pascal) which is favored in much of the aviation World when you need to certify your software.

User avatar
Gavinmc42
Posts: 2130
Joined: Wed Aug 28, 2013 3:31 am

Re: A Extended Pascal Implementation : CONCEPT.

Wed Jun 06, 2018 3:39 am

That MGL stuff is cool, last time I went up in a Cessna it was still analog dial gauges ;)

Got maybe some CAN bus automotive stuff to be down in the next year or so.
Nice to know Pascal is being used for instruments ;)
This tends to aid programming as its kind of "self documenting"
Yep I hate documenting, Pascal seems to be readable unless it gets too object like and obscure ;)

So many 64bit cpu's now, time to upgrade?
I'm dancing on Rainbows.
Raspberries are not Apples or Oranges

Rainier Lamers
Posts: 10
Joined: Fri Jun 01, 2018 10:46 am

Re: A Extended Pascal Implementation : CONCEPT.

Wed Jun 06, 2018 8:15 am

well, right now there is absolutely no need to upgrade to 64 bit for us.
You see, this is bare metal programming. There is no unwieldy operating system that gets in the way.
The result of this is blazingly fast execution of the application - since there is only one application running on the CPU I do not even bother with preemptive mutitasking - cooperative is just fine and far safer (no variable sharing issues). Far faster too - the CPU gets to use its cache memories in the most efficient way possible and there is no task switching overhead at all.
Since I am not using any third party code (not even device drivers) I get to do all the fun bits like squeezing the bejeezes out of an SD card interface for example and can optimize the heck out of the file system - so for example with a 50Mhz clock I do get very close to 25MB/s data transfer rates (sustained on large files during read - as you would expect to get with a 4-bit SD card bus).
The only drawback so far is that CPU manufacturers do not like to document their GPUs so although my higher end chips have nice GPUs on them I cannot use them. Much of the graphics heavy lifting I thus have to do with the NEON engine - which is not bad really and quite fun to use.
That brought me to look at the Pi - the CM3 module in particular. Ultibo has managed to get OpenGL on the GPU working on a bare bones platform. That is fantastic. Sadly it is overshadowed by Broadcoms dislike of telling developers what they need to know. I can use the CM3 for the next level of product upgrades (but will need to add a coprocessor to do much of the hardware interfacing - the CM3 is a bit thin on the peripheral side - in particular as I need to use the parallel TTL display).
So right now I am conflicted - I like the CM3 (and Ultibo) but am wary of getting stuck on something (like interfacing PAL cameras which is a must on our systems). I am playing with the Pi and the CM3 at the moment but am doing the same with the iMX8 and iMX6 (more expensive but at least they are properly documented). On these chips crafty hackers have reverse engineered the GPU successfully.
Will have to decide between these options. Tricky one...

User avatar
Gavinmc42
Posts: 2130
Joined: Wed Aug 28, 2013 3:31 am

Re: A Extended Pascal Implementation : CONCEPT.

Wed Jun 06, 2018 1:02 pm

but am doing the same with the iMX8 and iMX6 (more expensive but at least they are properly documented)
Yep I'm keeping my eye on those chips too, especially any A35 based ones for lower power apps.

Embedded FPC is getting along but limited to a few chips.
I only have so much free time to learn all this stuff :oops:

I am hoping Pi4 might be a bit more open, Eric Anholt is finding his way around the Videocore issues.
But Vulkan is where the future lies I think for Graphics.
I want to use Aarch64 to the max so I can make best use of the NEON.

Gentoo64 is helping some, Sakaki showed me how to compile ARM's Compute Library ;)
viewtopic.php?f=54&t=188448

The good thing with Pi's is there are so many people using them.
The bad thing is knowing there is so much stuff in them that you have no clue how to use.
I have yet to use any CM's.

I think there may be a video to CSI chip around?
That might do your cameras.
There is also the SMI based 6800/8080 LCD interface mode, faster than SPI, less pin hungry than DPI.
But nearly undocumented, at least on Pi's :( Arduino has better docs for this mode ;)
I'm dancing on Rainbows.
Raspberries are not Apples or Oranges

Rainier Lamers
Posts: 10
Joined: Fri Jun 01, 2018 10:46 am

Re: A Extended Pascal Implementation : CONCEPT.

Wed Jun 06, 2018 3:00 pm

Yes not problem with converting PAL, NTSC or whatever into CSI-2 data streams. ADV7282-M is perhaps the favorite chip here. It appears to be supported in Raspiraw.
Using the parallel memory bus is out of the question - I need to use the DPI for TTL displays so not much left on usable I/O after that.
Yes - it is possible to convert the HDMI out to TTL (another chip - what would we do without Analog Devices ?...).
I have been spending (far too much) time giving Google a hard time finding anything to do with the Pi and the ADV7282-M. Bits here are there and the Raspiraw source gives some clues. Still don't quite get how to turn RaspiRaw output into usable images. Perhaps it is a matter of just translating a YUV buffer to RGB using the ARM (and NEON) straight into the frame buffer. Some docs would be nice...

BTW I think the NEON can be used in 32 bit mode on the ARMv8 (unless I am mistaken). The NEON is a good engine for some graphics work like blending etc. I use it extensively to draw triangles with texture mapping and color gradients etc for showing 3D landscapes, runways etc. Doing that using only the ARM core is perhaps slower by a factor or 5 to 10.

jahboater
Posts: 3030
Joined: Wed Feb 04, 2015 6:38 pm

Re: A Extended Pascal Implementation : CONCEPT.

Wed Jun 06, 2018 3:12 pm

Rainier Lamers wrote:
Wed Jun 06, 2018 3:00 pm
BTW I think the NEON can be used in 32 bit mode on the ARMv8 (unless I am mistaken).
Yes you can use it in 32-bit mode.
There are less registers and the register layout is weird, but otherwise it works fine.
It also can do some 64-bit integer arithmetic (the compiler hands over more difficult int64_t operations to NEON).

User avatar
Gavinmc42
Posts: 2130
Joined: Wed Aug 28, 2013 3:31 am

Re: A Extended Pascal Implementation : CONCEPT.

Thu Jun 07, 2018 1:02 am

Using the parallel memory bus is out of the question - I need to use the DPI for TTL displays so not much left on usable I/O after that.
I use Zero's in USB boot for graphics code testing.
Use one of these and you have 4 Zero's, no HDMI access, but GPIO is on the top ;)
https://clusterhat.com/

You could use a Zero just for display driving, $5 is hard to beat for that sort of cpu/gpu power.

If I have 64bit cpu's I want to use them in 64bit mode, fine is ok but I want better ;) .
Aarch32 code will run on Aarch64.
viewtopic.php?f=54&t=211260

Anyway it is nice to know Pascal is not dead and is still "secretly" being used.
Is it because it is a European invented language the USA does not use it as much?
A NIH syndrome?
I'm dancing on Rainbows.
Raspberries are not Apples or Oranges

Rainier Lamers
Posts: 10
Joined: Fri Jun 01, 2018 10:46 am

Re: A Extended Pascal Implementation : CONCEPT.

Thu Jun 07, 2018 8:25 am

No Pascal is anything but dead and living a productive life "in the shadows".
Borland was a U.S. company - they are the ones that came up with Turbo Pascal which was arguably a huge success (while Microsoft's own Pascal flopped). But Borland had no chance against MS and their efforts to diversify (Think Borland Office) where doomed.
The World went "C" - in part this was because there where no suitable Pascal compilers that could be used cross platform and at lowest possible level. That was not a language problem but rather an implementation issue.
I still use Delphi for all of my desktop development - there is nothing that beats it. Period.
Embarcadero is now in charge of Delphi and although they managed to get me to buy two of their editions I don't use them. Very expensive so I think they are doomed long term.
Lazarus however is now getting my attention. I have been looking at it on and off for a few years but it seems there is a level of maturity creeping in now that is respectable.
Look, I do not get involved in "C" vs "Pascal" discussions - it's pointless. I started writing compilers and the first one I wrote was a "C" compiler derived from "small C". Remember it ? Pascal only started later as I had a need to reuse a lot of Pascal code and it was easier to write a Pascal compiler than to translate it (don't ask - it was a weird setup at the time). I first wrote one for the Z80 (and Z180), followed by 8052 and then the AVR. These where sold as fairly cheap shareware in the 90's and it was quite successful. However then I bought an old microlight aircraft with no instruments and had to make my own (well I did not have to but that's the way I do things). What followed was a new company that produces and manufactures a wide range of aircraft avionics and for that I continued developing my Pascal compiler for the ARM which is in heavy use today for our products. I never released it (I just don't have the time to support it) and now I do not want to - there is no need. All efforts should go towards the free Pascal compiler fpc.

There are many good arguments in favor of "C". There are equally good arguments in favor of Pascal. Interestingly - most of these arguments do not overlap which means there are flaws in both approaches. There are actually too many languages around now. For no real good reason.

As an aside - about 10 years ago we made a VHF airband communications radio called the V10. It used an ARM7 processor from Atmel. It was programmed in Pascal AND C. Yes - both languages in the same compiler used at the same time for a small embedded application. They work well together since they are very similar in fundamental structure. So it does not have to be one or the other. Ultibo is pretty close to that - it can easily link to object files and libraries done in "C" - just that the IDE can't handle the "C" sources and invoke the correct toolchain - that could be added...

jahboater
Posts: 3030
Joined: Wed Feb 04, 2015 6:38 pm

Re: A Extended Pascal Implementation : CONCEPT.

Thu Jun 07, 2018 8:33 am

Very interesting.
I learned Pascal at uni nearly 40 years ago. Then it was a nice language but had some awful flaws - such as the fact that a string of length 10 characters was a different and incompatible type to a string with 20 characters. I am sure that sort of nonsense is fixed now.
Pascal was designed as a teaching language at which it excelled.
Later I found C to be less "elegant" in some respects, but generally much more "capable" in the real world.

Rainier Lamers
Posts: 10
Joined: Fri Jun 01, 2018 10:46 am

Re: A Extended Pascal Implementation : CONCEPT.

Thu Jun 07, 2018 8:38 am

On the Pi Zeros - I read it's "one per customer".
That not true ?

Yes, $5 is hard to beat.

I have to be careful what I do - it is easy to get carried away but I must be mindful of producing a producible product that is as reliable as it gets.

My aim for the next generation of our EFIS systems is to make them "open source" - one additional reason why the Raspberry is of interest. While our systems are already very seriously user configurable I promised these would be open source when I started. Since the base code has now reached a good level of stability it is time to open it. But it needs suitable hardware - right now everything is custom designed.

Rainier Lamers
Posts: 10
Joined: Fri Jun 01, 2018 10:46 am

Re: A Extended Pascal Implementation : CONCEPT.

Thu Jun 07, 2018 9:02 am

Pascal strings ?
Well - no issue there. This is one aspect where Pascal is much better. Pascal (with all its various string types) stores the length of the string with the string. When you write compilers you will realize just what a bonus that is - C is forced to scan for the end character of a string it is working with for just about any string operation as it needs to know the length. This makes Pascal much faster here.
Also - it means you can put anything you like in a string. It does not have to be text. Look at it rather as as flexible length data container with benefits.
There are other little differences where Pascal scores - sometimes unintentionally. C is bogged down somewhat by standard calling conventions which force the caller to do work that is done in the callee in Pascal. Forced savings of registers takes time. Pascal is perhaps better when it comes to passing parameters - however that makes the compiler more complex while the C compiler is very simply in this regard. That unfortunately means that the "C" programmer is forced to work with pointers a lot since you cannot pass anything above a certain small size as argument. Every programmer has a story to tell about the "incorrect" pointer. Pointer bugs can be incredibly hard to find. In contrast, in Pascal if you work with a pointer - you know you work with a pointer and you only do that in cases where you need to. It helps. A lot.
There are many stories going around that Pascal cannot do what C can do - mostly related to pointers. Of course that is rubbish. You can do anything you like.
I don't like official Pascals restrictions on pointer arithmetic forcing you to do big type casts or cheats. My compiler (as you would guess) allows you unrestricted pointer arithmetic. So you can write:

var
p: ^byte; //Pointer to a byte
b: Byte; //a byte variable;
begin
p:[email protected]; //Set pointer to the address of something
p:=p+100; //add 100 to the pointer
b:=p^; //Get the byte pointed to by p into b;
end;

Even a non programmer can follow that I should think. Also, when it comes to the ability to hang yourself using pointers - you can do that perfectly well in Pascal too.

jahboater
Posts: 3030
Joined: Wed Feb 04, 2015 6:38 pm

Re: A Extended Pascal Implementation : CONCEPT.

Thu Jun 07, 2018 9:21 am

Rainier Lamers wrote:
Thu Jun 07, 2018 9:02 am
Pascal strings ?
I wasn't complaining about Pascal's string implementation - there are benefits to both methods. I was complaining that two strings of different lengths were considered different and incompatible types - I hope that is no longer true - otherwise the language is unusable IMHO :)
There are other little differences where Pascal scores - sometimes unintentionally. C is bogged down somewhat by standard calling conventions which force the caller to do work that is done in the callee in Pascal. Forced savings of registers takes time.
Thats nothing to do with C, it is the ABI for the platform. C just follows the ABI for obvious reasons (at least it does on Linux, on Windows you probably have a choice). A surprising number of functions in C get inlined nowadays which removes the problem.
That unfortunately means that the "C" programmer is forced to work with pointers a lot since you cannot pass anything above a certain small size as argument.
Yes thats true - for the usual efficiency reasons.
In contrast, in Pascal if you work with a pointer - you know you work with a pointer and you only do that in cases where you need to.
Yes indeed, but that is true of C too. Long long ago people stopped storing pointers in integers and other such nonsense!!

C has evolved at lot over the years, Pascal likely has too but I have not been following its standard's.

User avatar
Gavinmc42
Posts: 2130
Joined: Wed Aug 28, 2013 3:31 am

Re: A Extended Pascal Implementation : CONCEPT.

Thu Jun 07, 2018 11:10 am

When Pi's first came out, it was geez I cannot make my hardware for that price.
Now I just make simple PCBs that plug onto Pi's, if it is tricky then I add a PSoC mcu, which I do program in C ;)

But Pi's came with Linux, ugg, that was painful to learn, so many languages, so many choices, so many dependencies, so much bloat :shock:
After learning a dozen or so languages I ended up using shell script/SED/AWK to do my simple single purpose application running on PiCore OS.
C, Python, Pascal who really cares? Me :lol: C and Python needs extra libs to do anything useful.
Pascal has all that nice multi dimension arrays I one day want to use for ML/CV.

Extending Pascal for Machine learning should not be too hard?
CPU/GPU/QPUs 1GHz, 512Mb memory running Ultibo, I'm spoilt.

One day Ultibo could do iM6/8 or any ARM cpu like Cortex M0/3/4/7 or even MIPS as FPC can compile just about anywhere now.
It is a little bit like Arduino, restricted to a few CPU's, but can still do lots and much quicker than baremetal C.
FPC really is RAD, things that used to take months in C can be done in days, days are now only hours, fixes are a few minutes :D
Compile the Buildroot Linux Kernel with the missing driver you need, compile overnight, you are lucky if you get it right first time :o

Pointers are a pain in C, spent too much time debugging those issues over decades, one reason I use PSoC's, I most do application layers, PSoC's it is drag and drop programming.
.
Ultibo/FPC usually just works because I am mostly just writing the application layer, lower level stuff is written by better coders than me.
I use lots of i2c sensors, they just work in Ultibo, I have yet to find a method on Linux that is more reliable, in fact I gave up.

I wrote some shell extensions that was similar to the i2cdetect stuff in Linux,
That is pretty much like writing Linux drivers which I have no clue how to do.
https://ultibo.org/forum/viewtopic.php? ... etect#p651

Zero and Zero W 's are still $5/10 for one only, Zero WH's are not restricted but you get the WiFi/BT chip and header for much more $$
Nothing too unreliable about Pi's except the early A/B's and the 3B/3B+ (jury still out for 3B+)
CM's would be much better options.

Turbo Pascal was great but then that whole Delphi/database thing lost the plot for decades and cost $$$$.

I still need to get/find/make an Aarch64 FPC bootstrap compiler, so I can spend some time in Aarch64 land, messing about with CV/ML etc.
Then it is 64bit baremetal time. I don't NEED it now but I want to learn it before I need it :D
Doing Aarch64 in QEMU is not quite the same thing
https://ultibo.org/forum/viewtopic.php? ... ch64#p2634

In theory Ultibo should link to any library, not just C ones.
But there is still lots of Delphi/FPC libs that just work too, Fcl-image just worked for me, never used it before either.
Many others "limited testing" https://ultibo.org/wiki/Current_Status

Imagine Zero's with cameras and smarts, processing video before sending it to a Pi3.
More Zero's doing the displays, complete Flightsim running on Pi's.

This took me a few hours to mock up, mainly to learn OpenVG in real use case.
https://ultibo.org/forum/viewtopic.php? ... =PFD#p5409
https://github.com/Gavinmc42/PFD
I had first thought of Pi's for flight sims in 2012? I had no idea about how to code them back then.
$2 million the Uni just paid for a new one :shock:

Still need to understand the VC4 layer stuff and do some OpenGLES.
But if I can do this stuff any good coder can and a Pascal coder will write circles around me :oops:
Pi's with Pascal are doing what I want to do, nearly stress free too :lol:
This method should keep me busy for the next decade or so, not even close to this combo's limits.

Baremetal OpenGLES gaming/displays?
I think I can now see daylight at the end of the tunnel.
viewtopic.php?f=68&t=214695

Have not even talked about IoT stuff where I spend some of my time.
https://ultibo.org/forum/viewtopic.php? ... t=i2c#p367

Some stuff I posted 1-2 years ago were just possibilities.
Need to reread my old posts and make a list of what can now be done and not wished for. back then
I'm dancing on Rainbows.
Raspberries are not Apples or Oranges

Rainier Lamers
Posts: 10
Joined: Fri Jun 01, 2018 10:46 am

Re: A Extended Pascal Implementation : CONCEPT.

Thu Jun 07, 2018 12:44 pm

As they say: Amen to that brother !

Yes - I can see Ultibo becoming the embedded development system for many applications. By effectively incorporating a compatible "C" library to keep imports done in "C" happy one of the major drawbacks of Pascal (lack of sources for many interesting things) is mostly negated.
One can argue that Ultibo is "just another operating system" and in some ways it certainly is - a very, very lightweight one. Nothing wrong with that - after all - it gets everything going rather quickly after boot so you don't have to muck about with it - imposes a few things in return (you will have to follow a few rules to not break it, but not too bad). After that - the CPU(s) are (mostly) yours - you can crash the system to your hearts content any which way you like. Good ! Freedom !
Looking at the various examples Ultibo provides is enlightening. It has come a long way in a very short time. It is actually brilliant.

Rainier Lamers
Posts: 10
Joined: Fri Jun 01, 2018 10:46 am

Re: A Extended Pascal Implementation : CONCEPT.

Thu Jun 07, 2018 12:53 pm

PEX under Ultibo ?

Consider myself stunned. Wow !

hippy
Posts: 3893
Joined: Fri Sep 09, 2011 10:34 pm
Location: UK

Re: A Extended Pascal Implementation : CONCEPT.

Thu Jun 07, 2018 3:58 pm

Gavinmc42 wrote:
Thu Jun 07, 2018 11:10 am
C, Python, Pascal who really cares? Me :lol: C and Python needs extra libs to do anything useful.
I don't see how Pascal is any different to C or Python in that respect. I am not sure what one would want which could only be provided for by a library in C or Python which is a part of Pascal itself.

I'm not convinced that having to, or choosing to, use libraries is a fundamental problem anyway.

User avatar
Gavinmc42
Posts: 2130
Joined: Wed Aug 28, 2013 3:31 am

Re: A Extended Pascal Implementation : CONCEPT.

Fri Jun 08, 2018 1:09 am

I don't see how Pascal is any different to C or Python in that respect
Me neither, I could have used C or Python as I know them better than Pascal.
But Ultibo Pascal was the first usable baremetal dev tool for Pi's, at least one that I understood and can use at my skill level.

My problem with libraries and dependence is I develop behind a Uni firewall, so these are extremely hard to use.
Don't even talk Cloud based tools, the network guys look blank at me :(
With Ultibo/Laz/FPC/Delphi it all comes in one box, so to speak.
I'm dancing on Rainbows.
Raspberries are not Apples or Oranges

Rainier Lamers
Posts: 10
Joined: Fri Jun 01, 2018 10:46 am

Re: A Extended Pascal Implementation : CONCEPT.

Fri Jun 08, 2018 8:25 am

On the face of it -the languages are not really different.
The difference here is how the language is used - i.e. what has been done with it.

Like Java becoming the language of choice for Andoid, Pascal was chosen for Delphi (and later emulated somewhat by C++ Builder).
Now we have Pascal chosen for Ultibo. You could do exactly the same with "C" - I see no reason why not.

But - there is this thing called Lazarus and its underlying fpc compiler. It has silently evolved into a true native multiplatform development system. It just so happens it attempted to emulate Delphi and hence uses Pascal.

To get from Lazarus to Ultibo is not a stretch, merely a cross compiler platform implementation of Lazarus that can also natively run on a pi.
What makes this noteworthy is not the Pascal language (that is a minor detail) but the ready to use Bare bones development environment that compiles your application to a kernel file. It supports, out of the box, most of the drivers you need (but you can easily hack around in them or create new ones).

The real difference becomes apparent when you start using Ultibo. There is nothing to setup, no hassle with toolchains, make files, github, scripts, environments and all the things we are so familiar with under Linux we don't for a moment think there is another way. Ultibo means you spend your time developing your application. All of your time.

As yet, Ultibo does not support the Lazarus LCL - that is the vast collection of usually visual components you place on "forms" to make GUI applications. However - I don't think that is too far away.

Assuming Ultibo would be LCL capable: What would you have ? What would you call this ? All the graphical desktop functionality you would love - booting in 2 seconds and no operating system in sight. If your plan is to develop a "one application" target system. This is as good as it gets. It will need a new name. "Ultibo" does not do that justice.

Now, assume you add the concept of a process to Ultibo and add a loader for an application executable (and expand a bit on the existing page table mapping to accommodate this). What would you have ? Yes - a new operating system is borne. Lightweight and slick just like an early Linux - but up to date modern and lean. Dreaming ? Let's see what happens here...

hippy
Posts: 3893
Joined: Fri Sep 09, 2011 10:34 pm
Location: UK

Re: A Extended Pascal Implementation : CONCEPT.

Fri Jun 08, 2018 11:01 am

Rainier Lamers wrote:
Fri Jun 08, 2018 8:25 am
To get from Lazarus to Ultibo is not a stretch, merely a cross compiler platform implementation of Lazarus that can also natively run on a pi.

What makes this noteworthy is not the Pascal language (that is a minor detail) but the ready to use Bare bones development environment that compiles your application to a kernel file. It supports, out of the box, most of the drivers you need (but you can easily hack around in them or create new ones).
I absolutely agree. I am an advocate of Ultibo, have recommended its use, and am a user of Ultibo, though I have not done too much with it. I wouldn't consider anything else for 'bare metal' development.

Ultibo's biggest negative is it uses Pascal. Nothing wrong with Pascal per se; I understand why it is how it is, and Ultibo is better IMO than any other comparable alternative which currently exists. But it's yet another language to learn or recall from the past, another set of API's to have to learn and become familiar with. That however can be worth it when set against what Ultibo delivers.

Ultibo is great for embedded control. My main problem with Ultibo is that it is currently too low-level for me when I have my 'Application Developer' hat on. High-level application support and some desirable things are not there yet, particularly an easy to use graphics framework and WiFi integration.

What I would need can probably already be created on top of what there is but I don't want the learning curve and effort there currently is; I want it handing to me on a plate. I really can't and wouldn't knock Ultibo for what it is, it just doesn't currently meet my needs.

I am sure Ultibo will evolve into something which does suit my needs and I can accept that I am asking for something which is not reasonable to expect at present. I have nothing but praise for what has been achieved so far and do recommend Ultibo for anyone looking at 'bare metal' options.

User avatar
Gavinmc42
Posts: 2130
Joined: Wed Aug 28, 2013 3:31 am

Re: A Extended Pascal Implementation : CONCEPT.

Fri Jun 08, 2018 12:02 pm

Assuming Ultibo would be LCL capable: What would you have ? What would you call this ? All the graphical desktop functionality you would love - booting in 2 seconds
Some way of using the hardware acceleration for LCL would make it much better ;)
If we had LCl we would be using it just like a PC and not trying other things.
But do we really need it to look like every other OS? Perhaps for other OS users?
But these days that means Android or iOS touch things.

As Garry says, it can do anything and is not limited, so we can be free to explore all sorts of UI's.
My use at the moment is tending towards single purpose OS's, mainly because I don't have time to make a multi purpose OS ;)
That is the great thing, it can grow organically with updates adding more stuff if needed.

We are still stuck with the VC4 but we can probably get more out of the VC4 than any other method or OS one day.
The VC4 is some what limited for a general OS and is showing it's age.
But for IoT it is smoking.

New term I ran into today IIoT, Industrial Internet of Things?
https://inductiveautomation.com/what-is-iiot
MQTT?, yep done.
https://ultibo.org/forum/viewtopic.php? ... MQTT#p6896

Real time is a bit sucky, mostly because we still have just not figured it out yet.
Ultibo on a R series ARM? Ultibo as display/UI's to Realtime controllers?
If we cannot do real time on a 1GHz, 512MB CPU we are just not trying hard enough ;)
Anyway the Pi 4 will have an onboard Cortex M4/7 for that :lol:

We really are seeing a new way for doing "IoT" and display stuff.
Arduino was a new way of doing Microcontrollers but it does not have the connectivity the Pi has.

Dreaming, yep. Dream big, Dream bigger.
I posted lots of ideas on the Ultibo forums since 2016, Garry keeps making them easier to do with each release :lol:
Most of them are now possible to do by people like me, a non professional coder.

My dreams are becoming real, some of those dreams are 40-50 years old ;)
Mostly limited now by my time for learning and acquiring the skill set, flu recovery and memory failures :oops:
My main problem with Ultibo is that it is currently too low-level for me when I have my 'Application Developer' hat on. High-level application support and some desirable things are not there yet, particularly an easy to use graphics framework and WiFi integration.
Yep Ultibo is very close but not quite there yet, SSH /WiFi connectivity etc, it is about as secure as Windows98 :lol:
It is still mostly a one man effort, thankfully on top of those guys who are wise in Laz/FPC coding.
So in effect it is 1000's of people efforts, probably everyone better at coding than me.
Microsoft did not get the VC4 working in Windows IoT, one man called Garry, did it in baremetal.

I am coming up from decades in a 8bit world so my expectations are much lower plus this net stuff is all new to me.
Pascal is better than C for the object stuff and way easier than C++, but I have used SED and AWK so it does not worry me.
When it works it just works, if it does not I just print some debug info to the console screen ;)

I have just spent 6 weeks with CRO's and Logic analyzer debugging C code on a Cortex M0.
6 weeks is a lifetime in Ultibo land.
I could have built the logic analyzer into the Ultibo code in that time.
DMA the GPIO level register into memory?
That should be fast enough for i2c/SPI/UART debugging.

Anyway I find it a fun way to learn this hard stuff, because it is no longer hard.
If it is still hard, I do something else and just wait for the next release :lol:
Sometimes a year or 4 or 6 months will go by before I learn enough or new stuff comes out.
What really annoys me is googling stuff and finding I did it 6 months previously :oops:
I am pretty sure I have said all this before too :lol:
I'm dancing on Rainbows.
Raspberries are not Apples or Oranges

Return to “Other programming languages”