flat assembler
Message board for the users of flat assembler.

Index > Main > define dqword const ?

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



Joined: 24 Jan 2006
Posts: 185
lazer1
in the fasm documentation
Quote:

Table 1.1 Size operators versus Table 1.3 Data directives:

operator bytes define_data
byte 1 db
word 2 dw
dword 4 dd
fword 6 df
pword 6 dp
qword 8 dq
tword 10 dt
dqword 16 Mad HMM!


there is a define data for everything except dqword.

perhaps my documentation is out of date!

Now I need a 16 byte define for a struct to save the xmm values:

Quote:

struc xmm_values
{
.xmm0 d? 0 ; where d? is the directive I want! Smile
.xmm1 d? 0
.xmm2 d? 0
.xmm3 d? 0
.xmm4 d? 0
.xmm5 d? 0
.xmm6 d? 0
.xmm7 d? 0
.xmm8 d? 0
.xmm9 d? 0
.xmm10 d? 0
.xmm11 d? 0
.xmm12 d? 0
.xmm13 d? 0
.xmm14 d? 0
.xmm15 d? 0
}

virtual at 0
xmm_values xmm_values
end virtual

movupd [ rax + xmm_values.xmm0 ], xmm0
movupd [ rax + xmm_values.xmm1 ], xmm1
movupd [ rax + xmm_values.xmm2 ], xmm2

; using AMD volume 4 notation, see page 200



where d? doesnt exist in the documentation I have here,
but maybe has been created since?

currently I will need:

Quote:

....
.xmm0 dq 0
dq 0
....

movupd dqword [ rax + xmm_values.xmm0 ], xmm0


but if there is a d? then I dont need the "dqword" as fasm will
automatically know its a dqword.
Post 20 Aug 2008, 21:58
View user's profile Send private message Reply with quote
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 7725
Location: Kraków, Poland
Tomasz Grysztar
Post 20 Aug 2008, 22:03
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: 17287
Location: In your JS exploiting you and your system
revolution
This will come up again soon when AVX is implemented.
Post 20 Aug 2008, 22:20
View user's profile Send private message Visit poster's website Reply with quote
avi



Joined: 24 Jun 2008
Posts: 23
Location: usa
avi

_________________
It is better to keep your mouth shut and appear stupid than to open it and remove all doubt.--Mark Twain
Post 20 Aug 2008, 23:06
View user's profile Send private message Reply with quote
lazer1



Joined: 24 Jan 2006
Posts: 185
lazer1
commenting here instead of at that thread as its reached page 2!

(I think its better to have longer pages as it is offputting to go to
another page)

looks like the 2 themes there are that 128 bits will be vectors of 64 or less
bits and that its difficult to implement.

people are arguing that you NEVER need integers greater than 64 bits,

NOT TRUE: I use MORE THAN 1024 bits for PGP encryption,

PGP is all about very wide integers, and you want it to be as
fast as possible if you want to encrypt an HD

for my own code I need to backup the xmm's regarded as
storage cells. that is best done regarding them as an UNINTERPRETED 128 bit entity. They ARENT a vector of 2 x 64 bits, they are other things
as well, more of a union:

union { vector_of_2_64s v2_64 ; vector_of_4_32 v4_32 ; .... } ;

my own immediate usage of xmm's is as 2 x 64 vectors,

later I will use other interpretations eg 4 x 32



Quote:

It is better to keep your mouth shut and appear stupid than to open it and remove all doubt.--Mark Twain


that quote is nonsense, you need to appear stupid to learn.

if you dont understand what someone is saying you need to say so
otherwise you will appear clever and will REMAIN STUPID!

NEVER accept something you dont understand,
otherwise you will get CONNED. Con artistes are usually
based on the Mark Twain idea: people are too afraid
to look stupid, the story of the naked emperor.

what did Mark Twain ever invent?
Post 21 Aug 2008, 13:05
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17287
Location: In your JS exploiting you and your system
revolution
lazer1 wrote:
people are arguing that you NEVER need integers greater than 64 bits
Really? Who is arguing that? It would seem very naive to argue such a thing.
Post 21 Aug 2008, 13:56
View user's profile Send private message Visit poster's website Reply with quote
lazer1



Joined: 24 Jan 2006
Posts: 185
lazer1
revolution wrote:
lazer1 wrote:
people are arguing that you NEVER need integers greater than 64 bits
Really? Who is arguing that? It would seem very naive to argue such a thing.


example from the above thread:

Quote:

There is no need of dqword size type for these purposes, and for any other purpose --- vid


I am not an expert on PGP but looking at one of my books:

