[Contents] [TitleIndex] [WordIndex

1. Scilab function variables: representation, manipulation.

Functions in Scilab are stored as variables in the stack. Apparently, functions are generated from parsing scilab textual code by a process called "compilation", which seems rather to be a translation in a condensed, tokenized internal representation (called improperly pseudocode).

There is no published description, neither of the parsing of the function text which produces the function pseudocode nor of the storage conventions and implications. It is not clear to me whether this reflects an unstated intention of keeping the innermost proprietary details of scilab deliberately cryptic, or is just a result of the development history of Scilab.

Nevertheless, a better understanding of the works of the parser, and its way of storing and perusing code data, would be beneficial for any attempt of designing or improving modern Scilab code tools - like a lexer, a profiler, a debugger, a cross-compiler, a code differentiator, and so on.

What follows are a few personal deductions, for reference.

There are two sorts of functions: compiled (type 13) and compiled with provisions for profiling (type 13 as well).

The basis for the storage seems to be a header, detailing function type, input and output arguments and size, and a function body stored as pseudocode (type 13). Some of this information can be conjectured from help save_format, as it is likely that, for economy, the binary scilab files are essentially a dump of the stack structures. Historically, once upon a time function variables were stripped of the comment text in the function definition; now comments are preserved and stored along.

In all cases, the function body seems to be organized in elementary chunks corresponding to individual code lines. Both breakpointing and profiling operate with such a granularity.

Functions compiled for profiling apparently differ from those "just compiled", in that two extra words are added per function line (this is roughly deducible from the function size reported by who). I figure out that one of such words is for storing a cumulative call count, while the second for storing the cumulative time spent. Besides that, profilable functions are compatible with breakpointing (the time spent waiting for user input at the breakpoint is even *not* cumulated in the timing, correctly); the impact of making a function profilable on the performance seems at all negligible.

There are few Scilab functions providing some degree of access to the function types, and the possibility to manipulate them. These are:

1.0.1. Interfacing with files:

1.0.2. Operating on functions, or producing functions:

1.0.3. For the m2sci suite:

The format of a tlist of type "program" is:

The couple tree2code(macr2tree) used to be at odd with particular syntax constructs, which are gradually sorted out.


2022-09-08 09:27