Why Oberon for the Prop2 ?

Comments

• markmpx Posts: 28

  2018-12-12 05:51

  Why Oberon for Propeller 2 ?
  
  For those not familiar with Project Oberon i suggest a quick look at the following github repo
  https://github.com/pdewacht/oberon-risc-emu - there are plenty of links there to follow.
  
  
  1. I need a learning exercise for the P2, and for me its a fun project.
  2. There is considerable similarity between Wirth's Risc5 cpu and the Prop2, making the Prop2
  and ideal target for the Oberon 07 compiler. Hopefully close to a 1 to 1 correspondence
  between Risc5 (NOT to be confused with Risc-V) and Prop2 machine instructions. Oberon 07
  code, while NOT optimized is typically quite fast.
  3. The Prop2 is capable of replacing all the hardware of "Project Oberon" using a single chip.
  (yes, it only has 512 Kb memory instead of the 1024Kb assumed by project oberon, but hopefully
  parallax will produce version of the Prop2 chip with more memory) .
  4. Project Oberon hardware on Risc5 runs typically at 25-50Mhz. Prop2 is WAY faster at 180Mhz.
  5. Some people still use Risc5 Oberon because they need the software to be deterministic. Whilst Oberon
  has been ported to ARM,MIPS etc etc - these platforms tend to loose their ability to be deterministic.
  More modern cpu's with big instruction and data caches can be fast until they get a cache miss and
  then your instruction may take hundreds of clock cycles to execute. Interrupts make this worse.
  This is a real problem for certain types of applications.
  Prop2 is FAR more deterministic than ARM, MIPS etc
  6. Prop2 hardware seems interesting, heaps of things i want to try !
  
  It is not my intention to have any debate about the relative merits of Oberon vs C vs C++ (or whatever).
  Feel free to ignore anything in this thread that you disagree with.
  I do unfortunately, have strong opinions on certain subjects, and its possible i could express them in this thread. Please feel free to ignore my opinions, because at the end of the day, they are only my opinions.
  
  Just so you know, things i believe
  
  C is ok (have written millions of lines of it, hate that its too easy not shoot yourself in the foot, hate the syntax)
  C++ is horrible (but i use it when i must)
  Assembler is great
  Debuggers are rarely needed, that what printf is for !
  Speed, efficiency and determinism is good.
  The smallest program to do the job is always best
  and my favorite editor is vim
  
  For any of you who are interested in Oberon 07, feel free to ask anything.
  
  My apologies for such a long post, i will keep them much shorter in future
  
  Mark
• ersmith Posts: 5,909

  2018-12-12 09:33

  Welcome, @markmpx! Your project sounds pretty neat. Definitely porting a compiler is a good way to learn an instruction set .
  
  I'm curious, does the Oberon compiler produce binary or assembly code as output? If the latter, you may want to take a look at Dave Hein's p2asm assembler for P2, which is a small and clean assembler. fastspin works too, but it's probably overkill to drag around the Spin/BASIC/C compilers just to parse assembly language .
  
• Ym2413a Posts: 630

  2018-12-12 17:04

  Welcome Mark!! : ]
  
  Oberon is a word that pops up around here from time to time.
  
  Also I 99.5% agree with the things you believe.
  
  C++ is horrible,
  Assembler is great!
  C can help you shoot your foot off faster. (but I like the syntax though) : P
  Smaller code is better code.
  VIM!
  
  
• jmg Posts: 15,144

  2018-12-16 19:49

  markmpx wrote: »

  ...
  
  I do have a large amount of experience with writing/modifying compilers, but not C compilers.
  Most of my compiler experience is with the Wirth type compilers. (eg: Pascal, Modula, Oberon family)
  ..
  Short term, i need experience on the Prop2, i never used the P1. To write a compiler backend requires
  an intimate knowledge of the instruction set/architecture. I will get this experience with Prop2 by writing
  a new back end for the latest version of the Oberon 07 Compiler to target the Prop2.
  ..
  I am impressed by some of the posted assembly code that the fastspin/C compiler can produce ! Now if
  that was combined with all the optimizations gcc can produce ...
  ...

  
  

  markmpx wrote: »

  
  I expect to port Wirth's Oberon compiler to Nim and then modify it to produce P2 object code directly. (google nim-lang)
  My preferred development environment is Ubuntu, but Nim is available on windows, mac etc, (ie: almost anything)
  The Nim compiler produces C/C++ source code and a C compiler produces the object code, so effectively the Oberon P2
  compiler is a C program. I expect to port a minimal set of the Oberon runtime and i expect i will have to write a linker
  (as the oberon system does this dynamically at runtime).

  
  That seems like many steps, and many on rarely or not-yet travelled pathways ?
  
  Since you mention fastspin, why not target one of the languages that the fastspin language suite does support, as a 'stepping stone' ?
  
  http://forums.parallax.com/discussion/168913/new-basic-compiler-for-prop1-and-prop2/p1
  http://forums.parallax.com/discussion/164187/fastspin-compiler-for-p2/p1
  
  You could look at using any subset of those as a cleaner assembler for P2 - I think they all allow in-line ASM too, so you can start easy, and optimize as needed.
  You also then piggy-back on the optimize that fastspin does.
  
  Most generated-language code is a severe subset of the language, so you could also try the C side of fastspin, it might be good enough already, for gode generator use ?
  
  Other work that may be usable :
  https://forums.parallax.com/discussion/164401/porting-the-oberon-compiler-orp-to-the-p2
  
  
  
• markmpx Posts: 28

  2018-12-17 01:14

  jmg:
  
  Thanks for your comments, i shall read thru the other threads and comment after
  i have digested them in full.
  
  Thanks also for the link to a previous attempt at this.