Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[LoSboccacc]

well try first DIV 0x3FF0000000000000 and rax should be back to SP

[Bumber]

well try first DIV 0x3FF0000000000000 and rax should be back to SP

I should mention that I haven't actually tried multiplying yet. I was trying to think my way through how DP float multiplication works. I have no idea how the CPU handles the instruction. The program still needs more work before I can actually assemble and test it. The vector registers just seem like a better idea with the amount of work I'd be doing otherwise.

I'm still curious how this works: http://x86asm.net/articles/working-with-big-numbers-using-x86-instructions/#Multiplication
Looking at it again, it appears to be handling a number "bignum" in memory in three pieces. 4 bytes at a time, if I'm understanding correctly. 8 bytes for the original number, 4 bytes of overflow.

[LoSboccacc]

multiplication is distributive so you can perform the double float operation accumulating the carry over to emulate the double float 128bit

that's not necessary if you are on a 64bit cpu (notice that the sample is using eax, and you rax) because you can fit a single 128bit double in two floats and the cpu has all the instruction needed to support the ?dx:?sx double word operations already

you should start however from your actual program requirement. what's the precision the assignment requires? then you select the appropriate path

[Bumber]

multiplication is distributive so you can perform the double float operation accumulating the carry over to emulate the double float 128bit

that's not necessary if you are on a 64bit cpu (notice that the sample is using eax, and you rax) because you can fit a single 128bit double in two floats and the cpu has all the instruction needed to support the ?dx:?sx double word operations already

you should start however from your actual program requirement. what's the precision the assignment requires? then you select the appropriate path

The precision requirement is 15 decimal places of accuracy (double precision.) The difficulty I'm facing is that I'm trying to multiplying several 64-bit floats together for an accurate 64-bit result. I don't really know how one goes about properly storing and utilizing the intermediate values. In other words, how do I multiply my resultant 128-bit number by the next 64-bit number?

Edit: "In this assignment floating point data must be stored in the SSE component in 64-bit floating point format and floating point arithmetic must be performed in the SSE."
I take it this means xmm registers are mandatory? Didn't know what SSE meant when I first read the assignment. Probably would have saved some time.

[LoSboccacc]

yep

[Bumber]

I think I'm almost done. Just a few errors to sort out.

Code: [Select]

nasm -f elf64 -l sphere.lis -o sphere.o sphere.asm
sphere.asm:115: warning: register size specification ignored
sphere.asm:97: error: invalid combination of opcode and operands
sphere.asm:104: error: invalid combination of opcode and operands
sphere.asm:105: error: invalid combination of opcode and operands
sphere.asm:110: error: invalid combination of opcode and operands
sphere.asm:115: error: invalid combination of opcode and operands

Here's the full assembly program: http://pastebin.com/rG9whDHf
The format is messed up a bit, but I've pointed out the offending lines. Here are the problematic instructions on their own:

Code: [Select]

movsd rbx, [rsp] ;Line 97 Error

movsd xmm0, rax ;Line 104 Error
movsd xmm1, rbx ;Line 105 Error

mulsd xmm1, rax ;Line 110 Error
push qword xmm0 ;Line 115 Error & Warning
Do I need to do something to the data in the rx registers first (i.e., use a convert function or move to memory) before I can use them with the xmm registers? Am I just using the wrong functions?

[LoSboccacc]

now, to be honest I haven't worked in assembly since 1997, I could stretch my 32bit knowledge to 64bit world because AMD x64 is just that nice.

however

movsd only works to/from simd register and memory, you can't use immediate values from registers
http://www.jaist.ac.jp/iscenter-new/mpc/altix/altixdata/opt/intel/vtune/doc/users_guide/mergedProjects/analyzer_ec/mergedProjects/reference_olh/mergedProjects/instructions/instruct32_hh/vc202.htm

so store rax in memory then load the value in xmm0 or since it's already there skip the reference altogheter:

movsd xmm0, [rsp]


also avoid mixed mulsd: best is to mulsd two xmm register; acceptable is multiply one register and one location, but you cannot multiply a xmm register with a normal register (see above)

relevant doc
http://www.jaist.ac.jp/iscenter-new/mpc/altix/altixdata/opt/intel/vtune/doc/users_guide/mergedProjects/analyzer_ec/mergedProjects/reference_olh/mergedProjects/instructions/instruct32_hh/vc211.htm

[Bumber]

Thanks, I suspected as much. Apparently the register sets are all separate from each other and can only interact through memory except in a few small cases.

How would you suggest I go about converting the 128-bit surface area into a 64-bit double for the return value? The warning tells me it's ignoring the qword part of "push qword xmm0". I'm not entirely sure what'll happen when I attempt to pop the resulting data into rax.

[miauw62]

I have some interest of myself of looking into assembler, more specifically z80 assembler (so I can program my calculator :V). Not sure where to begin or find guides, though.

[LoSboccacc]

as I said yesterday cvtsd2ss

[Bumber]

as I said yesterday cvtsd2ss

Will that work? I thought single precision was 32-bit?

I mean, it says 64-bit memory location, but I'm not sure if I'll be losing extra precision down to a regular float.

[LoSboccacc]

well single and duoble are relative to your instruction set, so that'd be single precision but 64bit, comparable to a double 32bit precision


I think

[Bumber]

well single and duoble are relative to your instruction set, so that'd be single precision but 64bit, comparable to a double 32bit precision


I think

The link seems to suggest otherwise: "The result is stored in the low doubleword of the destination operand, and the upper 3 doublewords are left unchanged."

In addition, it says the destination operand must be a xmm register. Not sure how to store that result in memory properly.

[LoSboccacc]

yeah but the destination operand defines what a word and doubleword is in size. double world should be .dx:.ax independently from word size because backcomp

well, I think this is the boundary of my knowledge. have a pleasant journey ahead and report back your discoveries!

[Bumber]

I thought a double word was always 4 bytes?