you select 2 huge prime numbers p, q

n = pq

and a small odd integer e relatively prime to (p-1)(q-1)

d is the integer 1/e modulo (p-1)(q-1)

(e,n) is the public key

(d,n) is the secret key

the encryption of message M is M^e mod (n) (^ is exponent)

and the decription of E is E^d mod (n)



E = M^e mod (n)

mod (p) : E^d = M^(e*d) = M^ ( 1 + a(p-1)(q-1))

but x^(p-1)==1 mod (p) for x!=0,

so E^d=M * 1 = M for M!=0 and also when M==0

E^d = M mod p, and also E^d = M mod q

so by the Chinese Remainder Theorem E^d = M mod n




I think I use a 1030 bit PGP key,

which means you are evaluating 1030_bits ^ 1030_bits mod 1030_bits

to decrypt and

1030_bits ^ few_bits mod 1030_bits to encrypt



(to prove that x^(p-1) = 1 mod (p) for x != 0 (p) consider

(p-1)! = 1 * 2 * ... (p-1)

if we multiply all the terms on the right by x we get x^(p-1) * (p-1)!

however multiplication by x just permutes the terms so we in
fact get (p-1)! ie x^(p-1) * (p-1)! = (p-1)! ie x^(p-1) = 1)



PGP is banned in the US, in the UK the military use the PGP idea
for communications to prevent listening in.

if you could PGP encrypt video frames in real time then
you could have secure video links.

when I go on holiday I take PGP encrypted forms of all my
data on flash drives.

that way I have a backup of all my data and if I lose a
flash drive the data is unusable

I would NEVER use Microsoft encryption!
Post 21 Aug 2008, 15:42
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17287
Location: In your JS exploiting you and your system
revolution
PGP is not banned in the US. Where do you get that idea? I think you are actually talking about the RSA scheme, PGP uses RSA for key distribution, but not for direct message encryption.

128 bit integers are not nearly big enough for the RSA based encryption schemes if one wants a secure system. You will still need to use multiple 128 bit registers to make a larger sized modulus.

I would think that using PGP to encrypt all your data is not the best way to secure your own documents. Better would be one of the much simpler, easier and faster symmetric cyphers. This also allows you to keep a password in your head. Using RSA style encryptions requires a large secret key to be secured also.

Also, taking vid's comment out of context is not being fair. vid was talking about the assembly code aspect of a dqword operator, not the data contained within a 128 bit register.
Post 21 Aug 2008, 16:09
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
Yes, I meant that there are no instruction that work with 128 bit integer, so there also is no need for such type. Otherwise, we could use same your argumentation to include 39 bit type, etc...

btw:
Code:
struc ddq x {
  label . dqword
  dq x
  dq 0  ;FASM doesn't allow initializing more than 64 bits at a time
}

struc xmm_values {
  .xmm0 ddq ?
  .xmm1 ddq ?
 ...
}
    
Post 21 Aug 2008, 16:51
View user's profile Send private message Visit poster's website AIM Address MSN Messenger ICQ Number Reply with quote
bitRAKE



Joined: 21 Jul 2003
Posts: 2915
Location: [RSP+8*5]
bitRAKE
People are seeing symmetry between data directives (Table 1.3) and size operators (Table 1.1). The lack of a DQWORD data definition is symmetry breaking in that regard, but there is no FILE or UNICODE size operator, lol.

_________________
¯\(°_o)/¯ unlicense.org
Post 21 Aug 2008, 18:23
View user's profile Send private message Visit poster's website Reply with quote
Madis731



Joined: 25 Sep 2003
Posts: 2141
Location: Estonia
Madis731
Actually I need this feature now more than ever. Most of my programming is in SSE and I stumble at least 2-3 times a week on the "okay, I'll call you a dqword[memory] then" problem.

Its okay when you initialize the variables, then its usually dword or qword but there still must at least exist a normal solution to this when we're talking about reserved memory because when you make the memory typeless, you'll end up in all sorts of "other" errors.

But I'm not looking for ddq. Its breaking the habit Wink. There should be logically dx for xmm and dy for ymm, but as we all know, there's already a register called dx. So I'll go for do (as oword) and dy (from ymm registers).
Post 21 Aug 2008, 19:43
View user's profile Send private message Visit poster's website Yahoo Messenger MSN Messenger Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17287
Location: In your JS exploiting you and your system
revolution
Madis731: The problem is not with the definition or naming. it is with initialisation. How do you initialise do? dy?
Code:
xmm_mem_var do <what do I put here?>
ymm_mem_var dy <what do I put here?>    
Post 21 Aug 2008, 20:02
View user's profile Send private message Visit poster's website Reply with quote
Madis731



