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

'Killer App' for P2 ? - Project Oberon

jmgjmg Posts: 15,173
edited 2015-08-05 01:44 in Propeller 2
Some very interesting work is being done (refreshed) in Europe

http://www.inf.ethz.ch/personal/wirth/ProjectOberon/index.html

http://www.inf.ethz.ch/personal/wirth/ProjectOberon/PO.System.pdf
Mostly thanks to the regularity of the RISC instruction set, the size of the compiler could be reduced significantly.
It now measures less than 2900 lines of program and compiles itself in about 3 seconds, which is proof of its efficiency.
The entire system compiles itself in less than 10 seconds.
Considered extravagant and hardly necessary only years ago, run-time checks are generated automatically. In particular, they cover index range checks and access to NIL-pointers. Due to their efficiency they hardly affect run-time speed, but are a great benefit to programmers.

bold added, and I think those build time numbers are for a modest 25Mhz CPU clock !

Some porting is already underway - example
http://forum.gadgetfactory.net/index.php?/topic/2132-project-oberon-on-papilio-pro/#entry14771

A screenshot is here ( I think @ 1024 x 768, VGA, 75MHz Pixel Clock, 25Mhz CPU clock )
http://www.saanlima.com/images/oberon2.jpg

More forum comments here
https://lists.inf.ethz.ch/pipermail/oberon/2014/007853.html


The FPGA host has 1MB of RAM (32b), (+SD) which is rather close to planned P2 resource of 512k, and I cannot yet find mention of how much of that 1MB was actually needed for the builds above, or the final 'EXE/BIN' sizes.

Present core used is FPGA 32b Soft-CPU RISC5 (not to be confused with RISC-V), but this bit from above .PDF gives other pathways :
A welcome consequence of the simplifications of language and processor is the fact that all parts that had been written in assembler code in 1992 -- and therefore were not included in the book -- have now been expressed in Oberon as well

That comment makes it look like porting to P2 involves just the back-end of the compiler. (which would be compiled on a PC host, before being able to self-compile inside P2 )

Source of Compilers and RISC5 (in verilog) are here
http://www.inf.ethz.ch/personal/wirth/ProjectOberon/index.html

I think this is the RISC5 binary code-generator portion
http://www.inf.ethz.ch/personal/wirth/ProjectOberon/Sources/ORG.Mod.txt
date stamped quite recently
[" NW 31.5.2015 code generator in Oberon-07 for RISC Code generator for Oberon compiler for RISC processor."]
and the binary-opcode building is done in Put0 thru Put3

It seems the original PCB had 32b memory, and the porting above added an external 32b RAM for simplicity of least changes, but the now-accessible Cyclone A9 device can give 1MB in the FPGA.

I'll continue looking for Binary image sizes, and actual Build memory requirements.

The total system includes
17. The Processor's Environment
17.1. The SRAM memory
17.2. Peripheral Interfaces
17.2.1. The PS-2 interface
17.2.2. The SPI interface
17.2.3. The RS-232 interface
17.2.4. The display controller
17.2.5. The Mouse interface

The simple Verilog modules for each of those low-level peripherals, would re-map to P2 COG(s)
«1

Comments

  • mindrobotsmindrobots Posts: 6,506
    I'm pretty sure Project Oberon has appeared here before. The port to the papillio pro makes it interesting. I have one of those squirreled away someplace. I should dig it out and give it a whirl in ISE.
  • jmgjmg Posts: 15,173
    edited 2015-08-05 00:07
    I found some binary sizes, unclear if they are updated to RISC5, but I'd guess so.
    Comes in just under 100k code+static data, ( plus 98304 of Pixel Memory for 1024x768 ?)
    That's looking well within the P2 resource, assuming P2 is equal to RISC5 in code density.
    module  	code  	data  	lines
======          ====    ====    =====
Kernel  	1123  	8244  	263
FileDir  	1963  	60  	352
Files  		2360  	148  	505
Modules  	1214  	112  	226
Input  		186  	32  	79
Fonts  		628  	56  	115
Display  	1033  	84  	190
Viewers  	1324  	104  	206
Texts  		2906  	204  	537
Oberon  	1679  	288  	410
MenuViewers  	1513  	56  	208
TextFrames  	5786  	292  	874
System  	2134  	72  	418
Edit  		1096  	1104  	232
		24945 	10856  	4615

