Author Topic: Baremetal Pascal dev. environment for RPi  (Read 12034 times)

0 Members and 1 Guest are viewing this topic.

Offline medical-nerd

  • Regular Contributor
  • *
  • Posts: 198
  • Country: gb
  • What's that coming over the hill?
Re: Baremetal Pascal dev. environment for RPi
« Reply #50 on: September 21, 2017, 12:21:13 pm »

Many thanks for posting this, I've been building a retro platform with isa cards on an industrial backplane to use the Dig64 cards I have:

http://www.farnell.com/datasheets/88563.pdf

Running DOS, windows 95 and Turbo Pascal 7.0.

I now have a reason to buy a raspberry pi to play with.

I've used Linux since kernel 0.99 but using it in simple embedded systems didn't interest me, bare metal with pascal does!!

Cheers
'better to burn out than fade away'
 
The following users thanked this post: Vtile

Offline legacy

  • Super Contributor
  • ***
  • !
  • Posts: 4415
  • Country: ch
Re: Baremetal Pascal dev. environment for RPi
« Reply #51 on: September 21, 2017, 12:51:07 pm »
You just need to take appropriate care. Which, sadly, not everyone does.

No, we don't need to recycle the C language and its philosophy again and again!
We need to change people's head,  or better still, we'd best give people a head up!
 

Offline legacy

  • Super Contributor
  • ***
  • !
  • Posts: 4415
  • Country: ch
Re: Baremetal Pascal dev. environment for RPi
« Reply #52 on: September 21, 2017, 01:05:11 pm »
The C language as well as its preprocessor promotes "ambiguity", one of the most undesirable property of programming language grammar, as it significantly complicates the job of a compiler-writer as well as the life of users!

Oberon, Modula2 as well as Pascal are focused on "interfaces" and "being modular", while the the C language (no matter if C++, C++11, C+=whatever) still suffers of some bad design points, such as argument type transposed between function and call, functions that may be passed one argument but expected three, and too junk off the stack, variable used before being set without a warm, ambiguity in pointers...

Too bad! Does people really need to care about that? Do they need "validating-software"  like MISRA-LINT?

Well .... for sure even if you could make your programming language 100% reliable, you would still be pray to catastrophic bugs in the algorithm, thus the algorithm and data are THE MOST important thing to
be focused on, no matter which language you want to use to express the algorithm, but ...

But! the syntax of C declarations is a truly mess that permeates the use of the entire language, and it's no exaggeration to say that C is significantly and needlessly complicated because of the awkward manner of combining types.

On the pragmatic side, the economics of software is such that the earlier in the development cycle a bug is found, the cheaper it is to fix. So, it's a good investment to have a language or a tool do the job to find problems rather than the debugger; but Better a debugger finds the problems than an internal test group. The worst option of all is to leave the problems to be found by customers.

This one, the last one in my lines, is one of *the* reason why we use Ada in avionics  :D
 

Offline C

  • Super Contributor
  • ***
  • Posts: 1346
  • Country: us
Re: Baremetal Pascal dev. environment for RPi
« Reply #53 on: September 21, 2017, 09:23:59 pm »

A lot of problems talked about here is due to poor compilers.

Way back in the 70's & 80's HP used pascal internally. Due to the fact that HP wrote the compiler, they could make great changes to how it worked. Some here might not know that back then HP made it's own silicon, HP created processors.

One example is HP PASCAL/64000. This was a Pascal with additions & changes to assist in bare-metal development. From the programmer's side, a processor change was just changing the first line of a program so that proper compiler back-end could be selected for code generation.. The back-end of compiler generated an IL that had had 4 objects.  In source the statement "A := B + C" became " ADD, Destination, Source1, Source2". This simple change allowed better translation from IL to processor instructions.

