asm 64bit registers
I have tried to learn how 64bit asm (nasm in my case) works and found, among the many disparate pieces of info on the net, a few vague inferences that floating point registers can be used for other purposes than what they are intended for, example:
"64-bit Linux allows up to fourteen parameters to be transferred in registers (6 integer and 8 floating point)." This would be fantastic for string operations/manipulation (I have never used asm for floating-point operations), can anyone shed a bit of light? Thank you for your help. |
Quote:
What is the exact question ? |
Can those floating-point registers be used for string manipulation?
|
Quote:
|
I thought string manipulation was clear but it seems it is not.
For example can 2 strings (alphanumeric text) be placed in 2 floating-point registers (128/256bit?) for comparison? Is it faster (as implied in the info I found) than doing it in 64bit registers? A simple asm code would look like this in 64bit asm: first_string db "number of bytes of alphanumeric text here" second_string db "number of bytes of alphanumeric text here" mov resi,first_string mov redi,second_string cmp resi,redi |
Quote:
So, you think it's clear ? For example, in the "C" world strings are null terminated and as such their length can be whatever. OTOH, FP registers (AFAIK) can be loaded from memory only as a whole. So, for strings whose length is not a multiple of 8, FP registers can possibly be used for the initial part of the strings whose length is a multiple of 8, and the rest should be dealt with by other means. Now, the world "possibly". You have to verify that any data can be loaded into them not causing an FP exception. In the FP numbers world both NaNs and Infs exist. Probably loading not causing an exception can be done. Likewise, you have to verify that any data can be compared for equality, including the above mentioned NaNs and Infs. Among string operations there is also kind of '>' and '<' (see 'man 3 strcmp'). This operation can not be performed using FP registers for comparison - unless there is a possibility to access data in them as separate bytes. So, another thing for you to verify. The last but not least - do you need registers for comparison at all ? Maybe there is an instruction which compares, say, 'long long int' (8 bytes) with another 'long long int' - both of them being in memory. Obviously, if such an instruction exists, the comparison occurs inside the CPU, but using implicit registers. If so, why do you need registers for comparison at all - loading data into them is extra instructions, so fetching the instruction even from cache may take more time than the comparison under consideration. |
Very good point, thank you very much.
|
Quote:
|
So, the conclusion is those registers are not suitable for general purposes.
|
All times are GMT -5. The time now is 09:03 PM. |