ORS  		1762  	992  	319
ORB  		2348  	408  	437
ORG  		6699  	34976  	1125
ORP  		5994  	144  	974
		16803  	36520  	2855
		
Graphics  	3484  	564  	685
GraphicFrames  	2832  	288  	498
Draw  		690  	40  	164
Rectangles  	649  	40  	118
Curves  	1765  	72  	241
		9420  	1004  	1706

		====	====	====
Totals		51168	48380	9176
module  	code  	data  	lines
  • jmgjmg Posts: 15,173
    mindrobots wrote: »
    I'm pretty sure Project Oberon has appeared here before.
    You are right, I even found a thread I'd started 18 months back I have forgotten completely about...
    Still, the May 2015 revisions in the source files, and imminent P2 image makes this topical...

    mindrobots wrote: »
    The port to the papillio pro makes it interesting. I have one of those squirreled away someplace. I should dig it out and give it a whirl in ISE.
    Let us know the numbers. I think a full run needs added-RAM, but the A7- A9 boards should have enough inside the FPGA.
  • potatoheadpotatohead Posts: 10,261
    This is more complete than I saw last time you linked it.
    A whole system expressed in an efficient, high level language.

    And Wirth?

    I'll be reading for a while. IMHO, porting to P2 would be a great project.

  • jmgjmg Posts: 15,173
    potatohead wrote: »
    This is more complete than I saw last time you linked it.
    A whole system expressed in an efficient, high level language.

    And Wirth?

    I was impressed to see this tag
    [" NW 31.5.2015 code generator in Oberon-07 for RISC Code generator for Oberon compiler for RISC processor."]
    Seems Wirth is still active in the coding of this.
  • Peter JakackiPeter Jakacki Posts: 10,193
    Looking at the binary sizes table I fail to see any Ethernet at all. This might have been fine in the 80's but everything depends upon Ethernet connectivity these days. Perhaps they have Ethernet protocols working but left the figures out to make it look better.
  • mindrobotsmindrobots Posts: 6,506
    edited 2015-08-05 14:42
    Networking is considered an application.

    Section 10 of the Project Oberon "book" explains the network. It is of course, its own protocol and makes no use of Ethernet. The Oberon network abstraction would need to be mapped on top of a "proper" IP stack to make this more than an academic curiosity.
  • rod1963rod1963 Posts: 752
    If people can connect the Prop or a horde of disposable ARM boards to the internet the same can done with Oberon.

    Still at the very least a fully functioning Oberon system working on a PII would make a nice demo program for the masses compared to say CPM.

    However the main question is who will do the initial porting of the Oberon compiler back end so it can generate PII binaries and begin the porting process.
  • potatoheadpotatohead Posts: 10,261
    The good news is Wirth and team have put the basic code patterns needed into the documentation.

    Re: Network

    Their goal was to make a complete system, small, but functional. I did some reading last night, and the system is really interesting. It's complete enough for a few people to use it and actually get a few meaningful things done. But that's it, and as a learning tool, fantastic.

  • yetiyeti Posts: 818
    potatohead wrote: »
    The good news is Wirth and team have put the basic code patterns needed into the documentation.
    ftp://ftp.ethoberon.ethz.ch/Oberon/ ... so noone has to manually cut and paste from the docs...

    Searching GitHub for Oberon yields lots of repositories, maybe some of that stuff can be turned into a crosscompiler for the Propeller as bootstrap step for a native one...

    I was digging around the net for Oberon after a commercial Oberon compiler for microcontrollers was mentioned in the ESP8266 forums "OBERON: THE ULTIMATE COMPILER?" but I'm still not convinced that this (seen as tool for everyday tasks) would be worth all that sweat... but sometimes having a cute new toy (or pet) is nice and all you need for motivation...
  • rod1963rod1963 Posts: 752
    Yeti

    Astrobe is the company that sells Oberon compilers for ARM micros. Though you can also download a starter version of it for free. It's pretty nice if you're into programming ARM micros.

    He's also in the process of releasing a Windows based cross compiler for the Oberon System for FPGA's.

    link:
    http://www.astrobe.com/default.htm

  • yetiyeti Posts: 818
    edited 2015-08-06 20:17
    rod1963 wrote: »
    Though you can also download a starter version of it for free.
    No source, no go!
    And I live in the Unix universe... no Windows here...


    (Edit@20150806-2217-CEST)

    I tried Bluebotte-OS on a Thinkpad T30. It runs but lacks network connectivity because too few NICs are supported and exactly not the one in this notebook. It should be able to do networking if run inside VMWare, but I did not try this yet.

    ...and...

    Building an emulator for the RISC CPU used by Project Oberon on Debian8 is trivial and a prepared diskimage file for this emulator is mentioned in the emu's README.md. Networking is said not to work too but a way to transfer files between PC and emulator is mentioned.

    This is what Project Oberon runs on the FPGA, so it probably is the more natural choice than Blubebottle-OS to get an impression of Project Oberon.
  • rod1963rod1963 Posts: 752
    Actually Oberon on FPGA was designed by Wirth as a teaching device for students but is quite extensible for those who want to do more. WIrth was disgusted with the existing bloated and complex OS's and hardware platforms. So he rolled his own and made workable and understandable system hardware and software wise in a very small package.

    It's quite impressive effort and fine teaching platform. He's certainly old school.

    Never expected the Prop community to embrace it though. Everything centers around Spin and PASM for the Prop.

    Yeah Astrobe isn't aimed at Linux users, too many platforms to support for a small shop. I saw the goat rope that some users here had with Altera Quartus for Linux. What a nightmare. I don't blame the author from staying away from this tar baby

  • jmgjmg Posts: 15,173
    edited 2015-08-16 02:20
    rod1963 wrote: »
    Actually Oberon on FPGA was designed by Wirth as a teaching device for students but is quite extensible for those who want to do more. WIrth was disgusted with the existing bloated and complex OS's and hardware platforms. So he rolled his own and made workable and understandable system hardware and software wise in a very small package.
    Not quite - Wirth started coding complete systems in one language, way back with Lilith - long before FPGAs hit the scene.

    https://en.wikipedia.org/wiki/Lilith_(computer)

    A respin was done in Ceres in 1985, still way before FPGAs were practical hosts.
    rod1963 wrote: »
    It's quite impressive effort and fine teaching platform. He's certainly old school.

    Never expected the Prop community to embrace it though. Everything centers around Spin and PASM for the Prop.

    Why not ?
    Parallax are focused already on fine teaching platforms.
    Many ask in the forums here, about self hosting in various flavours.

    The P2 could run the newest respin from Wirth, but it will struggle to run larger OS offerings.
  • potatoheadpotatohead Posts: 10,261
    edited 2015-08-16 04:19
    "all about spin..."

    Actually, that isn't true.

    We have had lots of C activity, and I predict we will have more of it on P2. It's a bit more roomy, which should make the whole C experience more attractive.

    And of course a lot of it is about SPIN+PASM. That combination is awesome. 'nuff said. :)

    I would be interested in running this as a curio one day. I feel some others may too, but that's far from an embrace of any kind.

    Re: OS offerings

    Assuming it all plays out as expected, the whole point of a P2 is to avoid OS offerings. Some people will do them, and that's good, and I hope they get used too. If we do, in fact, get to a place where one can drop in various bits and have them work reasonably together, sans OS, it's going to have some nice appeal in how lean that can be. And by lean, I mean people not needing to know stuff to get other stuff done as well as small kinds of lean.



  • AleAle Posts: 2,363
    The Oberon system seems quite well suited for something like a "self contained P2 development plaform". The only drawback is the lack of an oberon compiler, any. The language seems similar enough to pascal, maybe one could modify p2c to get something going. One needs just the compiler to RISC5. It is a one cycle processor with floating point. Niiiice! It can do 41 MHz on the CV. I'll have a look at p2c, it may be a starting point (translating the compiler to C or Python crossed my mind too, alternatives) :)
  • AleAle Posts: 2,363
    I found this document Using p2c to convert a large pascal source, it may be better to convert it manually... the oberon libraries are missing !!!
  • yetiyeti Posts: 818
    edited 2015-08-18 06:32
    Ale wrote: »
    The only drawback is the lack of an oberon compiler, any.
    There are lots of Oberon compilers scattered around the net.

    Why not Project Oberon itself?

    The RISC5 emulator compiles without problems (on Debian8), a windowish binary is available, http://www.projectoberon.com/ has a diskimage for it and all the sources are available.
  • jmgjmg Posts: 15,173
    Ale wrote: »
    The Oberon system seems quite well suited for something like a "self contained P2 development plaform". The only drawback is the lack of an oberon compiler, any. The language seems similar enough to pascal, maybe one could modify p2c to get something going. One needs just the compiler to RISC5. It is a one cycle processor with floating point. Niiiice! It can do 41 MHz on the CV.....

    My reading was they had ported the Code generator in the Compiler (written in Oberon) to the RISC5, so it already self-hosts on a modest sized RISC5 system.

    The choices from there, would be to either emulate RISC5 in P2 (likely to be slow), or change the Code Generator back-end to emit P2 code (assembler ?)
    That back-end morph could be done in stages, with a coarse-macro-like in-line mapping/'emulation', and then a more tuned design.



  • AleAle Posts: 2,363
    edited 2015-08-24 09:31
    I would like to try this oberon project but either I don't find how to start or I don't find a suitable oberon compiler.
    All source-code has been written in Oberon, super... then I'd like an oberon compiler for win32, linux or mac osx. I understand this is a self-contained system but... I cannot even compile this thing on my pc.
    Does anyone had tried this ? (and not failed).
    I tried XDS... :(, not plussed

    I think that I understand the problem here... this is a self-contained-compiler-in-its-own-os ! in the sense of self-contained. I didn't look at the source and thought that the compiler was portable, it is not. :( not double-good-plussed :(
  • hover1hover1 Posts: 1,929
    Ale wrote: »

    Did you know all the propeller.wikispaces.org links are dead?
  • rosco_pcrosco_pc Posts: 464
    hover1 wrote: »
    Ale wrote: »

    Did you know all the propeller.wikispaces.org links are dead?

    look here: https://github.com/rosco-pc/propeller-wiki/wiki
  • jmgjmg Posts: 15,173
    Ale wrote: »
    I think that I understand the problem here... this is a self-contained-compiler-in-its-own-os ! in the sense of self-contained.
    Yes, that is exactly the point, and why is has appeal for possible P2 use
    Ale wrote: »
    I didn't look at the source and thought that the compiler was portable, it is not. :(
    Oberon is portable, there are a number of Oberon Compilers.
    - but the Oberon code generator inside Project Oberon has a code generator customised for the RISC5 MPU it runs on.


    Here is a post about a PC hosted RISC5 compiler, for Project Oberon
    http://www.cfbsoftware.com/astrobe/RISC5Register.aspx

    The approach of this last reference is slightly different, rather than self-hosting, which pushes most other MCUs, this version looks to remove some elements (editor/compiler/fonts) to make a system more like the usual Deeply Embedded MCU PC-Hosted, cross development environment.
    (and it allows a smaller, cheaper FPGA)

    In the case of P2, there is no smaller cheaper version, - either the Project Oberon can compile & run inside the 512K, or it cannot.

    All of this should run on a P2 : GUI, display, VGA, mouse, keyboard, compiler, editor.

    It makes great P2 app, because here P2 competes with FPGAs, not other MCUs.
  • MGreimMGreim Posts: 114
    There is a free Oberon -> C compiler

    https://github.com/norayr/voc

    Would be interesting how the Propeller GCC would handle the output.

    There is also a version generating directly RISC5 code


    Regards

    Markus
  • jmgjmg Posts: 15,173
    edited 2016-01-18 06:12
    I missed this article in December, quite interesting comments on
    http://www.theregister.co.uk/2015/12/02/pi_versus_oberton/

    Not the ironic typo in the header, they are not sure what this is called, but they know it may be important :)
    But what it shows is that complete, working, usable operating systems – not single-trick ponies – can be built, essentially single-handed, and can be understandable by ordinary mortals.

    Software like that is what will revolutionise teaching for the next generation or two.
  • D.PD.P Posts: 790
    jmg wrote: »
    I missed this article in December, quite interesting comments on
    http://www.theregister.co.uk/2015/12/02/pi_versus_oberton/

    Not the ironic typo in the header, they are not sure what this is called, but they know it may be important :)
    But what it shows is that complete, working, usable operating systems – not single-trick ponies – can be built, essentially single-handed, and can be understandable by ordinary mortals.

    Software like that is what will revolutionise teaching for the next generation or two.

    Yep I'm one of those who has worked in Pascal, Ada, Modula-2, and Delphi. I'm a Wirth fan boy I guess.

  • potatoheadpotatohead Posts: 10,261
    edited 2016-01-18 08:20
    Chip used Delphi when developing stuff for the P1. It's a pretty sweet environment, well designed, efficient, clean.

    Oh, the Register! Thanks for linking them JMG. I've not been there for a while, but I do fondly remember their, BOFH series. :) Good stuff. Google it.

    Frankly, I agree with them on the scope of Oberon being appropriate for "whole computer" type learning. That scale we left in the 16 bit era was just a great scale. It's entirely possible for one person to completely understand those machines. The 8 bitters, even more so, but they are just a shade too tiny to be relevant for all but a few niche cases.

    One nice thing about the P2, as it's shaping up, is you really don't need an OS for a lot of things. Right now, I'm about half way through a nice little project, and it's all PASM. (Haven't yet setup Dave's C tools) What I'm noting is the additional "room" in the P2 is significant. The project I'm doing would be a nice effort on a P1. It's going to just touch the surface of the P2, and not having anything but PASM isn't that big of a deal right now. Surprisingly. (and yes, I and many of us know PASM, so that helps, but it's just not that big of a leap as assembly language can so often be. Ordinary mortals, of which I am absolutely one, can do this, and in my book, that's damn cool.)

    The thing has all those COGS. There is nice math on chip, if you need it. PASM works in COG or HUB mode, allows for mixed, in-line constants, data, etc... It's possible to just write code, and not worry about a lot of things.

    We have lost a little of the super clean nature of the P1, but the gains are totally worth it!

    Getting a lot of things to happen at one time, sans an OS, is a big deal.

    I can see something like Oberon making for a great little computer setup. Just enough of an environment to manage basics, pictures, applications, text, build, display, plot, capture, store, network, interact.

    Honestly, a lot of people are gonna go for their fave, C or SPIN, and just build stuff and run it on the thing. Fine. That's what it's being made for. Some people are going to self-host and explore that part of things, and PASM is likely the on chip solution. Use that, bootstrap something a bit bigger, and that's Oberon, or some BASIC / OS looking thing one layer above just making a program and running it.

    Sure looks like we are almost done. Hope so. I sure feel some great times are ahead for everyone.

    Has anyone run the Oberon thing? I haven't yet. Oberon seems to be getting just a little attention, but not quite enough for me to sink some time into just yet. Maybe soon... when we can put it on this chip, or the FPGA when the next stage, booter, etc... are complete.
  • rod1963rod1963 Posts: 752
    Oberon on the FPGA was meant as a teaching tool to show students how little in the way of resources one could build a functional system. Yes it can be extended since the source is open and available. It does take a bit of getting used to.

    I originally used Oberon back when Wirth just introduced it, ran it on the Atari ST and a 286 PC. I was amazed at the time such a unified system could be made to work and not be a resource hog like Windows. The whole system fitted on a 1.44 MB floppy. BTW images for those still can be found on the internet and tried out.

    Programming wise it's like Delphi but simplified.
    http://www.astrobe.com/Oberon.htm

    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. But if you like FPC or Delphi you'll like Oberon.

    Right now I program ARM micros with Oberon.
  • potatoheadpotatohead Posts: 10,261
    Are you using the Oberon system, or just the language somehow?
  • ErlendErlend Posts: 612
    A few months ago I read up on Oberon - triggered by an earlier thread here. What I read made me think that this language was just a Swiss curiosity, and that to get Oberon as an alternative to Spin would be an impossible dream. In my former life a used Delphi a lot, and I still miss it. Oberon seems to have that same feel to it. Getting oberon for P2 would be exciting, I think.

    Erlend
Sign In or Register to comment.