-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hi all,
I added support for pushl xxx(%esp) instruction and also I managed to create smarter wrapper code which means 10% drop in size (measured if -O0 is used).
Signed-off-by: Rudolf Marek r.marek@assembler.cz
Rudolf
On Fri, Oct 09, 2009 at 07:47:12PM +0200, Rudolf Marek wrote:
I added support for pushl xxx(%esp) instruction and also I managed to create smarter wrapper code which means 10% drop in size (measured if -O0 is used).
Nice!
BTW, I saw some further ways to enhance xmmstack:
It looks like either the xmm or mxx space is used. However, my read of the docs says both xmm and mxx can be used at the same time - this could increase the space from 128 bytes to 192 bytes.
The code only fixes pointers relative to %esp, but I don't think anything stops gcc from using non-esp pointers when referring to the stack. I think the code could be extended to fixup all memory accesses. Unfortunately, this would break those places where the code needs to access real-memory (eg, pci space or constants in flash). To get around this, the wrapper functions could check the absolute address of the access and only use xmm/mmx for those accesses between say 0x0040-0x00c0 (where the stack could be located). In order to test the address, instructions that set flags would be needed, but backing up and restoring the flags doesn't sound too hard (with lahf/"seto %al").
Finally, it appears much of xmmstack is static code inserted at the top of the file. I think moving the static code into it's own assembler file that is included might make what's going on a little more clear.
Just some random thoughts.. -Kevin
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hi Kevin,
It looks like either the xmm or mxx space is used. However, my read of the docs says both xmm and mxx can be used at the same time - this could increase the space from 128 bytes to 192 bytes.
Yes I think one must have SSE2 and not SSE for this.
The code only fixes pointers relative to %esp, but I don't think anything stops gcc from using non-esp pointers when referring to the stack.
Well I believe if -fomit-frame pointer is used all is addressed relatively to esp.
I think the code could be extended to fixup all memory accesses. Unfortunately, this would break those places where the code needs to access real-memory (eg, pci space or constants in flash). To get around this, the wrapper functions could check the absolute address of the access and only use xmm/mmx for those accesses between say 0x0040-0x00c0 (where the stack could be located). In order to test the address, instructions that set flags would be needed, but backing up and restoring the flags doesn't sound too hard (with lahf/"seto %al").
Yes looks feasible.
Finally, it appears much of xmmstack is static code inserted at the top of the file. I think moving the static code into it's own assembler file that is included might make what's going on a little more clear.
Yes :)
Rudolf
-
Kevin O'Connor -
Rudolf Marek