Programming puzzles: processing lists!

[DavidM]

(04-25-2017 08:34 PM)pier4r Wrote:  Hold on....

...So, userRPL -> sysRPL -> saturn code (emulated) -> ARM code

I probably contributed to the confusion when I asked Claudio about an equivalent to a sysRPL "layer". In my own defense, I did use quotes.

Seeing the list you made above (with the arrows) leads me to believe that you may have the wrong impression of the relationship of user- and sys-RPL. They're actually just subcategories of commands in the larger set of RPL as a whole. Neither is subordinate to the other, though some might argue that userRPL is actually just a subset of sysRPL that defines a "safer" or "less type-specific" operating model due to the way those commands are implemented.

When the 50g kernel is executing a collection of RPL objects (aka a "program"), it doesn't care if the next object in the stream is one in the category of userRPL or sysRPL. It sees them in the same way, and just executes them one after the other in the same fashion. There's no further interpretation.

(04-25-2017 08:34 PM)pier4r Wrote:  When Claudio says "there is the inner layer of C code" it seems that the C code should be interpreted first, instead of being a binary.
Like: newRPL -> C -> ARM code

Am I mistaken?

I don't want to speak for Claudio, but he was probably using those terms because of the way I asked the question.

In my mind the more important part of his answer pertains to how the RPL loop in newRPL is used to process the list commands. It sounds like the newRPL kernel is executing the list-processing commands more like another newRPL subroutine (with their own sandbox to play in) as opposed to API library calls as is apparently done with most other commands.