Shop OBEX P1 Docs P2 Docs Learn Events
Porting/writing a Spin compiler to baremetal Raspberry Pi/Ultibo — Parallax Forums

Porting/writing a Spin compiler to baremetal Raspberry Pi/Ultibo

As I can understand, the only opensource Spin2 compiler available is Flexspin (or is there any else?)

What I want is to port a Spin(2) compiler to Ultibo environment on RPi. This will allow to connect P2 to RPi making a hardware independent from any other PCs and operating systems.

The Ultibo is a Free Pascal based environment for bare metal RPi programming. It allows to link static compiled C code as a library, if it doesn't depend on something other than libc/libm

As I can see, Flexspin is C (good...) but it is complex and have dependencies (Bison?) (bad...)

To make this work with Ultibo I have to (1) get a compiler source (2) simplify it to get rid of dependencies, if possible, (3) add a few functions to interface with Ultibo code.

The second way may be writing a Spin compiler for Ultibo from scratch in fpc.

At the moment I don't know which way can be simpler. Writing a compiler is a complex task but getting rid of dependencies in a big piece of foreign code can be even harder.


Comments

  • David BetzDavid Betz Posts: 14,511
    edited 2020-12-20 13:23
    Bison just takes a grammar description and converts it to a C function to parse the grammar. You could run bison on a PC and then compile the resulting C code on your target machine. You'd just have to modify the Makefile to separate out the bison step from the rest. What tools does your platform support? Does it have make?
  • pik33pik33 Posts: 2,350
    edited 2020-12-20 19:02
    No, I haven't make on the target system.

    This is freepascal/Lazarus based bare metal environment for RPi 0..3 called Ultibo ( www.ultibo.org). You can compile a source code on Linux or Windows machine including the Raspberry Pi. The result is kernel7.img file which you can put on a SD card with RPi firmware and it starts without any OS in less than 5 seconds. There is no OS, but there is filesystem and multitasking support in it.

    Ultibo supports C compiled libraries if only they have no dependencies other than libc/libm. They can be compiled on Linux powered RPi. It doesn't support C++. I can then attach the compiled library, make the interface code and tell the linker to link it.

    I ported. for example, mp3 decoder library libmad to Ultibo. The hardest thing to do with it was getting rid of all the stuff which outputs logs, error descriptions and all other stuff using and depending on several standard Linux libraries which I haven't in Ultibo and this stuff has nothing to do with the main task: get an mp3 frame and output decoded audio samples.

    After stripping the library from all this stuff it worked (and I have a bare metal mp3 player on RPi which starts immediately and I can switch the Pi with the power switch at any time).

    To port a command line compiler this way I need to rename its main(argc,argv) to a "non-main" function, for example int compile(arguments). Then get rid of all code not necessary for the compilation: verbose output, logging, error processing, etc) - if possible. Then compile it as a library and link it with the rest of my program.

    To start this I need a Propeller board first (I am waiting for delivery of P2 development board and accessories set) and then some time to try to connect it to RPi and experiment with coding. The board was ordered 3 weeks ago, maybe a santa Postman will bring it before Christmas.

  • pik33 wrote: »
    After stripping the library from all this stuff it worked (and I have a bare metal mp3 player on RPi which starts immediately and I can switch the Pi with the power switch at any time).

    I've recently been considering integrating/building a car PC to play music using a RPi, but the lack of true sleep mode and slowish boot always turned me off. I'm interested, how fast does your custom system boot up from power on to begin playing?
  • Wuerfel_21Wuerfel_21 Posts: 4,522
    edited 2020-12-20 22:59
    rogloh wrote: »
    pik33 wrote: »
    After stripping the library from all this stuff it worked (and I have a bare metal mp3 player on RPi which starts immediately and I can switch the Pi with the power switch at any time).

    I've recently been considering integrating/building a car PC to play music using a RPi, but the lack of true sleep mode and slowish boot always turned me off. I'm interested, how fast does your custom system boot up from power on to begin playing?

    You can also get fast booting with normal linux. Just don't use the default OS. Barebones distros like Arch boot very quickly. Still not as fast as bare metal firmware, obviously.
  • Yeah the baremetal thing is interesting. I like the idea it might be turned off at any time like we used to in the old days and not corrupt the filesystems too. There's probably stuff you could do with read only filesystems and ram filesystems etc to try to enable this even in linux but it might be a bit of messing about to setup (as is common with many linux things).
  • One thing you might be able to include is the new Spin2 debug stuff, written in Pascal.

    OpenSpin is a compiler for Bytecode for P1, written in C and open source. Does not support P2.

    FlexSpin is the cmd line compiler used by FlexProp, the GUI needs TCL that might not work on bare bones, but the compiler itself could be doable.


    Enjoy!

    Mike
  • pik33pik33 Posts: 2,350
    edited 2020-12-21 07:26
    how fast does your custom system boot up
    About 5s from switching on. Can be even shorter if define boot_delay=0 and disable rainbow splash. In the real life the LCD monitor boots slower than this.

    The (very messy) stuff is here: https://github.com/pik33/ultibo_retro_gui - it contains near all things I started and finished - or not finished and left as it it - for Ultibo - including 6502, SID and OpenGL testing stuff. I have to clean it up.
    I like the idea it might be turned off at any time

    Of course if your program doesn't write on SD itself. The player only reads. You can even pull the SD out when system is up and insert another SD, it will be automounted and visible. There is no system - It is your RPi :)
    One thing you might be able to include is the new Spin2 debug stuff, written in Pascal.

    If the source is avaliable, and it is Pascal, then porting this should be easy
  • Cluso99Cluso99 Posts: 18,069
    pik33 wrote: »
    One thing you might be able to include is the new Spin2 debug stuff, written in Pascal.

    If the source is available, and it is Pascal, then porting this should be easy
    It's in x86 assembler :(
    Not sure if PropTool is using the x86 code tho.
  • Cluso99 wrote: »
    pik33 wrote: »
    One thing you might be able to include is the new Spin2 debug stuff, written in Pascal.

    If the source is available, and it is Pascal, then porting this should be easy
    It's in x86 assembler :(
    Not sure if PropTool is using the x86 code tho.
    The Prop Tool is not written in x86 assembly. It's written in Delphi.

  • Not entirely true, a lot of it is 386 assembler written by Chip.

    Even the debug stuff contains a parser in assembly, but according to chip that might be able to be rewritten in pascal itself since it is just simple string parsing.

    Mike
  • Cluso99Cluso99 Posts: 18,069
    David Betz wrote: »
    Cluso99 wrote: »
    pik33 wrote: »
    One thing you might be able to include is the new Spin2 debug stuff, written in Pascal.

    If the source is available, and it is Pascal, then porting this should be easy
    It's in x86 assembler :(
    Not sure if PropTool is using the x86 code tho.
    The Prop Tool is not written in x86 assembly. It's written in Delphi.
    I thought that while the GUI is in Delphi, the actual compiler code is in x86. IIRC Roy converted the P1 x86 compiler code to C for OpenSpin.
  • pik33pik33 Posts: 2,350
    Why not switch to Lazarus then? It is free, it is multiplatform and it is Delphi compatible. The Propeller tool can be then available for all x86 systems.

    The assembly code has to be translated for ARM then...
  • Cluso99 wrote: »
    David Betz wrote: »
    Cluso99 wrote: »
    pik33 wrote: »
    One thing you might be able to include is the new Spin2 debug stuff, written in Pascal.

    If the source is available, and it is Pascal, then porting this should be easy
    It's in x86 assembler :(
    Not sure if PropTool is using the x86 code tho.
    The Prop Tool is not written in x86 assembly. It's written in Delphi.
    I thought that while the GUI is in Delphi, the actual compiler code is in x86. IIRC Roy converted the P1 x86 compiler code to C for OpenSpin.
    True. The compiler itself is what is written in x86 assembly. The IDE is not. Neither is PNut if I'm not mistaken. It's just the actual compiler that is in x86 assembly. One could imagine a version of the P1 Propeller Tool that used OpenSpin instead of Chip's x86 assembly code. Unfortunately, there isn't an OpenSpin2.

  • Cluso99Cluso99 Posts: 18,069
    edited 2020-12-22 11:53
    David Betz wrote: »
    Cluso99 wrote: »
    David Betz wrote: »
    Cluso99 wrote: »
    pik33 wrote: »
    One thing you might be able to include is the new Spin2 debug stuff, written in Pascal.

    If the source is available, and it is Pascal, then porting this should be easy
    It's in x86 assembler :(
    Not sure if PropTool is using the x86 code tho.
    The Prop Tool is not written in x86 assembly. It's written in Delphi.
    I thought that while the GUI is in Delphi, the actual compiler code is in x86. IIRC Roy converted the P1 x86 compiler code to C for OpenSpin.
    True. The compiler itself is what is written in x86 assembly. The IDE is not. Neither is PNut if I'm not mistaken. It's just the actual compiler that is in x86 assembly. One could imagine a version of the P1 Propeller Tool that used OpenSpin instead of Chip's x86 assembly code. Unfortunately, there isn't an OpenSpin2.

    I think pnut is totally x86 assembler - it's the P2 compiler. If not, then it's only the IDE that's not.
    There was a lot of discussion about wanting Chip to write the P2 compiler in other than x86 but it never happened.

    Don't expect to see OpenSpin2 from Roy. His work was almost wasted.
  • Cluso99 wrote: »
    David Betz wrote: »
    Cluso99 wrote: »
    David Betz wrote: »
    Cluso99 wrote: »
    pik33 wrote: »
    One thing you might be able to include is the new Spin2 debug stuff, written in Pascal.

    If the source is available, and it is Pascal, then porting this should be easy
    It's in x86 assembler :(
    Not sure if PropTool is using the x86 code tho.
    The Prop Tool is not written in x86 assembly. It's written in Delphi.
    I thought that while the GUI is in Delphi, the actual compiler code is in x86. IIRC Roy converted the P1 x86 compiler code to C for OpenSpin.
    True. The compiler itself is what is written in x86 assembly. The IDE is not. Neither is PNut if I'm not mistaken. It's just the actual compiler that is in x86 assembly. One could imagine a version of the P1 Propeller Tool that used OpenSpin instead of Chip's x86 assembly code. Unfortunately, there isn't an OpenSpin2.

    I think pnut is totally x86 assembler - it's the P2 compiler. If not, then it's only the IDE that's not.
    There was a lot of discussion about wanting Chip to write the P2 compiler in other than x86 but it never happened.

    Don't expect to see OpenSpin2 from Roy. His work was almost wasted.
    Chip's compilers are always in x86 assembly language. The IDEs are not. I guess I'm not absolutely sure about PNut but I'd be willing to bet that it's in Delphi.

  • pnut is a delphi application wrapped around the x86 compiler guts.
    The x86 part is the same between pnut and proptool. The compilation process does a fair bit of back and forth between the delphi parts and the x86 parts of the code.
  • Did Chip open source PNut and/or PropTool? If so, I missed that. If not, then any discussion of porting the code from x86 to the RPi is moot.

    OTOH flexspin/spin2cpp is already written in C, is open source, and runs on multiple platforms including the Raspberry Pi. Porting it to Ultibo will surely be easier than porting a bunch of x86 assembly code.
Sign In or Register to comment.