Smalltalk › Squeak › Other › Squeak - Exupery

Re: Your ASM generator

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

1 message

Igor Stasenko

Re: Your ASM generator

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
form.
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
inlining.
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)
#(#ret)))

- 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]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/exupery