GAS macro formals as expression

[Fruhwirth Clemens]

Hi Nick!

On Wed, Sep 10, 2003 at 03:40:28PM +0100, Nick Clifton wrote:

> >> What you need is a patch something like the one below.  With this you
> >> can assemble code like this:
> > I'm looking forward to use this  one,
> 
>  ... I am not planning to apply it unless I can be persuaded that it
>  is a good idea.  At the moment I think it is a case of creeping
>  featurism rather than a needed extension to GAS.

That's true. To me it looks like GASP has been deprected to early but..

> >  but I'm afraid my Linux kernel patch is unlikely to get accepted
> > soon if it depends on such a brand new binutils feature.
> 
> True.  What is the real problem that you are trying to solve ?
> Perhaps there is a way to code your program that will not need any new
> features in GAS.

I'm porting 2fish_86.asm (http://www.counterpane.com/twofish-assem.zip) over
to gas. It's written in masm. I compile it with masm, and diassembled with
objdump, fixed the relocation. Now everything is running fine, but the
source is useless for modifications. So I'm trying to get the intelligent
macros back into the source.

For instance this masm macro:

ldCache macro addr,byteCnt,cpuName
NN=0
  rept (byteCnt+63)/64                  ;force cache line load (Pentium only)
    irp QQ,<%(NN)>
    mov         eax,addr[QQ]
        endm
   if (NN+32) lt byteCnt
    irp QQ,<%(NN+36)>
      mov       ebx,addr[QQ]
        endm
   endif
NN=NN+64
  endm
endm

I reimplemented this loop with this recursive gas macro:

.macro  ldCachePentium addr,byteCnt
        mov     \addr,%eax
        .ifgt \byteCnt-32
                mov 36+\addr,%ebx
                ldCachePentium 64+\addr,\byteCnt-64
        .endif
.endm

Called like: ldCachePentium 0x0(%esp),0x2c0 

There are two practical problems: maximum macro expansion depth. This could
be solved if one could redefine macro formals with like \n = \n + 64.
Evaluation would be nice so the formal don't add up to a chain of
64+64+64+64.. However that's not the main problem with this macro. masm is
generating different code for memory references with offset=0. Instead of
"mov 0x0(%esp,1),%eax" it's generating "mov (%esp,1),%eax" which is one byte
shorter. For my macro to reassemble this behaviour I would have to evaluate
the offset and check for 0x0 to generate "mov (%esp,1),%eax" instead of "mov
0x0(%esp,1),%eax".

So that's my practical problem :) In case you're still here thanks for
trying to understand it.

Regards, Clemens
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <https://sourceware.org/pipermail/binutils/attachments/20030910/d78ff3bb/attachment.sig>