PRIME TIME

[Claudio L.]

(03-09-2016 08:36 PM)manjo Wrote:  When thinking about Saturn Vritual machine... I would not look to make it compatible, rather to "evolve" or further develop in the direction what Saturn processor would be if made today with both ARM and x86 archtectures in mind.

If made today, the Saturn would not be a Saturn, just another ARM system-on-chip. The tendency is to converge to a single architecture, so I'd guess the Saturn would follow the trend.

Question is: if you create a new, much evolved Saturn that is not compatible, you need a new ROM from scratch, written in Super-Saturn assembly. If you are willing to write from scratch, then why not code a math platform directly on ARM or x86? You don't need a Super-Saturn at all. I debated this for quite a while and reached the conclusion that it was best to go for userRPL compatibility and skip the Saturn.

(03-09-2016 08:36 PM)manjo Wrote:  Something similar and VERY interesting is the RPL/2 project
http://www.rpl2.net/

RPL/2 is exactly what I'm describing above: a math platform, rather than a virtual CPU.

Even more similar to a 50g (quite incomplete yet usable): newRPL
You should take a look at the internals, since I think it lines up with your way of thinking: it's essentially a VM core that executes bytecode. The bytecode is (within certain limits) entirely defined by libraries, so in theory you could write a library that executes Saturn assembly from within an RPL program. Even compiling (assembling) is done by the libraries, so it's perfectly doable.
It would actually be very cool if newRPL could compile and run Saturn Assembly routines to keep the old Saturn alive.

EDIT: First you would have to port newRPL to the Prime, should be doable but not exactly trivial.