This is the mail archive of the binutils@sources.redhat.com mailing list for the binutils project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
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
Attachment:
pgp00000.pgp
Description: PGP signature
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |