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. regs Konrad 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 > -- > UNSUBSCRIBE: mailto:[EMAIL PROTECTED] > -- UNSUBSCRIBE: mailto:[EMAIL PROTECTED]
