Re: Your ASM generator

Previous Topic Next Topic
classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view

Re: Your ASM generator

Igor Stasenko
I CCed our discussion to exupery board. Want to hear what Bryce thinks too :)

On 31/07/07, Jason Johnson <[hidden email]> wrote:

> On 7/31/07, Igor Stasenko <[hidden email]> wrote:
> > On 31/07/07, Jason Johnson <[hidden email]> wrote:
> >
> > Not at all! Idea is good. I didn't seen a need for macros - as you may
> > know i'm focused on using code inlining. In most cases with use of
> > inlining we can achieve same results as with macros , because inlining
> > have same semantics: expand inlined code at call place.
> But does it evaluate it first?  One popular example from Paul Grahams Common
> Lisp book is a macro called "random_choice".  You call it like:
> (let direction (random_choice (:east :west :north :south)))
> And what actually gets expanded into the code is like:
> (let direction (condition (random 4)
>                       ((1) (:east))
>                        ((2) (:west))
>                       ((3) (:north))
>                       ((4) (:south))))
> That is, the compiler sees the use of the macro, calls it with the options
> given, the random_choice macro looks at the number of arguments it received,
> outputs a call to random for that number and sets up the conditions so that
> each possible number will pick one of the choices.  So it's better then what
> I know as inlining, it allows you to use functions (built in, or what you
> have written) to make writing new code more concise and clear without the
> runtime overhead of functions.

>From that point , writing:  'register message' is same thing as macro,
but its evaluated in smalltalk code for generating an intermediate
For example i can add a #toSmallInt selector, so writing:
reg toSmallInt will lead to generate following intermediate:

sal reg  1
inc reg

Lambda argument replacement can be done in smalltalk code (just by
writing new method in AsmSelectors), everything else can be done using
I agree, this is not so elegant as lisp macros, because you need to
write code in different domains to get what you want.

> > I planned to make calling conventions support as hard-coded feature,
> > but now i see, that by using macros it can be implemented on asm
> > (using some special syntax), except one thing: how to tell compiler
> > that upon return , the result will be stored in CPU register (eax for
> > x86), so it will know how to deal with result later?
> I had planned to have a different macro for defining functions depending on
> how they behave.  For example, if wanted to create functions that can be
> called from C code we might define them with:
> (def-c-function myCfunction (...))      "has cdecl
> Returning via eax would probably be the default:
> (def myFunctionReturnsFromEAX (...))
> With a stack:
> (def-stack-function my-stack-function (...))
>  etc.
> > Some of your ideas interfere with Exupery. They will need a more
> > advanced assembler compiler than Exupery currently have to make some
> > things doable :)
> >
> What parts will be problem areas?

Ironically, but Exupery have printable intermediate forms which
already looks like a lisp code:
#(#(#block 1 #(#push #ebp) #(#mov #esp #ebp)) #(#block 3 #(#mov #(-4
#ebp) #eax) #(#mov #(-8 #ebp) #ebx)) #(#block 5 #(#sub #ebx #eax))
#(#block 4) #(#block 6) #(#block 2 #(#mov #ebp #esp) #(#pop #ebp)

- remove '#' and see what we got :)

Exupery already having a number of optimizers which manipulating with
intermediate. I think that for getting full potential of lisp
macros/optimization schemes you will need to implement them on lisp.

> > I liked your idea of using macros. Just one thing: i want to stick
> > with smalltalk syntax. Because of 2 things:
> > - introducing new syntax will require to implement own parser
> Parser no, there is already a Lisp parser called Lisp kit.  It will handle
> the parsing and the common lisp example will have the macro handling in it.
> So it would just be mostly a matter of defining lisp macros for what we want
> and defining the primitives to be the assembly intermediate.

> > - using other than smalltalk syntax will scare off potential
> > developers, who write on smalltalk and don't want to hear about
> > anything else ;)
> That's possible, though I'm not as concerned about it.  Some will like both
> (as I do) and it will open the door to new people as well.  Plus, one
> usually goes to lisp so they don't have to have such a big development team,
> just as they do in Smalltalk. :)
Also, consider that smalltalk have more readable syntax than any
programming language i have managed to learn during my more than 20
years of programming experience, including Lisp :)

> > I'm sure we can deal with everything just fine by using smalltalk
> > syntax. Just need to formalize some things.
> > In fact, all my syntax based on executing code in single class with
> > same selector as used in asm.
> > So, when you put 'a+b' in asm code, this leads to call AsmSelectors>>+
> > method which generates corresponding intermediate for this operation.
> Well, you can still have macros in Smalltalk (though it's hard to do with
> Squeak's compiler if you want to use ##).  What Dolphin does already, and I
> have seen patches for VW is to override ##() to be a macro.  You can write
> pure smalltalk code and the output is placed in the location the macro was
> before the compile is completed.

I never programmed in Lisp, so i can't say how its easy/hard to
implement a compiler and define a set of functions for writing
assembler code.

Best regards,
Igor Stasenko AKA sig.
Exupery mailing list
[hidden email]