Another example is the HP series 200 computer line. This was the replacement of the  HP9825 which used a HP created 16 bit processor whit a system around the Motorola 68000. HP Pascal was the foundation that created the software needed. The first was the HP9826. The 9825 used a language called "HPL" so a need to continue to run these programs on replacement was needed. HP Pascal created the HPL work-a-like that was much faster. HP Pascal created the Pascal based system for this series. HP Pascal also created the HP Basic system.so that the series 200 could start replacing the 9835 & 9845 computers.
The Compiler I used as an end user was almost the same as the compiler used internal to HP, The internal pascal had and option to allow better system programming called "MODCAL", My compiler would not set the flag to enable this extension.
One thing "MODCAL" allowed was a pascal program to connect to different blocks of code in a very simple way under program control. This is a basic need of any OS but here could also function as overlays if you had the "MODCAL" option.

The other big change was MODULE'S.
Each MODULE was compiled separately. This allowed many things. The Module header could be used by other modules when compiled with no need for the full module source code or the binary. Many people could work on separate Modules at same time.,  The Module header could be used before the complete module source existed & could be used to generate the assembly language interface code needed for modules written is assembly. A pascal program was also a module. A simple idea that is very powerful.

So HP back then created many systems with Pascal as a foundation.

Some here do not like a compiler that generates Pcode or byte code. This should be and option for any compiler. If you take the blinders off, again a very powerful capability that some want to throw in the trash. When the Pcode or Byte code interpreter is written in Pascal, you could have pascal scripts used in a program. With a change you could run many Pcode streams at same time by time sharing the processing.

So put on your thinking cap.
By being able to compile modules separately, Compile times decrease & code creation becomes faster & easer and is checked at pascal source level for errors..

If you had started with a great pascal, I think most would see the huge problems that C and C like languages create.
Need to remember the starting point, C was designed to replace an Assembler. Pascal was designed from high level point of view.

The options should not be a choice of ONE.
It is not that hard to have a compiler generate more then one type of output, you just need a way of telling the compiler.
The lack of input to compiler is preventing the assistance a compiler could do just due to a little lack of input.
It's, Don't fix the source of the problems, but create a hack to work around the problem.

Today with the computers we are using, the editor should be doing language source checking in the editor leaving the compiler to just generate the code.


 

   
 
The following users thanked this post: Vtile

Offline VtileTopic starter

  • Super Contributor
  • ***
  • Posts: 1144
  • Country: fi
  • Ingineer
Re: Baremetal Pascal dev. environment for RPi
« Reply #54 on: September 21, 2017, 11:02:58 pm »
That were interesting piece of history, like some parts of some other posts.

It seems there is possibility to use RPi with Rasbian as development host or what it is called. How nerdy!
Here are the instuctions. https://ultibo.org/wiki/Building_for_Raspbian
« Last Edit: September 22, 2017, 10:16:59 pm by Vtile »
 

Offline VtileTopic starter

  • Super Contributor
  • ***
  • Posts: 1144
  • Country: fi
  • Ingineer
Re: Baremetal Pascal dev. environment for RPi
« Reply #55 on: September 22, 2017, 12:30:46 am »
Here is more interesting information from Raspberry forums. It seems Ultibo is first dev. system to allow OpenGL and what not without true OS.: https://www.raspberrypi.org/forums/viewtopic.php?f=72&t=193560&sid=23f70d3919ed023ea9ed6dd947ba87bc
 

Offline hendorog

  • Super Contributor
  • ***
  • Posts: 1617
  • Country: nz
Re: Baremetal Pascal dev. environment for RPi
« Reply #56 on: September 22, 2017, 08:38:10 pm »
Here is more interesting information from Raspberry forums. It seems Ultibo is first dev. system to allow OpenGL and what not without true OS.: https://www.raspberrypi.org/forums/viewtopic.php?f=72&t=193560&sid=23f70d3919ed023ea9ed6dd947ba87bc

Nice!

I think Ultibo just went from an interesting curiosity to something much more important for quite a few people :)
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf