Index
> Main > How to declare 16-byte objectsGoto page 1, 2 Next |
| Author |
|
|
rhyde 19 Mar 2008, 16:23
What's the directive for declaring dqword objects? (and reserving storage for them?)
Thanks, Randy Hyde |
|||
19 Mar 2008, 16:23 |
|
|
AlexP 19 Mar 2008, 16:40
Hmm, try a FASM pre-processor array, or:
Code: struct dqword name { } |
|||
|
19 Mar 2008, 16:40 |
|
|
revolution 19 Mar 2008, 16:42
Is this a trick question? The manual section 1.2.2 shows the available store definitions (up to the maximum dt/rt for 10 bytes).
|
|||
|
19 Mar 2008, 16:42 |
|
|
vid 19 Mar 2008, 17:11
do you need ability to initialize their value to 128bit integer? or just do this:
Code: dd 0 dd 1 dd 2 dd 3 ... rd 4 rb 5*16 |
|||
|
19 Mar 2008, 17:11 |
|
|
vid 19 Mar 2008, 17:47
i think this is issue that we discussed several times on ALA. FASM's type information is only "heuristic helper" for cases like "mov [eax], 10", or catching bugs like "mov [abcd], ax" (where abcd is not assigned word size). There is no need of dqword size type for these purposes, and for any other purpose, you should build more strictly typed framework yourself (like you did with HLA)
|
|||
|
19 Mar 2008, 17:47 |
|
|
rhyde 19 Mar 2008, 20:31
vid wrote: i think this is issue that we discussed several times on ALA. FASM's type information is only "heuristic helper" for cases like "mov [eax], 10", or catching bugs like "mov [abcd], ax" (where abcd is not assigned word size). There is no need of dqword size type for these purposes, and for any other purpose, you should build more strictly typed framework yourself (like you did with HLA) Again, you've missed the point. Think initialization, i.e., somevar ddq 1234556787654356787654345676543 Also, having the heuristics to catch problems like someSSEInstr xmm0, <not a ddq var> would be nice, too. Cheers, Randy Hyde |
|||
|
19 Mar 2008, 20:31 |
|
|
AlexP 19 Mar 2008, 20:36
Just make a simple macro for constant intialization, like:
Code: macro ddq [bytes] { db bytes } ; or something of the sort, I have little macro experience. ; Then to declare a constant: somevar ddq 1234556787654356787654345676543 |
|||
|
19 Mar 2008, 20:36 |
|
|
Goplat 19 Mar 2008, 21:00
fasm's numeric constants are only 64-bit, so there can't be a "ddq" instruction (what would you put as its operand?) You have to make your dqword out of smaller parts.
There are several ways to get around the problem of the label being the wrong size-type for SSE instructions: Code: ; use an explicit size specifier movdqa xmm0,dqword [foo] foo db 1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16 ; use an untyped label, by adding the colon movdqa xmm0,[foo] foo: db 1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16 ; use the "label" directive to make a true dqword label movdqa xmm0,[foo] label foo:dqword db 1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16 |
|||
|
19 Mar 2008, 21:00 |
|
|
vid 19 Mar 2008, 21:10
it probably is POSSIBLE to write such macro by converting value to string, etc... but it would be overkill.
rhyde: what do you need 128bit integers for? |
|||
|
19 Mar 2008, 21:10 |
|
|
rhyde 20 Mar 2008, 02:07
vid wrote: it probably is POSSIBLE to write such macro by converting value to string, etc... but it would be overkill. ??? Uh, they are a basic SSE data type. Whether I personally use them or not isn't the point. An assembler that supports SSE instructions like ANDPD should support 16-byte integers. The fact that few people actually write them is really irrelevant. Forcing someone to compute the hexadecimal equivalent and emit the data as two qwords is not clean. From a personal point of view, I'm cleaning up the source code generator module for HLA to try and emit code that is a bit more readable that the "acceptable to a back-end assembler and not much else..." output it has been producing. Obviously, it's pretty easy for me to break a 16-byte value down into two qwords or any number of smaller components. But the point is to make the output more readable. Well, there is no sense arguing about the need for it. The fact that I want it means *someone* out ther wants it; and it sure seems to me that if an assembler supports instructions that manipulate 128-bit data types, there would be a directive for declaring 128-bit constants. HLA, for example, has had this facility for many years. Either Tomasz will add it, or he won't. It's as simple as that. I'm not begging for it to be added, I was just suprised to find that support was added for 128-bit data types (i.e., ther fdword modifier) without support for declaring 128-bit integer constants. Cheers, Randy Hyde |
|||
|
20 Mar 2008, 02:07 |
|
|
vid 20 Mar 2008, 02:17
SSE data types are set of 4 dwords, not single 128bit integer, that simply doesn't hold.
There could be some rationale for defining it as separate size type, but definitively not for initializaing by integer value. It's true that FASM *should* have 128 (or 129) bit internal aritmetics, but that isn't something tomasz realized back in '99 or so, when he designed it. Not because of SSE instruction (those work with set of 4 dwords anyway), but for other reasons. But unfortunately due to nature of FASM, i don't see it as realistic option right now. :/ |
|||
|
20 Mar 2008, 02:17 |
|
|
revolution 20 Mar 2008, 02:38
SEEx does NOT have a 128 bit integer data type. It uses packed floats and integers of no larger than 64 bits each. There are currently no instructions in x86 that can directly deal with 128 bit values. You will need a bignum library to deal with 128 bit values.
Things like ANDPD do not operate on "16-byte integers". They simply operate on 16-bytes of data at one time. The data is not interpreted as either integers, floats, or unsigned, it is just a string of data bytes without implied meaning. |
|||
|
20 Mar 2008, 02:38 |
|
|
mattst88 20 Mar 2008, 03:49
I understand your question.
Instead of specifying a 128bit value, you actually specify 4 32-bit values, or 2 64-bit values. For instance Code: zero_double: dq 0.0,0.0 ; two double precision floating point values zero_single: dd 0.0,0.0,0.0,0.0 ; four single precision floating point values Note the : after the name of the variable. Then, to load into an SSE register.. Code: movdqa xmm0,dqword[zero_double] movdqa xmm1,dqword[zero_single] |
|||
|
20 Mar 2008, 03:49 |
|
|
Tomasz Grysztar 20 Mar 2008, 12:46
These solutions don't enable the right type checking for such defined variables. You should do it this way:
Code: label something dqword
dq low,high etc. |
|||
|
20 Mar 2008, 12:46 |
|
|
rhyde 26 Mar 2008, 17:59
revolution wrote: SEEx does NOT have a 128 bit integer data type. It uses packed floats and integers of no larger than 64 bits each. There are currently no instructions in x86 that can directly deal with 128 bit values. You will need a bignum library to deal with 128 bit values. Well, one could argue that AND doesn't operate on 4-byte, 2-byte, or 1-byte integers. Still, type checking is done for those instructions, eh? I realize people around here are a bit defensive about this subject, so I will let it drop (as there is no such directive, so I'll just have to fake it). I am amazed, however, at the apologetics that seem to be taking place here. As the language supports 128-bit objects, it seems reasonable that the assembler would support a directive that lets you create 128-bit objects in a manner consistent with bytes, word, dwords, and qword. Again, no big loss to me as I'm just producing output from a compiler and I can easily write code to automate breaking the large objects down into smaller ones (though it would be nice if the output were more readable, I can live with that). However, for human beings, having to break the object into smaller pieces seems like extra work -- the assembler ought to do this. Cheers, Randy Hyde |
|||
|
26 Mar 2008, 17:59 |
|
|
vid 26 Mar 2008, 18:15
Quote: However, for human beings, having to break the object into smaller pieces seems like extra work -- the assembler ought to do this. Every 128bit object you ever need (MMX vector, SSE vector) is by definition broken to smaller pieces. It's no artificial breaking in this case. Vector written as single integer is IMHO actually harder to read than vector written naturally - as four dwords, for example. Yes, having such feature would be nice, but it's no big deal if it is missing, as no one ever needs such thing. |
|||
|
26 Mar 2008, 18:15 |
|
|
revolution 26 Mar 2008, 18:29
rhyde wrote: Well, one could argue that AND doesn't operate on 4-byte, 2-byte, or 1-byte integers. Perhaps you meant to say 16-byte sized data structures? Then I can see the desire for a single data type, dqword. But it hasn't caught on yet. I know that the internal data structure could support it without too much change, but the expression parser and assembler might prove problematic to get it working nicely. |
|||
|
26 Mar 2008, 18:29 |
|
|
daniel.lewis 27 Mar 2008, 02:25
Ermm... for many SSE instructions you can use 16-byte memory instead of registers. It's quite reasonable to want to be able to access the whole 16-bytes as a single code point.
Also, given SSE is constantly growing (faster than the normal instruction set) I would argue that it's sensible to solve this as it's quite reasonable to suspect they'll eventually add a 16-byte numbers from a register type checking perspective. Best Regards, Daniel |
|||
|
27 Mar 2008, 02:25 |
|
|
DiamondXX 31 Mar 2008, 18:21
Why don't use such code:
Code: macro dqword name { } macro ddq [ar] { forward match low:high,ar \{ dq low,high \} } struc ddq [ar] { common ddq ar } macro rdq ar { rept ar \{ dq ?,? \} } struc rdq ar { rdq ar } macro dqd [ar] { forward match first:second:third:fourth,ar \{ dd first,second,third,fourth \} } struc dqd [ar] { common dqd ar } macro rqd ar { rept ar \{ dd ?,?,?,? \} } struc rqd ar { rqd ar } |
|||
|
31 Mar 2008, 18:21 |
|
| Goto page 1, 2 Next < Last Thread | Next Thread > |
Forum Rules:
|