On Thu, Mar 14, 2013 at 7:20 AM, Esteban Lorenzano <esteba...@gmail.com>wrote:
> > On Mar 13, 2013, at 7:11 PM, Eliot Miranda <eliot.mira...@gmail.com> > wrote: > > > > On Tue, Mar 12, 2013 at 7:54 PM, Igor Stasenko <siguc...@gmail.com> wrote: > >> On 12 March 2013 19:44, Eliot Miranda <eliot.mira...@gmail.com> wrote: >> > >> >> > 3. Pharo has forked the VM to include a) NativeBoost and b) ephemerons >> and >> > c) new FileSystem primitives. >> > a) is cool, but I don't like the x86 specificity. I want a >> cross-platform >> > FFI, so I'm not excited enough to include NB in my port. >> >> Just let me remind you that (x86 specificity) is completely on image side. >> The VM side changes are minimal and 100% not platform specific. >> Making NB image-side implementation platform-unspecific is another story.. >> but as i said before i see no reason to do it unless there's a version >> of Cog which runs >> on some other platform :) >> > > I understand that. I think Squeak should provide a platform-independent > FFI at the image level. > > >> >> There is plans and some work started on getting there, by making a >> platform-neutral low-level >> DSL, which can be used for generating native code. >> > > This is called RTL ;) > > > I never hear about it... you mean > http://en.wikipedia.org/wiki/Register_transfer_language ? > If so, looks interesting :) > Yes. RTL is essentially an assembler for an abstract machine with readable names for registers. Arguably the Cog back-end assembler is an RTL. It has abstract registers (ReceiverResultReg, ClassReg etc), and abstract operations (e.g. MoveR:R:). To do marshalling you need only define argument registers (floating-point and integer, an empty set on the x86), return registers, the stack pointer, and maybe the frame pointer, plus a basic set of data manipulation instructions. Then either define these as numeric constants so that the JIT interprets sequences of numbers, or strings, so that the JIT uses string matching (the former is of course faster and slimmer). The JIT maps these abstract instructions and register names into concrete machine code and register numbers. Note that the RTL still has platform-specific constructs, e.g. a LinkReg is valid on RISCs but meaningless on x86, and the ABI-to-RTL compiler has all the knowledge about the format of outgoing calls, what kinds of registers are available (address, data, floating-point, etc). But it does not have to do the final assembly step, fixing up branches etc. This is low-level work the JIT already does and needs to do itself because it knows at what addresses code is generated at. P.S. that wikipedia page is rather poor. Another example other than GCC's is Ralph Johnson's and Carl McConnell's "The *RTL* System: A Framework for Code Optimization<http://www.google.com/url?sa=t&rct=j&q=ralph%20johnson%20rtl&source=web&cd=3&ved=0CEQQFjAC&url=http%3A%2F%2Fciteseerx.ist.psu.edu%2Fviewdoc%2Fsummary%3Fdoi%3D10.1.1.50.6632&ei=Hw9CUcWyGJKkqQGj3YGAAw&usg=AFQjCNGoQxB5uhsnqCm-yUr9_ihxu2iODA&sig2=lex4YodEuPolzf3ezZ8t8g&bvm=bv.43287494,d.aWM> ". > Esteban > > > >> >> -- >> Best regards, >> Igor Stasenko. >> >> > > > -- > best, > Eliot > > > -- best, Eliot
