On 10/23/07, Allison Randal <[EMAIL PROTECTED]> wrote: > Klaas-Jan Stol wrote: > > Hi, attached a document describing the current macro layer of IMCC. > > On the proposed modifications to macros, I have reservations on the > automatic munging of .local variable names. Macros are simple > parameterized substitutions. If someone includes a '.local' in a macro, > it's likely that they'll expect it to appear literally in the body: > > .macro declare_my_locals(x) > .local int $x > .endm > > .sub bar > .declare_my_locals(foo) > foo = 5 > print foo > ... > .end > > And unlikely that they'll want it to appear munged for a particular > macro name: > > .sub bar > .declare_my_locals(foo) > local_declare_my_locals_foo = 5 > print local_declare_my_locals_foo > ... > .end > > Comments? > yes, '.local' in a macro should mean the same thing as '.local' in pir. to confuse the matter further, '.local' in a macro currently means "create a unique label."
what i'd like to see is a macro language where you can write pir ops and directives, and they'll be emitted as pir ops and directives. i'd also like the ability to create unique labels and unique variables, so we can do loop-in-a-loop macros that won't step on each other's variable names. so: .local in pir and macro language means create a local named variable .label in pir and macro language means create a label .macro_local in macro language means create a local uniquely named variable each time the macro is run .macro_label in macro language means create a uniquely named label each time the macro is run i'm not married to the name 'macro_', however the semantics are an important macro language feature that we're currently missing. ~jerry
