I CCed our discussion to exupery board. Want to hear what Bryce thinks too :)
On 31/07/07, Jason Johnson jason.johnson.081@gmail.com wrote:
On 7/31/07, Igor Stasenko siguctua@gmail.com wrote:
On 31/07/07, Jason Johnson jason.johnson.081@gmail.com 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.
exupery@lists.squeakfoundation.org