On 05.09.2012, at 15:21, "MacArthur, Ian (SELEX GALILEO, UK)" <ian.macart...@selexgalileo.com> wrote:
> >>> Though... IIRC the Newton ROM presented some API in C++ (or ObjC?) based >> on the calling convention of some obscure obsolete compiler... so creating >> code to the same ABI might be, um, "tricky"...? > > >> Yes, it is tricky. I need interfaces between the Just In TIme compiler and >> the native code. Those interfaces convert from register notation into a >> correctly formed C+ call, also taking care of the return value. But all >> that has been working for a year now. >> >> The major issue is the extensive use of the MMU by Newton OS: a memory >> access fault can happen at any time. The JIT takes care of that very well, >> but native code would need to call the JIT, causing a recursion in the JIT >> system. > > > OK - that sounds even more complicated than I'd imagined though; I was just > envisaging something analogous to what the Haiku folk seem to have (at least, > as it seems to me) where they build with one ABI that matches the C++ > compiler that BeOS used, so that older code and existing BeOS binaries will > run, but they have an alternate ABI based on more recent C++ compilers that > presents "the same" API in a more "modern" way... and some sort of wrapper to > map the ABI's so that old code can run wrapped up on the new hosts, or > something... Ah, I see what you mean. The beauty of NewtonOS is, that there is almost no app out there that uses native code. All existing apps are compiled into NewtonOS byte code which can we already compile and run. So it is actually a bit less work because in the end we need "only" the modern API. _______________________________________________ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
