Environment capabilities

The PicoC environment is given 128 KiB of memory, allocated on the stack of the Utilities add-in, used for all the PicoC objects. This region contains the stack used by PicoC scripts and internal PicoC objects necessary for script execution, like symbol names.

PicoC scripts can call any OS syscalls present in gbl08ma's fork of libfxcg, as long as they don't have function pointers as arguments or return values. Additionally, PicoC scripts can make use of the wide set of functions present in Utilities. These include:

• Functions to provide common UI elements, like menus, text inputs, and text areas;
• Functions for building those common UI elements, like sprite drawing and shape drawing functions;
• Helpers and wrappers for easier usage of OS syscalls, like a wrapper around PrintXY that automatically adds the necessary leading bytes in a safe way, or a GetKey wrapper that takes care of Utilities-specific key combinations, including the one used to open the settings menu;
• Functions used to provide and control the various features and tools of Utilities, including functions for dealing with date and time, settings, file management, and more.

From now on, we will refer to these functions as the Utilities Framework.

Calls to syscalls or Utilities Framework functions do not use the 128 KiB of memory dedicated to PicoC. They will use their standard stack and heap, with Utilities Framework functions allocating stack above (or below, in terms of memory addresses) the PicoC region. This is why the whole Utilities stack can't be given to PicoC: native functions need their stack to be somewhere.

PicoC scripts can't override Utilities Framework functions or system calls; Utilities doesn't offer any kind of hook system and doesn't call PicoC scripts except when the user executes a script.

Performance considerations

PicoC program execution is at least an order of magnitude slower than native code execution. Furthermore, unlike what usually happens with compiled code and certain interpreted languages, there is no optimization whatsoever. PicoC is really not well suited to performance-critical code.

As PicoC is an interpreter, it needs to hold the names of all symbols in memory. This means longer variable, macro and function names use more memory than shorter ones. Comments also slow code execution by a small amount. Of course, the lack of comments and indecipherably short names means the code becomes unmaintainable. Ideally, code would be "minified" for running while keeping development versions properly documented. Obviously, for small scripts, like those one could even write on the calculator itself, this is not a concern.

Finally, to execute scripts PicoC needs to load the whole contents of the files into memory. This means there is an upper limit to the file size of a script: 64 KiB. Again, code minification would help with fitting more program in less script.

Safety considerations

PicoC does is not and does not aim to be a sandboxed environment. Sandboxing scripts would heavily limit the possibilities it offers. This means that PicoC scripts can crash the calculator just like native code, and do even more catastrophic stuff like corrupt the OS or erase the bootloader, yielding a brick.

You should be careful when running scripts you do not understand. When developing, using an emulator can save you many headaches, while also reducing deployment and debugging time and avoiding Flash memory wear on your real Prizm.