Shop OBEX P1 Docs P2 Docs Learn Events
'Killer App' for P2 ? - Project Oberon - Page 2 — Parallax Forums

'Killer App' for P2 ? - Project Oberon

2»

Comments

  • AleAle Posts: 2,363
    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'll try the second and third versions :).

    More to come !
  • jmgjmg Posts: 15,140
    The swapped code generator sounds promising,
    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.
  • AleAle Posts: 2,363
    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.
  • IMS the compiler is based on the book written by Wirth - Compiler Construction which is available as a pdf.

    http://www.ethoberon.ethz.ch/WirthPubl/CBEAll.pdf
  • AleAle Posts: 2,363
    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 :)
  • It should be doable though given that Oberon has been ported from a Amiga, Atari ST, x86 platforms, Power PC, SPARC, PA-RISC embedded ARM, etc.

    Of course they weren't version 7 of Oberon but earlier versions.

  • AleAle Posts: 2,363
    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 :)
  • cgraceycgracey Posts: 14,133
    Ale wrote: »
    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 :)

    Sounds great!
  • jmgjmg Posts: 15,140
    Ale wrote: »
    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 ?

    Ale wrote: »
    I did modify the AyaCompiler for better error reporting... but reporting line:column gives the wrong line.
    How far off is it ?
    Sometimes this can be just poor line counting, either EOL issues or maybe not counting comments correctly.

    Ale wrote: »
    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.
  • rod1963 wrote: »
    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.
  • AleAle Posts: 2,363
    @jmg:

    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:
    File size (RISC5) size (AMD64)
    ORG         26796        33712
    ORB          9392        16335
    ORS          7048         8429
    ORP         23976        38090
    

    A bit larger on AMD64. Pointers are 64 bits and so on :).

    Now, to test it a bit more and start the port :)


  • AleAle Posts: 2,363
    I added a simple disassembler for RISC5 and compiled a test file:
    MODULE Test2;
    VAR
     A, B: INTEGER;
    BEGIN
        A := B + 5;
    END Test2.
    
    Compiling log
    Compiling to Test2.rsc
    Total size:  56
    Type descriptors:  0
    Data size:  8
    Strings:  0
    Code len:  9
    Code:  4EE90004 SUB   SP, SP, 4
    Code:  AFE00000 ST    LNK, [SP + 0]
    Code:  8D000002 LD    R13, [R0 + 2] **
    Code:  80D00004 LD    R0, [R13 + 4]
    Code:  40080005 ADD   R0, R0, 5
    Code:  A0D00000 ST    R0, [R13 + 0]
    Code:  8FE00000 LD    LNK, [SP + 0]
    Code:  4EE80004 ADD   SP, SP, 4
    Code:  C700000F BRA   LNK
    nofent:  1
    entry:  0
    
    

    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.
    
    Compiling log
    Compiling to Test33.rsc
    Total size:  124
    Type descriptors:  0
    Data size:  8
    Strings:  0
    Code len:  26
    Code:  4EE9000C SUB   SP, SP, C
    Code:  AFE00000 ST    LNK, [SP + 0]
    Code:  A0E00004 ST    R0, [SP + 4]
    Code:  40000050 MOV   R0, R0, 50
    Code:  80000000 LD    R0, [R0 + 0]
    Code:  A0E00008 ST    R0, [SP + 8]
    Code:  80E00004 LD    R0, [SP + 4]
    Code:  40010001 LSL   R0, R0, 1
    Code:  81E00008 LD    R1, [SP + 8]
    Code:  80001 ADD   R0, R0, R1
    Code:  8D00000A LD    R13, [R0 + A]
    Code:  A0D00004 ST    R0, [R13 + 4]
    Code:  8FE00000 LD    LNK, [SP + 0]
    Code:  4EE8000C ADD   SP, SP, C
    Code:  C700000F BRA   LNK
    Code:  4EE90004 SUB   SP, SP, 4
    Code:  AFE00000 ST    LNK, [SP + 0]
    Code:  40000006 MOV   R0, R0, 6
    Code:  F7FFFFED BRAL  FFFFED
    Code:  8D000009 LD    R13, [R0 + 9]
    Code:  80D00004 LD    R0, [R13 + 4]
    Code:  40080005 ADD   R0, R0, 5
    Code:  A0D00000 ST    R0, [R13 + 0]
    Code:  8FE00000 LD    LNK, [SP + 0]
    Code:  4EE80004 ADD   SP, SP, 4
    Code:  C700000F BRA   LNK
    nofent:  1
    entry:  60
    
    
  • jmgjmg Posts: 15,140
    edited 2016-09-18 20:27
    Ale wrote: »
    ...
    Now, to test it a bit more and start the port :)

    @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
                           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...

  • Here's a "baremetal" Oberon project for Raspberry Pi based on Ultibo:

    https://ultibo.org/forum/viewtopic.php?f=9&t=219
  • And for those who want to try Oberon, you can run it in a modern browser:

    http://copy.sh/v86/

    The environment didn't see intuitively obvious to me.
  • captbillcaptbill Posts: 3
    edited 2016-10-03 19:10
    KeithE wrote: »
    And for those who want to try Oberon, you can run it in a modern browser:

    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.




  • AleAle Posts: 2,363
    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.
  • jmgjmg Posts: 15,140
    edited 2017-12-28 19:30
    Ale wrote: »
    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.


    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...
Sign In or Register to comment.