flat assembler
Message board for the users of flat assembler.

Index > Main > How to declare 16-byte objects

Goto page 1, 2  Next
Author
Thread Post new topic Reply to topic
rhyde



Joined: 03 May 2007
Posts: 21
rhyde
What's the directive for declaring dqword objects? (and reserving storage for them?)
Thanks,
Randy Hyde
Post 19 Mar 2008, 16:23
View user's profile Send private message Reply with quote
AlexP



Joined: 14 Nov 2007
Posts: 561
Location: Out the window. Yes, that one.
AlexP
Hmm, try a FASM pre-processor array, or:
Code:
struct dqword name {
    
}
    
Post 19 Mar 2008, 16:40
View user's profile Send private message Visit poster's website Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17665
Location: In your JS exploiting you and your system
revolution
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).
Post 19 Mar 2008, 16:42
View user's profile Send private message Visit poster's website Reply with quote
vid
Verbosity in development


Joined: 05 Sep 2003
Posts: 7105
Location: Slovakia
vid
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
    
Post 19 Mar 2008, 17:11
View user's profile Send private message Visit poster's website AIM Address MSN Messenger ICQ Number Reply with quote
rhyde



Joined: 03 May 2007
Posts: 21
rhyde
I think you're all misunderstanding why I ask this.

FASM does a modicum of type checking. That is, symbols have a type/size attached to them. Although there are no instructions that absolutely require an implied 16-byte type (as there is always an SSE register with which to infer the type), it would seem reasonable that there should be the "dqword" equivalent of a data declaration and a reserve storage declaration that sets aside 16 bytes and attaches the associated size/type info. Just for consistency, if nothing else.

Yes, a macro can do it. Yes, you can just reserve two qwords of storage. But it's not the same. There is, of course, one other reason for wanting a "double qword" data storage directive -- if you want to initialize the value it's nice (especially when using a radix other than hexadecimal) to be able to specify the operand's value as a single number (decimal, hex, whatever).

hLater,
Randy Hyde
Post 19 Mar 2008, 17:33
View user's profile Send private message Reply with quote
vid
Verbosity in development


Joined: 05 Sep 2003
Posts: 7105
Location: Slovakia
vid
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)
Post 19 Mar 2008, 17:47
View user's profile Send private message Visit poster's website AIM Address MSN Messenger ICQ Number Reply with quote
rhyde



Joined: 03 May 2007
Posts: 21
rhyde
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
Post 19 Mar 2008, 20:31
View user's profile Send private message Reply with quote
AlexP



Joined: 14 Nov 2007
Posts: 561
Location: Out the window. Yes, that one.
AlexP
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 
    
Post 19 Mar 2008, 20:36
View user's profile Send private message Visit poster's website Reply with quote
Goplat



Joined: 15 Sep 2006
Posts: 181
Goplat
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    
Post 19 Mar 2008, 21:00
View user's profile Send private message Reply with quote
vid
Verbosity in development


Joined: 05 Sep 2003
Posts: 7105
Location: Slovakia
vid
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?
Post 19 Mar 2008, 21:10
View user's profile Send private message Visit poster's website AIM Address MSN Messenger ICQ Number Reply with quote
rhyde



Joined: 03 May 2007
Posts: 21
rhyde
vid wrote:
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?


???
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
Post 20 Mar 2008, 02:07
View user's profile Send private message Reply with quote
vid
Verbosity in development


Joined: 05 Sep 2003
Posts: 7105
Location: Slovakia
vid
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. :/
Post 20 Mar 2008, 02:17
View user's profile Send private message Visit poster's website AIM Address MSN Messenger ICQ Number Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17665
Location: In your JS exploiting you and your system
revolution
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.
Post 20 Mar 2008, 02:38
View user's profile Send private message Visit poster's website Reply with quote
mattst88



Joined: 12 May 2006
Posts: 260
Location: South Carolina
mattst88
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]    
Post 20 Mar 2008, 03:49
View user's profile Send private message Visit poster's website Reply with quote
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 7796
Location: Kraków, Poland
Tomasz Grysztar
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.
Post 20 Mar 2008, 12:46
View user's profile Send private message Visit poster's website Reply with quote
rhyde



Joined: 03 May 2007
Posts: 21
rhyde
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.

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.


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
Post 26 Mar 2008, 17:59
View user's profile Send private message Reply with quote
vid
Verbosity in development


Joined: 05 Sep 2003
Posts: 7105
Location: Slovakia
vid
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.
Post 26 Mar 2008, 18:15
View user's profile Send private message Visit poster's website AIM Address MSN Messenger ICQ Number Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17665
Location: In your JS exploiting you and your system
revolution
rhyde wrote:
Well, one could argue that AND doesn't operate on 4-byte, 2-byte, or 1-byte integers.
I can't see your argument there, AND will set a sign bit to give the sign of the result, that is definitely based upon integers. But more importantly ADD reg,reg is dealing with reg-sized integers but PADDx is not dealing with 128-bit sized integers. Call me an apologetic if you like, but the basic underlying instruction set doesn't support 128-bit 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.
Post 26 Mar 2008, 18:29
View user's profile Send private message Visit poster's website Reply with quote
daniel.lewis



Joined: 28 Jan 2008
Posts: 92
daniel.lewis
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
Post 27 Mar 2008, 02:25
View user's profile Send private message Reply with quote
DiamondXX



Joined: 31 Mar 2008
Posts: 1
DiamondXX
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
}     
Post 31 Mar 2008, 18:21
View user's profile Send private message ICQ Number Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  
Goto page 1, 2  Next

< Last Thread | Next Thread >
Forum Rules:
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum


Copyright © 1999-2020, Tomasz Grysztar. Also on GitHub, YouTube, Twitter.

Website powered by rwasa.