I've been researching the possibility of porting Project Oberon to the P2.
A direct Oberon-07 compiler to P2 is of course not available. But there are several possibilities, though:
. bootstrap a P2 Oberon system using an Oberon compiler hosted on a pc: doable, its own set of problems:
modify an existing compiler to produce P2 code
find a suitable compiler able to compile PO (or modify it to be able to....)
just write the thing from scratch!, afraid of a bit compiler writing ? are we ? :)
. retarget the code generator in Project Oberon, to produce P2 code instead of RISC5; doable, its own set of problems:
working in Oberon, what we want anyways but P2 based.
testing needs a working simulator (available) or a target (not yet available to me).
for testing it would be great if both emulators could be "merged" in a ASMP way, so we could launch the P2 code from within PO. I kind of like this idea!.
. recompile the RISC5 binaries targeting the P2 instead, we have sources, we have listings, we have binaries. (I'll have to study those binaries, listings and so on).
I've been following those threads, together with the taz thread, to see if I could use some parts of them. Unless one goes for a very different approach, the Oberon compilers i've seen generate the code on the fly and patch it where necessary. That makes re-targeting difficult, imho.
There, in the book, the oberon0 version is described, the OS uses oberon07, another revision with many enhancements. Of course one could extend an existing version 0 into a version 7...
Such a compiler exists in several variants, I downloaded one written in python, it follows the original quite fatefully, it is my starting point in trying to retarget the oberon07 compiler
I did it ! I did it ! I thought it would be impossible.
I have the original, from project Oberon compiler ORP, (written in Oberon) compiled and working natively on win32 !
I used the AyaCompiler. I had to make many adjustments, I got rid of the Texts and Files dependencies and changed a bit how file access occur, using a couple of modules from the AyaCompiler. I did modify the AyaCompiler for better error reporting... but reporting line:column gives the wrong line.
I have to see now how do I test the generated code, and for a P2 port . The sources will be posted to github
I did it ! I did it ! I thought it would be impossible.
I have the original, from project Oberon compiler ORP, (written in Oberon) compiled and working natively on win32 !
I used the AyaCompiler. I had to make many adjustments, I got rid of the Texts and Files dependencies and changed a bit how file access occur, using a couple of modules from the AyaCompiler. I did modify the AyaCompiler for better error reporting... but reporting line:column gives the wrong line.
I have to see now how do I test the generated code, and for a P2 port . The sources will be posted to github
I did it ! I did it ! I thought it would be impossible.
I have the original, from project Oberon compiler ORP, (written in Oberon) compiled and working natively on win32 !
I used the AyaCompiler. I had to make many adjustments, I got rid of the Texts and Files dependencies and changed a bit how file access occur, using a couple of modules from the AyaCompiler.
Impressive.
Can you report the sizes of used memory with AMD64 target vs original RISC ?
I have to see now how do I test the generated code, and for a P2 port . The sources will be posted to github
Cool.
You could add a comment to AyaCompiler, as I see they ask for test sources ?
Also raise the error reporting line# bug as an issue if it is elusive.
I see this comment "INT8, INT16, INT32, CARD16, CARD32 types
Reason for introducing: Same as BYTE type, in order to economise the use of memory.
Note: Type inclusion is not the same as in Oberon-2/Component Pascal. All the integer types: BYTE, INT8, CARD16, INT16, CARD32, INT32 and INTEGER are interchangable. All integer variables when loaded to register are signed extended to 64-bit INTEGER type. All integer calculation results are 64-bit INTEGER. That means BYTE + BYTE = INTEGER. Therefore, there is no speed benefit for using small integer types over INTEGER type. The programmer should use only INTEGER type for most of cases, which is good programming practice."
Which is not such good news for a P2 port, where 32b is a better native choice, and BYTE is probably also good to have for BYTE opcodes.
As to why it hasn't caught on is simple - because it came about after the C-Pascal wars and was regarded as little more than a oddity by most.
Well, that and that it supported only cooperative multitasking. Ok, Mac OS at that time was no better, but that a new OS should be created then with such a limitation was at least a questionable design decision.
I did not port the AyaCompiler to the P2, I ported the original ORP compiler from "itself" to the AyaCompiler, meaning I do not have to deal with Aya's idiosyncrasies (CHARs are 16 bits ! instead of 8).
Regarding sizes, let's assume that the modifications are kind of equivalent to what was there before, these are the sizes:
R13 is the local variables pointer. Interesting that is loads from an address not modulo 4, apparently.
A longer example:
MODULE Test33;
IMPORT SYSTEM;
VAR
A, B: INTEGER;
PROCEDURE p1(j: INTEGER);
VAR x: INTEGER;
BEGIN
SYSTEM.GET(80, x);
B := j * 2 + x;
END p1;
BEGIN
p1(6);
A := B + 5;
END Test33.
DIP48 form factor, Cmod A7-15T $75 Cmod A7-35T $89
Cmod A7-15T $75 Cmod A7-35T $89
FPGA part XC7A15T-1CPG236C XC7A35T-1CPG236C
1 MSPS On-chip ADC Yes Yes
Programming options Quad-SPI Flash/JTAG Quad-SPI Flash/JTAG
Look-up Tables (LUTs) 10,400 20,800
Flip-flops 20,800 41,600
Block RAM 112.5 KB 225 KB
Clock Management Tiles 5 5
System Features
512KB SRAM with an 8-bit bus and 8ns access times
4MB Quad-SPI Flash
USB-JTAG Programming Circuitry
Powered from USB or external 3.3-5.5V supply connected to DIP pins
System Connectivity
USB-UART bridge
Interaction and Sensory Devices
2 LEDs
1 RGB LED
2 Push Buttons
Expansion Connectors
48-pin DIP connector with 44 Digital I/O and 2 Analog inputs (0-3.3V)
One Pmod connector with 8 Digital I/O
It is a Xilinx flow, but the form factor and prices look attractive, certainly can do a great P1V, and a more modest P2 test vehicle, so can cover many test uses...
The environment didn't see intuitively obvious to me.
That's nice. The best online emulator for Oberon I think I have seen. Cool. Booted first go for me.
On the main "Project Oberon" web page there is a windows executable that runs the current, up to date emulation of the FPGA version. This page has it ALL, in one place. The emulator is the very right/bottom links. projectoberon.com/
To be clear, the "bare metal" Ultibo version is a port of the "official emulator" by Peter De Wachter from C to Freepascal to run on Ultibo. This is very promising since now we have a full cohesive "Wirthian" programming environment. Lazarus+Freepascal for the desktop and Oberon for the microcontroller realm, with a nice emulator.
I got sidestepped with another project, recreating woodstock, not the event, but the calculator
I was making some progress and I need to investigate a bit more how the code generator works, because the 1-pass compiler modifies existing code and was tightly coupled to the RISC5 instruction set. I also messed up the modules because I could not read them back... a 1:1 translation of the compiler for the p2 using another compiler is not the best, I had to start somewhere.
I got sidestepped with another project, recreating woodstock, not the event, but the calculator
I was making some progress and I need to investigate a bit more how the code generator works, because the 1-pass compiler modifies existing code and was tightly coupled to the RISC5 instruction set. I also messed up the modules because I could not read them back... a 1:1 translation of the compiler for the p2 using another compiler is not the best, I had to start somewhere.
This slices the earlier, more complete Project Oberon, and so has a much smaller memory footprint, & now targets the smaller 192k internal BRAM FPGA boards.
"3. Embedded Project Oberon
The compiled applications produced by Astrobe can be executed on a subset of the complete Project Oberon OS i.e. just the Kernel, loader, filesystem, SPI, RS232 and SD card support. This is referred to as Embedded Project Oberon.
All of the development can be done on Windows so the higher-level layers of Project Oberon OS with its user-interaction features: GUI, display, VGA, mouse, keyboard, compiler, editor etc. are not required on the target FPGA system.
Interactive execution of the programs can be controlled by the Astrobe Terminal connected to the development board by a 115200 baud serial link. Download the Embedded Project Oberon version of the document How to use the Oberon System for more details.
The reduced memory footprint of Embedded Project Oberon means it is possible to run RISC5 Oberon applications on the latest Xilinx FPGA devices (with 192 KBytes or more of internal BRAM) with no need for any external RAM e.g."
There is a report I think is used bytes/% of 53984 32%, which indicates a overall system memory of ~168700 bytes ? ( IIRC, the full Project Oberon OS, usually runs on ~1MByte FPGA boards, 1024 * 768 VGA )
It does look like Embedded Project Oberon is small enough to easily fit a P2, and should be easy to test, given how it is split.
This should appeal to Parallax, as there is a strong education focus to this, and a P2 module should come in cheaper than the FPGA boards (& with more RAM, MHz)
Anything that has classes running a P2 and any other MCU, has to be great exposure...
Comments
A direct Oberon-07 compiler to P2 is of course not available. But there are several possibilities, though:
. bootstrap a P2 Oberon system using an Oberon compiler hosted on a pc: doable, its own set of problems: modify an existing compiler to produce P2 code find a suitable compiler able to compile PO (or modify it to be able to....) just write the thing from scratch!, afraid of a bit compiler writing ? are we ? :) . retarget the code generator in Project Oberon, to produce P2 code instead of RISC5; doable, its own set of problems: working in Oberon, what we want anyways but P2 based. testing needs a working simulator (available) or a target (not yet available to me). for testing it would be great if both emulators could be "merged" in a ASMP way, so we could launch the P2 code from within PO. I kind of like this idea!. . recompile the RISC5 binaries targeting the P2 instead, we have sources, we have listings, we have binaries. (I'll have to study those binaries, listings and so on).I'll try the second and third versions
More to come !
There is already some good back-end code generation done here
http://forums.parallax.com/discussion/164187/fastspin-compiler-for-p2
so you may be able to merge the two ?
First pass does not have to be super optimized.
http://www.ethoberon.ethz.ch/WirthPubl/CBEAll.pdf
Such a compiler exists in several variants, I downloaded one written in python, it follows the original quite fatefully, it is my starting point in trying to retarget the oberon07 compiler
Of course they weren't version 7 of Oberon but earlier versions.
I have the original, from project Oberon compiler ORP, (written in Oberon) compiled and working natively on win32 !
I used the AyaCompiler. I had to make many adjustments, I got rid of the Texts and Files dependencies and changed a bit how file access occur, using a couple of modules from the AyaCompiler. I did modify the AyaCompiler for better error reporting... but reporting line:column gives the wrong line.
I have to see now how do I test the generated code, and for a P2 port
Sounds great!
Can you report the sizes of used memory with AMD64 target vs original RISC ?
How far off is it ?
Sometimes this can be just poor line counting, either EOL issues or maybe not counting comments correctly.
Cool.
You could add a comment to AyaCompiler, as I see they ask for test sources ?
Also raise the error reporting line# bug as an issue if it is elusive.
I see this comment
"INT8, INT16, INT32, CARD16, CARD32 types
Reason for introducing: Same as BYTE type, in order to economise the use of memory.
Note: Type inclusion is not the same as in Oberon-2/Component Pascal. All the integer types: BYTE, INT8, CARD16, INT16, CARD32, INT32 and INTEGER are interchangable. All integer variables when loaded to register are signed extended to 64-bit INTEGER type. All integer calculation results are 64-bit INTEGER. That means BYTE + BYTE = INTEGER. Therefore, there is no speed benefit for using small integer types over INTEGER type. The programmer should use only INTEGER type for most of cases, which is good programming practice."
Which is not such good news for a P2 port, where 32b is a better native choice, and BYTE is probably also good to have for BYTE opcodes.
I did not port the AyaCompiler to the P2, I ported the original ORP compiler from "itself" to the AyaCompiler, meaning I do not have to deal with Aya's idiosyncrasies (CHARs are 16 bits ! instead of 8).
Regarding sizes, let's assume that the modifications are kind of equivalent to what was there before, these are the sizes:
A bit larger on AMD64. Pointers are 64 bits and so on
Now, to test it a bit more and start the port
MODULE Test2; VAR A, B: INTEGER; BEGIN A := B + 5; END Test2.R13 is the local variables pointer. Interesting that is loads from an address not modulo 4, apparently.
A longer example:
MODULE Test33; IMPORT SYSTEM; VAR A, B: INTEGER; PROCEDURE p1(j: INTEGER); VAR x: INTEGER; BEGIN SYSTEM.GET(80, x); B := j * 2 + x; END p1; BEGIN p1(6); A := B + 5; END Test33.@Ale - Any updates ?
I saw some recent news on expanding Project Oberon FPGA support...
http://www.astrobe.com/forum/viewtopic.php?f=13&t=510
http://store.digilentinc.com/cmod-a7-breadboardable-artix-7-fpga-module/
DIP48 form factor, Cmod A7-15T $75 Cmod A7-35T $89
It is a Xilinx flow, but the form factor and prices look attractive, certainly can do a great P1V, and a more modest P2 test vehicle, so can cover many test uses...
https://ultibo.org/forum/viewtopic.php?f=9&t=219
http://copy.sh/v86/
The environment didn't see intuitively obvious to me.
That's nice. The best online emulator for Oberon I think I have seen. Cool. Booted first go for me.
On the main "Project Oberon" web page there is a windows executable that runs the current, up to date emulation of the FPGA version. This page has it ALL, in one place. The emulator is the very right/bottom links. projectoberon.com/
To be clear, the "bare metal" Ultibo version is a port of the "official emulator" by Peter De Wachter from C to Freepascal to run on Ultibo. This is very promising since now we have a full cohesive "Wirthian" programming environment. Lazarus+Freepascal for the desktop and Oberon for the microcontroller realm, with a nice emulator.
I was making some progress and I need to investigate a bit more how the code generator works, because the 1-pass compiler modifies existing code and was tightly coupled to the RISC5 instruction set. I also messed up the modules because I could not read them back... a 1:1 translation of the compiler for the p2 using another compiler is not the best, I had to start somewhere.
Any more progress ?
I'll bump this thread, ( and also see Ale's http://forums.parallax.com/discussion/164401/porting-the-oberon-compiler-orp-to-the-p2 )
I see this update from Astrobe http://www.astrobe.com/RISC5/ adds a new variant called Embedded Project Oberon
This slices the earlier, more complete Project Oberon, and so has a much smaller memory footprint, & now targets the smaller 192k internal BRAM FPGA boards.
"3. Embedded Project Oberon
The compiled applications produced by Astrobe can be executed on a subset of the complete Project Oberon OS i.e. just the Kernel, loader, filesystem, SPI, RS232 and SD card support. This is referred to as Embedded Project Oberon.
All of the development can be done on Windows so the higher-level layers of Project Oberon OS with its user-interaction features: GUI, display, VGA, mouse, keyboard, compiler, editor etc. are not required on the target FPGA system.
Interactive execution of the programs can be controlled by the Astrobe Terminal connected to the development board by a 115200 baud serial link. Download the Embedded Project Oberon version of the document How to use the Oberon System for more details.
The reduced memory footprint of Embedded Project Oberon means it is possible to run RISC5 Oberon applications on the latest Xilinx FPGA devices (with 192 KBytes or more of internal BRAM) with no need for any external RAM e.g."
There is a report I think is used bytes/% of 53984 32%, which indicates a overall system memory of ~168700 bytes ? ( IIRC, the full Project Oberon OS, usually runs on ~1MByte FPGA boards, 1024 * 768 VGA )
It does look like Embedded Project Oberon is small enough to easily fit a P2, and should be easy to test, given how it is split.
This should appeal to Parallax, as there is a strong education focus to this, and a P2 module should come in cheaper than the FPGA boards (& with more RAM, MHz)
Anything that has classes running a P2 and any other MCU, has to be great exposure...