Index
> Main > define dqword const ?Goto page 1, 2 Next |
| Author |
|
HMM!
|
Tomasz Grysztar 20 Aug 2008, 22:03
Already discussed here: http://board.flatassembler.net/topic.php?t=8487
|
|||
20 Aug 2008, 22:03 |
|
|
revolution 20 Aug 2008, 22:20
This will come up again soon when AVX is implemented.
|
|||
|
20 Aug 2008, 22:20 |
|
|
avi 20 Aug 2008, 23:06
_________________ It is better to keep your mouth shut and appear stupid than to open it and remove all doubt.--Mark Twain |
|||
|
20 Aug 2008, 23:06 |
|
|
lazer1 21 Aug 2008, 13:05
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:
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? |
|||
|
21 Aug 2008, 13:05 |
|
|
revolution 21 Aug 2008, 13:56
lazer1 wrote: people are arguing that you NEVER need integers greater than 64 bits |
|||
|
21 Aug 2008, 13:56 |
|
|
lazer1 21 Aug 2008, 15:42
revolution wrote:
example from the above thread: Quote:
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! |
|||
|
21 Aug 2008, 15:42 |
|
|
revolution 21 Aug 2008, 16:09
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. |
|||
|
21 Aug 2008, 16:09 |
|
|
vid 21 Aug 2008, 16:51
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 ? ... } |
|||
|
21 Aug 2008, 16:51 |
|
|
bitRAKE 21 Aug 2008, 18:23
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.
|
|||
|
21 Aug 2008, 18:23 |
|
|
Madis731 21 Aug 2008, 19:43
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  . 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). |
|||
|
21 Aug 2008, 19:43 |
|
|
revolution 21 Aug 2008, 20:02
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?> |
|||
|
21 Aug 2008, 20:02 |
|
|
Madis731 22 Aug 2008, 08:18
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. |
|||
|
22 Aug 2008, 08:18 |
|
|
vid 22 Aug 2008, 09:12
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.
|
|||
|
22 Aug 2008, 09:12 |
|
|
MCD 22 Aug 2008, 09:46
Madis731 wrote: I hope I'm not being too plain here, but what we need first is to be able to write this code: 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:
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 -||__/ .|+-~ .|| || |
|||
|
22 Aug 2008, 09:46 |
|
|
revolution 22 Aug 2008, 10:48
MCD wrote: ... reading such big numbers without any separators like _ or so tends to be impossible. |
|||
|
22 Aug 2008, 10:48 |
|
|
Madis731 22 Aug 2008, 14:46
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  |
|||
|
22 Aug 2008, 14:46 |
|
|
vid 22 Aug 2008, 14:57
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?
That would be doable (even though FASM no-string-functions limit can be felt here) |
|||
|
22 Aug 2008, 14:57 |
|
|
bitRAKE 23 Aug 2008, 04:44
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] |
|||
|
23 Aug 2008, 04:44 |
|
|
vid 23 Aug 2008, 07:51
XMM0 is array of dwords too
|
|||
|
23 Aug 2008, 07:51 |
|
| Goto page 1, 2 Next < Last Thread | Next Thread > |
Forum Rules:
|