Joined: 25 Sep 2003
Posts: 2141
Location: Estonia
Madis731
I hope I'm not being too plain here, but what we need first is to be able to write this code:
Code:
movdqa xmm0,[myxmmdata]
myxmmdata ro 10
myymmdata dy 0
    

then onto more complicated examples like initializing to a value beyond qword:
Code:
db 01h
dw 0123h
dd 01234567h
dq 0123456789ABCDEFh
do 0123456789ABCDEF0123456789ABCDEFh
dy 0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEFh
    

I wonder if the native CPU mode would become 128-bit in ~15years, would it still be so much opposed that dqword is unnecessary and unthoughtfully stupid :S

I just don't get it why people are so against it.
Post 22 Aug 2008, 08:18
View user's profile Send private message Visit poster's website Yahoo Messenger MSN Messenger Reply with quote
vid
Verbosity in development


Joined: 05 Sep 2003
Posts: 7105
Location: Slovakia
vid
It wouldn't bother me to have it, but in current situtation in FASM, it would be vast amount of work, and little gain, since there are no instruction that work with 128 bit integers anyway. If there is some CPU that works with 128 integers, I'd be first to support it.
Post 22 Aug 2008, 09:12
View user's profile Send private message Visit poster's website AIM Address MSN Messenger ICQ Number Reply with quote
MCD



Joined: 21 Aug 2004
Posts: 604
Location: Germany
MCD
Madis731 wrote:
I hope I'm not being too plain here, but what we need first is to be able to write this code:
Code:
movdqa xmm0,[myxmmdata]
myxmmdata ro 10
myymmdata dy 0
    


agreed, since I'm currently using some kind of macro to do this job. It has something like
Code:
label Name dqword
dd X0,X1,X2,X3
    


Madis731 wrote:

then onto more complicated examples like initializing to a value beyond qword:
Code:
db 01h
dw 0123h
dd 01234567h
dq 0123456789ABCDEFh
do 0123456789ABCDEF0123456789ABCDEFh
dy 0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEFh
    

I wonder if the native CPU mode would become 128-bit in ~15years,

even if we would have AVX with 256bit wide registers, they won't contain integer or floating point data types > 64bits, so this doesn't really make sence.

Also, reading such big numbers without any separators like _ or so tends to be impossible.

_________________
MCD - the inevitable return of the Mad Computer Doggy

-||__/
.|+-~
.|| ||
Post 22 Aug 2008, 09:46
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17287
Location: In your JS exploiting you and your system
revolution
MCD wrote:
... reading such big numbers without any separators like _ or so tends to be impossible.
Agreed, see here
Post 22 Aug 2008, 10:48
View user's profile Send private message Visit poster's website Reply with quote
Madis731



Joined: 25 Sep 2003
Posts: 2141
Location: Estonia
Madis731
I understand vid, finally, from his last post (sorry if I'm slow...).
I agree with MCD on huge numbers (even 64-bit initializers are rare in my code)

Maybe we can come to a consensus of some kind Razz
Post 22 Aug 2008, 14:46
View user's profile Send private message Visit poster's website Yahoo Messenger MSN Messenger Reply with quote
vid
Verbosity in development


Joined: 05 Sep 2003
Posts: 7105
Location: Slovakia
vid
Quote:
Maybe we can come to a consensus of some kind

"ddq" macro with lots of load/store trickery, with support only for 128bit hex initializers? Wink

That would be doable (even though FASM no-string-functions limit can be felt here)
Post 22 Aug 2008, 14:57
View user's profile Send private message Visit poster's website AIM Address MSN Messenger ICQ Number Reply with quote
bitRAKE



Joined: 21 Jul 2003
Posts: 2915
Location: [RSP+8*5]
bitRAKE
Redefine the instructions to remove type checking on memory operands would be another option - how much 'protection' does it provide for DQWORDs.
Code:
psubd xmm0,dqword [.4]    
...seems silly as I'm using many dynamic memory locations and DQWORD means nothing - they are dwords. Yet, FASM forces the type of DQWORD. Why? Of course XMM0 is a dqword, but the instruction wants an array of DWORDs.

_________________
¯\(°_o)/¯ unlicense.org
Post 23 Aug 2008, 04:44
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
XMM0 is array of dwords too
Post 23 Aug 2008, 07:51
View user's profile Send private message Visit poster's website AIM Address MSN Messenger 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 YouTube, Twitter.

Website powered by rwasa.