#### Archived

This topic is now archived and is closed to further replies.

# Strange looking assembly code

This topic is 5345 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

Should this code work?
.data
FixedScale   dd 65536.0
pFixednumber dd    ?
.code
;...
;stuff
;...

;strange code:
st(0)
fmul  [FixedScale]   ; some number
fistp [pFixednumber]


Now the idea of this code is to translate some number to fixedpoint. The strange thing is that fmul direction, which(for what I know) should multiply the st(0) with the number adressed by Fixedscale. But here the fixedscale is not an address, but a dword variable.

##### Share on other sites
Doesn''t [FixedScale] actually mean its address?
Just like & in C.

##### Share on other sites
quote:
Original post by juuso
Doesn't [FixedScale] actually mean its address?
Just like & in C.

No, it means the actual data I think...

EDIT: BTW, it looks like something to do fixed point (like to scale it into a short).

[edited by - Puzzler183 on November 29, 2003 8:37:24 AM]

##### Share on other sites
Sure FixedScale is an address. And [FixedScale] is the data at the address.

##### Share on other sites
Exactly. So that code shouldn''t work, unless the assembler automagically create memory place for that 65536.0 in real format and put the FixedScale variable point into it.

I took this code from a professional programmers assembly example, could he have put that error there on purpose, so that the code wouldn''t work just by copy/pasteing it.

##### Share on other sites
But the line "FixedScale dd 65536.0" should be read like this: FixedScale is a label, and will have the address to the data at the place it was written. dd says that here we have a dword of data, which we then say should be 65536.0. So, FixedScale points to the data containing 65536.0, and [FixedScale] would be 65536.0.

"FixedScale equ 65536.0" would set FixedScale to 65536.0. It is not the same thing as dd.

So, the answer is yes, that code should work.

[edited by - Jolle on November 29, 2003 11:10:05 AM]

##### Share on other sites
No, I think the problem is that you don't quite get it. The code works just fine, you just don't understand the concept of memory or soemthing...

EDIT: BTW, I posted while Jolle was posting...

[edited by - Puzzler183 on November 29, 2003 11:10:53 AM]

##### Share on other sites
quote:
Original post by Jolle
But the line "FixedScale dd 65536.0" should be read like this: FixedScale is a label, and will have the address to the data at the place it was written. dd says that here we have a dword of data, which we then say should be 65536.0. So, FixedScale points to the data containing 65536.0, and [FixedScale] would be 65536.0.

"FixedScale equ 65536.0" would set FixedScale to 65536.0. It is not the same thing as dd.

So, the answer is yes, that code should work.

<SPAN CLASS=editedby>[edited by - Jolle on November 29, 2003 11:10:05 AM]</SPAN>

Sorry Jolle, but you are wrong. [FixedScale] doesn''t mean data at the address FixedScale. It is FixedScale that means it. [FixedScale] is indirect adressing, and tells to the processor to get the value pointed by FixedScale and use it as address to point to the memory.

The strange thing in the code here is the use of [FixedScale] where it shouldn''t be, but also the fact that co-processor works with normalized values. 65536.0 is not Normalized and (if the assembler doesn''t normalize it when assembling) will produce false calculations.

##### Share on other sites
It''s the same as C :
(1)

static const float Scale=65536.0f;

void main(void)
{
float x=3.07f;
float y=x*Scale;
printf("y=%f\n",y);
}

So I can''t see any problem. In asm the stored variables (.data dd, ...) are labelled and this represents the object address, not the object itself. You are accustommed to C or C++. Take a look at the asm code generated by (1), you will see that x=3.07f also requires a memory access, because the float constants can not be part of the asm instructions as it is the case for integers.

Anyway it''s not the fastest way to convert float to fixed point. Adding a 32bits or 64 bits"magic" number to "denormalize" the floating point is better ... if you don''t use the integer right after you stored it.
; x in st(0)
fstp qword ptr[TempQWord]
; ...
mov eax, dword ptr[TempQWord]

You can code it in C :
static double temp, magic;

temp = x+magic;
// ...
int i = ((int*)&temp)[ENDIANNESS];

For a PC ENDIANNESS= 0, a PPC =1.

Well search for the good old pentopt.txt on the web. However the fmul fild becomes more and more relevant on modern CPUs and in some contexts.

##### Share on other sites
AP is somewhat confused.
1. [FixedScale] is perfectly valid, and refers to the contents of the memory labelled FixedScale. MASM (rightfully referred to as quirks mode by TASM), a subset of which is made available by __asm, also allows FixedScale for the same purpose, and requires offset FixedScale for the address. This idiocy is the reason people sometimes use lea when loading the address, which is slower. Anyway, IA-32 doesn''t generally support memory-indirect addressing (exceptions: jmp, call).
2. You are quite right in pointing out that 65536.0 is not normalized. However, I have yet to see an assembler that requires anything other than decimal notation, and doesn''t convert it to IEEE format.

1. 1
Rutin
25
2. 2
3. 3
4. 4
JoeJ
18
5. 5

• 14
• 14
• 11
• 11
• 9
• ### Forum Statistics

• Total Topics
631757
• Total Posts
3002139
×