Aligned function pointers (was: MMD and PASM subs)

Dan Sugalski <[EMAIL PROTECTED]> wrote: > ... Seems that gcc does *not* > align function pointers by default. I've now created a new config key: HAS_aligned_funcptr => 1 which creates #define PARROT_HAS_ALIGNED_FUNCPTR 1 This key is already set for GCC. So, if you are using another compil

Re: MMD and PASM subs

Dan Sugalski <[EMAIL PROTECTED]> wrote: >>cc1: Invalid option `-falign-functions=8' > The manpage made it sound like it was an absolute thing, but I can > see it being a power-of-two number. GCC 3.3.3 likes the 8, so I > hadn't noticed. I've a =3 build going now--if it tests OK I'll commit > the

Re: MMD and PASM subs

At 7:12 PM +0200 4/29/04, Leopold Toetsch wrote: Dan Sugalski <[EMAIL PROTECTED]> wrote: And just to add extra evil, now it works. Seems that gcc does *not* align function pointers by default. Almost: $ perl Configure.pl --maintainer --floatval=double --verbose-step=Determ ... cc1: Invalid optio

Re: MMD and PASM subs

At 7:08 PM +0200 4/29/04, Leopold Toetsch wrote: Dan Sugalski <[EMAIL PROTECTED]> wrote: Oh, right, and... this is really, really evil. Which is why I just put it in. :) *g* Should I cleanup and implement the rest? And which opcode of the (duplicated? mm* ops? I'll go patch this up. I'm halfway

Re: MMD and PASM subs

Dan Sugalski <[EMAIL PROTECTED]> wrote: > And just to add extra evil, now it works. Seems that gcc does *not* > align function pointers by default. Almost: $ perl Configure.pl --maintainer --floatval=double --verbose-step=Determ ... cc1: Invalid option `-falign-functions=8' This one want -malign

Re: MMD and PASM subs

Dan Sugalski <[EMAIL PROTECTED]> wrote: > Oh, right, and... this is really, really evil. Which is why I just > put it in. :) *g* Should I cleanup and implement the rest? And which opcode of the (duplicated? mm* ops? leo

Re: MMD and PASM subs

At 4:54 PM +0200 4/29/04, Leopold Toetsch wrote: Dan Sugalski <[EMAIL PROTECTED]> wrote: At 3:55 PM +0200 4/29/04, Leopold Toetsch wrote: Another long running discussion: do we need duplicate mmd tables. Dunno. Don't care, really--I was throwing in two tables as proof-of-concept just to get thi

Re: MMD and PASM subs (was: keyed vtables and mmd)

At 11:42 AM -0400 4/29/04, Dan Sugalski wrote: At 3:55 PM +0200 4/29/04, Leopold Toetsch wrote: Another long running discussion: do we need duplicate mmd tables. Here is a proof of concept to avoid it: Oh, right, and... this is really, really evil. Which is why I just put it in. :) And just to add

Re: MMD and PASM subs

Dan Sugalski <[EMAIL PROTECTED]> wrote: > At 3:55 PM +0200 4/29/04, Leopold Toetsch wrote: >> >>Another long running discussion: do we need duplicate mmd tables. > Dunno. Don't care, really--I was throwing in two tables as > proof-of-concept just to get things going. As there can be just one entr

Re: MMD and PASM subs (was: keyed vtables and mmd)

At 3:55 PM +0200 4/29/04, Leopold Toetsch wrote: Another long running discussion: do we need duplicate mmd tables. Here is a proof of concept to avoid it: Oh, right, and... this is really, really evil. Which is why I just put it in. :) -- Dan --

Re: MMD and PASM subs (was: keyed vtables and mmd)

At 3:55 PM +0200 4/29/04, Leopold Toetsch wrote: Dan Sugalski <[EMAIL PROTECTED]> wrote: Okay, we've a long-running discussion between Leo and I about the keyed variants for all the binary vtable entries. Another long running discussion: do we need duplicate mmd tables. Dunno. Don't care, really

MMD and PASM subs (was: keyed vtables and mmd)

Dan Sugalski <[EMAIL PROTECTED]> wrote: > Okay, we've a long-running discussion between Leo and I about the > keyed variants for all the binary vtable entries. Another long running discussion: do we need duplicate mmd tables. Here is a proof of concept to avoid it: #v+ --- parrot/src/mmd.cTh