thanks for your comments! :-)
> It would appear that you could claim portability to any CPU. Afterall,
> porting should only require writing a translator module for the
Well, not really any CPU. It should have a 64 bit word size, with 8 bits
per byte. And if it is a CPU that requires heavy instruction reordering,
the translator module might be difficult to implement.
> different instruction set. If anyone wants JVM or CLI then that should
> be what needs rewriting.
Yes, this would be an interesting exercise.
> As for the gcc.l, as.l, and the generic call to external libraries, I
> have a suggestion:
> 1. Shared libraries written in the normal manner (dlopen/dlsym
> A manifest file for each DL which lists the entry points, argument types and
> return value type.
I'm thinking of something similar. Not with a separate manifest file,
but with some encoding conventions in an s-expression, specifying the
types and layouts of arguments and return values.
This would allow to call almost any C function in an external library on
the fly. The calling mechanism itself would be the same as it is in
picoLisp-2.x, just with some glue functionality interpreting the encoded
information, and preparing the arguments and return values
A slight disadvantage compared to your proposal is some runtime
overhead, though. Let's see ...
UNSUBSCRIBE: mailto:[EMAIL PROTECTED]