2008/7/5 Peter William Lount <peter at smalltalk.org>:
> Hi Igor,
>
> Very nice work Igor.
>
> What about special assembly language instructions for the various
> architectures? Such as test and set (for managing concurrency control)? How
> do you control the mapping to native code?
>
> By lambda, do you mean to say that you're doing this at the level of block
> closures rather than only the level of methods? Block closures being more
> general purpose so that the entire method need not be a "primitive". Never
> liked primitive methods... always thought that blocks were the better place
> to hang primitives - as well as a host of other capabilities - from.
>

Native methods , smalltalk methods , and block closures from ST
methods are compiled to common form: CompiledMethod.
A difference lies just in preprocessing style.
Compiled method always expects that arguments are passed via stack ,
but rest is up to implementor.
Compiler inlines code for method prologue/epilogue (code sits in
CVStackConext & friends), so if you don't like how its currently done,
you can always invent own stack layout & formats.
A polymorphic sends (Smalltalk method lookup & call) is implemented in
corresponding classes, and compiler just inlines this code with very
little assumptions about what code does.

> You mentioned you do byte code to native code conversion with Exupery. How
> does this work and how can one fine tune the generated code for the various
> architectures and calling conventions (for interfacing with ugly things like
> DLLs or Shared Libraries that static <as in frozen in time> system generate?
>

No, i'm not using byte codes at all. Translation performed from method
source to lambdas. Currently its using AST created by default squeak
Parser, but it will be replaced by own parser to translate sources
directly to lambdas. It already lies in package, written by Klaus, but
i didn't wired it up yet.

Interfacing with DLL's & other FFI stuff is up to implementor. Its as
easy as writing a code which does a call to address, stored in memory.
You can write such code yourself as:
result := someAddress call.
- generates a call to address = someAddress.

Maybe later, i'll add an foreign function callout code generator,
which will automatically generate code for arguments coercion &
pushing , and converting returned value. But its optional.

There are some nuances with returned values.
Currently it assumes that returned value is in eax, but its not true
for a C functions, which returning floats or 64 bit values on 32bit
platform.
It would require adding some special instructions later, like:

someAddress fcall: pointerForStoringFloat  " here you provide two
addresses: function pointer and pointer to memory location where
returned floating point value should be stored"

> How much work would it take to put the squeak code base upon a hydra
> rewritten in the new improved slang+exupery?
>

This project not related to Hydra.
The earlier you start writing it, the faster you'll get results :)
And if seriously, currently its a big playground. With freedom from C,
it opens a huge field of possibilities, how system can be implemented
from scratch.
Currently, there are only few bits, which make basic things working:
Context format, CompiledMethod format and VTable format to be able
perform polymorphic sends.

Low-level lambdas (the result of method compiling) are intentionally
platform independent. They assume you having a virtual CPU with
unlimited number of registers. Special register holding stack value ,
special register holding context value, and register for returning
value.

And i'm using Exupery for getting results fast. It lacks some
instructions (like working with byte-sized memory operands) and float
math support, but its not hard to add them later. Since 99% of code
already can work using current Exupery features, i don't think its a
big issue.
Its not using Exupery at full scale , only the last few classes
responsible for register allocation, instruction selection and
assembly.

> How many architectures does exupery currently support?
>

Well, originally it supports only i386. But i heard there are ports on ARM.
I think its not me who need to answer this question. Bryce knows
better about it. :)

> What are your plans on sharing your "lambda" code improvements?
>

Its free for any who may want to use it (MIT license). There a lot of
things which need to be done, before it can become a working system,
and amount of work to replicate such environment as Squeak, for
example is paramount for single man.
So i don't have an illusions that i could do it alone. But team of
people can do.



-- 
Best regards,
Igor Stasenko AKA sig.