"db (-1) shr 1" results into "value out of ra

Index > Compiler Internals > "db (-1) shr 1" results into "value out of ra

Goto page Previous 1, 2

Author

Thread

edemko

Joined: 18 Jul 2009
Posts: 549

edemko 08 Sep 2010, 10:42

Tomasz, provide some proof - i do not understand.
Some life situation...

08 Sep 2010, 10:42

Tomasz Grysztar

Joined: 16 Jun 2003
Posts: 8359
Location: Kraków, Poland

Tomasz Grysztar 08 Sep 2010, 11:37

07FFFFFFFFFFFFFFFh+1

with 64-bit signed calculation, this causes overflow error
with 64-bit "composite" calculation it is allowed, however if you use the result for further calculations, it may get interpreted as negative value
with 65-bit signed calculation this is allowed and is still unambiguously positive value

-8000000000000000h-1

with 64-bit signed calculation, this causes overflow error
with 64-bit "composite" calculation it is allowed, because there is no way to tell it from "8000000000000000h-1", which should be allowed - it yields the positive result
with 65-bit signed calculation this is allowed, but will overflow when you try to put it into 64-bit container; it is also correctly distinguished from "8000000000000000h-1", which produces a positive value that can fit into 64 bits.

Code:

dq 8000000000000000h-1 ; error with 64-bit signed, assembles correctly with 64-bit composite and 65-bit signed
dq -8000000000000000h-1 ; error with 64-bit signed and 65-bit signed, assembles (though not really correctly) with 64-bit composite

PS I have added the "calculator" feature to the fasm's IDEs (fasmd/fasmw) under Ctrl+F6 combination for the purpose of checking out what the result of some your calculations would be, so if you have trouble with some of the fasm's quirks, you can at least quickly check out what your expression would become.

08 Sep 2010, 11:37

edemko

Joined: 18 Jul 2009
Posts: 549

edemko 08 Sep 2010, 20:01

There is another way when bit65 says "-" or "+" and modulo values stored in preceding 64 bits.
Such method widens number spectrum.
Positive and negative values lay same magnitude differing in their signs only.
There will be no ambiguity.
Number operations must be changed then too.

Look how easy multiplication then is:

Code:

result = abs1 * abs2                   ;this goes to 64bits

sign   = (abs1.sign + abs2.sign) and 1 ;this goes to bit65
       = abs1.sign xor abs2.sign

sure, 00b + 00b and 01b = 00b          ;+ * + = +
      00b + 01b and 01b = 01b          ;+ * - = -
      01b + 01b and 01b = 00b          ;- * - = +

eq    0 xor 0 = 0
      0 xor 1 = 1
      1 xor 1 = 0

etc
etc

08 Sep 2010, 20:01

revolution
When all else fails, read the source

Joined: 24 Aug 2004
Posts: 20453
Location: In your JS exploiting you and your system

revolution 08 Sep 2010, 20:08

xor is then same as add (and sub) if you ignore the carries. GF(2^n) uses xor as the additive/subtractive operation.

Last edited by revolution on 08 Sep 2010, 20:08; edited 1 time in total

08 Sep 2010, 20:08

Tomasz Grysztar

Joined: 16 Jun 2003
Posts: 8359
Location: Kraków, Poland

Tomasz Grysztar 08 Sep 2010, 20:08

edemko wrote:

There is another way when bit65 says "-" or "+" and modulo values stored in preceding 64 bits.
Such method widens number spectrum.

No, it does not - it actually has narrower number spectrum than regular 65-bit encoding, because it allows range -(2^64-1) to 2^64-1, as it is not able to encode the -2^64 number. It loses this one encoding, because it has both the negative and positive zero, and so it is able to encode one number less than the standard scheme (which is a truncated 2-adic numbers scheme).

08 Sep 2010, 20:08

edemko

Joined: 18 Jul 2009
Posts: 549

edemko 08 Sep 2010, 20:31

Seems you are right.
2-complementation implies easy computation through addition when subtraction needed, bothers mult. and div., ensures logical evaluation: shl/shr etc as no number conversion needed.

Eh.
I've found the solution - use qwords Smile

08 Sep 2010, 20:31

edemko

Joined: 18 Jul 2009
Posts: 549

edemko 08 Sep 2010, 20:33

revolution: commonly i avoid big theories, your the only sentence is more comprehensive those texts are

08 Sep 2010, 20:33

edemko

Joined: 18 Jul 2009
Posts: 549

edemko 09 Sep 2010, 03:44

Tomasz.
Soon or later there will be an overflow.
Bit 65 postpones it.
User allowed inputting composite nums which can be overflow condition once.
Will fasm say: "the expression can not be evaluated" ?
Why not to leave it and count the way CPU does.

09 Sep 2010, 03:44

Tomasz Grysztar

Joined: 16 Jun 2003
Posts: 8359
Location: Kraków, Poland

Tomasz Grysztar 09 Sep 2010, 07:43

edemko wrote:

Soon or later there will be an overflow.
Bit 65 postpones it.

The 65-bit signed precision is really the minimum if we want to allow 64-bit numbers in the composite signed+unsigned range analogously to 8-bit/16-bit/32-bit/48-bit numbers. Just as TASM's 33 bits were the minimum to do it for 32-bit numbers. Since fasm doesn't allow to define single values of larger sizes, it is not needed to have more bits. If we needed to define 128-bit numbers, 129-bit signed range would be right choice, etc.

edemko wrote:

Why not to leave it and count the way CPU does.

And what do you mean by that? Allow all kinds of overflows and never do any range checking? That is not a good idea.

edemko wrote:

commonly i avoid big theories

You should be careful, sometimes you may miss something important. Have you ever had some Knuth books in your hand? I highly recommend such a reading.

09 Sep 2010, 07:43

Tomasz Grysztar

Joined: 16 Jun 2003
Posts: 8359
Location: Kraków, Poland

Tomasz Grysztar 09 Sep 2010, 08:38

revolution wrote:

xor is then same as add (and sub) if you ignore the carries. GF(2^n) uses xor as the additive/subtractive operation.

revolution, if you are interested in such topics, you may find this related:
http://www.emis.de/journals/UIAM/PDF/46-21-30.pdf
(the bitwise XOR and AND are mentioned there, though under a different nomenclature).

09 Sep 2010, 08:38

edemko

Joined: 18 Jul 2009
Posts: 549

edemko 09 Sep 2010, 10:35

Tomasz wrote:

And what do you mean by that? Allow all kinds of overflows and never do any range checking? That is not a good idea.

Will next fasm deny this "dq 18'446'744'073'709'551'615 + 18'446'744'073'709'551'615"?
In my vision that seems a non-needed service.
qword->dword/word/byte and vice-versa important.

Tomasz wrote:

Have you ever had some Knuth books in your hand?

No.
Book looks good.

09 Sep 2010, 10:35

revolution
When all else fails, read the source

Joined: 24 Aug 2004
Posts: 20453
Location: In your JS exploiting you and your system

revolution 22 Jan 2011, 08:27

Tomasz Grysztar wrote:

bitRAKE wrote:
Why not make FASM 2.0 arbitrary precision?
That obviously would be something nice. It still may be decided, I'm not starting fasm 2.0 in any nearest future. You know, they are going to release Duke Nukem Forever next year, so then I may get a chance to beat them in terms of development time.

Duke Nukem Forever Has A Release Date: May 3, 2011

22 Jan 2011, 08:27

Goto page Previous 1, 2

< 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