nut 25  explain

This is a version 2.5  of nut package.  This package is the experiment on optimise the instruction for NOS.  This is done for som (as S2 will be too tedious to do).  The changes are

1)  no S2, delete as22, nut-s2
2)  modify nut-som to include some primitives
3)  modify nut compiler to have "inline"
4)  modify s-code to have "displacement" addressing mode to improve access to a field in the data structure.

The evaluation is based on running test-sum.txt on nos and profile only the system execution.

9 Feb 2005

how to compile macro?

(defm print (x) () (sys 1 x))

(def main () () (print 10))

normally the compiler translates

(print 10) =>  (call.print lit.10)
(sys 1 x)  =>  (sys.1 get.1)

now that "print" is a macro, its actual argument must be substitute into the "body" of definition.  A macro does not have its own activation record, it uses arguments directly from the stack. So when compiling a call to macro, the argument list is compiled as usual, but at the call.fun, the macro's body is generated inplace until "get.n", "get.n" denotes passing the actual parameter, the actual argument in the argument list is used instead of "get.n".

(print 10)  is compiled
1)  argument list  (lit.10)
2)  (sys.1 lit.10) instead of (call.print lit.10)

The experiments done on inlining code (using macro expansion) shows that it is very effective.  It is better than (by a small margin) using primitives. Read "profile-analysis.txt" and the raw data in "profile.txt", "profile2.txt", "profile3.txt".

the next experiment is about instruction set.  Introduce "inc lv" to do (set i (+i 1)), and conditinal jump for the sequence "Eq, jF" etc.  Then will look at the addressing mode to access data structure.

nos-som4.txt  uses !=, <=, >= as primitives because it produces better code.  (the macro produces surplus lit 0, lit 1, although they are correct but not good).  See for example nos-som3 at function switchp.