THe interesting thing will be handling C structs. As almost every
interesting C API makes heavy use of them.

My wish list would be to be able to create them from inside pico and
use them just like a native object. IE pass them arround as the values
of symbols and use 'get' and
'put' to read and write their fields.



2008/10/17 Alexander Burger <[EMAIL PROTECTED]>:
> Hi Eugene,
> 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
> appropriately.
> A slight disadvantage compared to your proposal is some runtime
> overhead, though. Let's see ...
> Cheers,
> - Alex
> --

Reply via email to