Hi Tomas,

> I guess that miniPicoLisp is not 64 bit incarnation of future
> picoLisp-3 then?

Right, it is rather limited, and more of a design study than.

> What are the reasons for a) complete rewrite and b) switching from C
> to asm?

As Konrad noted, there is - due to the doubled word size - an additional
tag bit available, which allows things I wanted but could not do on the
32bit platform. This results in a slightly different tag layout, with
relative large consequences on the overall data structures.

This alone would not cause a "complete rewrite", though. The trigger was
the decision to switch back to assembly language. The first versions of
PicoLisp were written in various assembly languages, more than 20 years
ago, and in fact some things for such an interpreter are even easier to
do in assembly than in C.

I switched to C back then only for portability reasons, and now I hope
to slove that with the generic assembler described in anothter post.

Why is assembly better for writing a PicoLisp interpreter, and why are
some things even easier?

In C you have to go through a lot of trouble to direcly manipulate the
stack, for example. As you don't know in advance how long an evaluated
list will be, you want to 'push' things on the stack in a loop. Or you
need to align the stack pointer to certain boundaries so that the
pointer tags reflect the desired data type. Unwinding the stack is
tedious, possibly only with longjmp() and a lot of overhead. In assembly
this can be reduced to simple stack pointer arithmetics.

Or you don't have access to the CPU flags (the 'carry') for muli-
precision arithmetics.

Then I want to guarantee odd things, like that certain instructions
start at addresses in memory which are a multiple of 16 plus 2.

And assembly also has other advantages, like multiple arguments and
return values in registers, the possibility to directly return status
flag return values from functions, or have multiple function entry

But the killall criterion for me was simply that 64bit C compilers do
not support a number type of 128 bits, as needed, for example, as the
result of 64bit multiplications. This is really stupid. They defined
'long' as 64 bits, and 'long long' too!

- Alex

Reply via email to