[Oberon] Project Oberon: New Edition

[eas lab]

] On a 64 bit machine, two integer datatypes will suffice: CHAR (8 bit)
] and INTEGER (64 bit). Same for (LONG)REAL. Modern processors are so
] complex that there is no need for intermediate datatypes.

64 bit seems absurd? I remember M$'s <Pascal 10 page booklette & cassette>
probably pre-DOS, where the compiler just stopped listing the source on
the old RCA-input B/W via a Z80 *8*bit CPU, when it hit an error.
No need for compiler error diagnostics. You could SEE where's the error.

] Mr Niemann (also on this list) is working on an Oberon to C translator.
] Perhaps he would be pleased to get some support.

What's wrong with the existing p2c?
->  which p2c  == /usr/bin/p2c
CtoPascal would be very usefull to port some of the MASS of available
C-sources. I can contribute my previous work/investigation on *that*.

] Prof Wirth is showing us his framework. We should build on that, no
] copy it.

] A good start would be to port Native Oberon to gcc but the sources of NO
] are very hard to get.

Are they available, or secret?  Where's Mr Snowden?
gcc is a monster-moving-target: to be avoided.
Yes!! We can ride-on-top-of *nix device drivers.
But our language, compiler, TUI ..etc. is much superior.

==== posted in the RPi NewsGroup:--
>>>> When a compile takes a significant part of the day (as with compiling
>>>> the kernel on the RPi), making multiple runs is extremely time
>>>> consuming!  Unfortunately, even if you want to change just one
>>>> option, if it's your first compile it still takes almost all the
>>>> working day.
--
Old timers may know about the 70s dual between:
 European: algol -> Pascal
and
 US: C [actually originated from UK B]
Many C-users said "Oberon [Pascal's descendant] doesn't work",
because when they test-compiled the eg. compiler, there was no
grinding-wheels-and-smoke. It just wrote <Compiling ?? 75..9 Bytes>.
Because it was DONE!

============
> Others might even hate the TUI because the mouse-interclicks cannot be
> translated to touch screens but on the other hand like to have a nice
> programming language and a small footprint, understandable OS they can
> use on limited resources devices.

Yes!! One must separate the attributes which we value - concretely:
 HCI/TUI;
 minimalist, close-to-natural-language syntax;
 economical implementation.
========
] This is not an attempt to be another PC or Linux clone or even an
] alternative - it is in a different category altogether. It is open hardware
] as well as open software - and I don't just mean that the schematics
] are available.

That's great, as an educational project.
I was complaining on the rPi:group that no one dares to look-down to the
hardware-level. They only fill-in-forms like office-boys.
I can't find a listing of the byte-sequence for an implementation of the
3 pseudo-code instructions: #N -> rR ; rR -> (Memory) ; Branch Here.

Ie. to set various memory-mapped-ports and WaitForever.
I've read that the ARM-assembler puts the constants after the code,
but I refuse to open another canOworms/tool-chain/syntax just to set
a register. BTW.  I'll also need to:  `(Memory) -> rR`

Thanks,

== Chris Glur.