Gabriel Dos Reis wrote:
> On Sun, Mar 30, 2008 at 2:27 PM, Waldek Hebisch
> <[EMAIL PROTECTED]> wrote:
> > Gabriel Dos Reis wrote:
> > > A long time ago, `OutputForm' tend to be called `Expression', e.g.
> > > equivalent to SExpression, until the difference was fully realized. If
> > you
> > > browse the Spad compiler source code, you should still find vestiges
> > > of that.
> > >
> > > I must confess I don't know to what extent your plan diverges from or
> > > converge to my plan -- a year ago -- to have a virtual machine for
> > > Spad (my slides are still on the web). But, it is interesting that I
> > > saw all those problems you're discussing and concluded that it was
> > > time to abandon Lisp as the virtual machine one compiles Spad to.
> > >
> >
> > I must admit that I do not understand what you really mean. Do
> > you mean that at conceptual level we should use different abstract
> > machine? Or maybe you mean literally re-targeting Spad compiler?
>
> I think I'm essentially suggesting to make the Spad compiler re-targetable at
> the conceptual level, and dropping the Lisp target in the long run.
> That implies
> a VM that has its own semantics (preferably very simple, easy to map to
> hardware to sustain interoperability with C, C++, Java, C#, or what
> have you codes).
>
Let me outline my conceptual model. We need garbage collected
imperative abstract machine with reference semantics. Basic operation
are assignment, flow control (sequence, conditonal, loops) and
function calls (possibly indirect). We need ability to define
top-level functions having local variables (no nested functions).
We also need global variables. And we want nonlocal control
transfer (offically not supported in Spad but done via Lisp
primitives). Basic data types are integers, machine floats,
arrays, pairs (lists), strings, symbols and function pointers.
We need also several primitive operations, but conceptually they
are just calls to predefined routines.
The set of core types is somewhat fuzzy: in principle instead
of symbols we could use integers and global symbol table. We
could use two element arrays as pairs. Or we could add a
structure type. Simlarely, without explicitly listing
primitives description is very incomplete. But I think that
what I wrote may work as a good conceptual model and is
easy to implement.
My conceptual machine is essentially untyped (dynamically typed
if you prefer such terminology). First class Spad types are mapped
to ordinary values. This requires no-trivial runtime support,
but the support routines are just ordinary functions -- no need
(except possibly for some low-level speed hacks) to have them as
primitives. To have efficient code we will have to propagate
type information from Spad to lower levels, but IMHO untyped
machine is correct as conceptual tool.
Currently Axiom/FriCAS/OpenAxiom supports runtime compilation to
machine code and dynamic (auto)loading. They are nice features,
but I would exclude them from conceptual model. Namely, autoloading
is mostly a space optimization. Runtime compilation is used
in the "interpreter", but the "interpreter" also can interpret
the code, so again, compilation is just an optimization.
So, at conceptul level thing are pretty simple. To turn this into
practice we need to get rid of (most of) Lisp forms from Spad
files. Which means that Spad compiler must know about core
spad types and handle primitive operations on them. Also, some
high level operations are handled rather late, when other
constructs essentially are in Lisp form -- we need to move them
earlier and write proper Lisp code generator. Of course we
need to build explicit list of primitives. And we need to
write language-specific runtime support (and factor out language
independent parts). To host Spad compiler on non-Lisp
targets we need to untangle current handling of types (currently
the compiler loads and runs compiled representation of types
to get runtime type representation, which in turn is used for
typechecking and code generation).
--
Waldek Hebisch
[EMAIL PROTECTED]
-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
_______________________________________________
open-axiom-devel mailing list
open-axiom-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/open-axiom-devel
