# Difference between revisions of "Talk:DGTEFF"

Line 59: | Line 59: | ||

As mentioned above, only when multiplication/division occurs does the processor make a distinction of the high bit (many RISC processors do not have multiplication/division as on-chip instructions and therefore never make any distinction). The MULtiply instruction ignores any signedness intended by the data and uses the high bit as numeric. The Integer MULtiply uses the high bit as the sign bit by masking off the pair of high bits (multiplication requires two numbers after all) and XORing them together to represent the result's high bit with the rest of the numbers being used for the multiplication. (Note also that any multiplication operation extends the bit representation to the next higher category: 8-bit multiplication results in one 16-bit number and 16-bit multiplication results in one 32-bit number). --[[User:Barthax|Barthax]] 05:52, 19 October 2006 (EDT) | As mentioned above, only when multiplication/division occurs does the processor make a distinction of the high bit (many RISC processors do not have multiplication/division as on-chip instructions and therefore never make any distinction). The MULtiply instruction ignores any signedness intended by the data and uses the high bit as numeric. The Integer MULtiply uses the high bit as the sign bit by masking off the pair of high bits (multiplication requires two numbers after all) and XORing them together to represent the result's high bit with the rest of the numbers being used for the multiplication. (Note also that any multiplication operation extends the bit representation to the next higher category: 8-bit multiplication results in one 16-bit number and 16-bit multiplication results in one 32-bit number). --[[User:Barthax|Barthax]] 05:52, 19 October 2006 (EDT) | ||

+ | |||

+ | Hehe, a mate just pointed out that processors typically support different comparator operators for unsigned/signed comparisons... but then, that's not arithmetic, that's logic. :D --[[User:Barthax|Barthax]] 11:20, 19 October 2006 (EDT) |

## Revision as of 16:20, 19 October 2006

--08:29, 17 October 2006 (EDT) :

Well, I've used word2mediawiki to convert the Guide to wiki code. It's one huge page, so I guess we need to break it up into chapter-pages. Also, I haven't been able to include the images just yet, and the formating is the way the word2mediawiki macro for Word created it.

Alright, it'll make for a good placeholder for now. I'm thinking I'm going to do the new version of the guide in HTML (for my own sanity ;) ) and then get it sent to you... I figure, it should be easy enough to convert to PDF or DOC format... BTW, what happened to WATTO? His last post on the forum was sometime in March, and he hasn't edited anything on the WIKI for awhile either... 「ディノ奴千？！」^{? · ☎ Dinoguy1000} 12:31, 17 October 2006 (EDT)

Watto is busy with the full time job he started after he graduated from uni. He doesn't have much time on his hands.

--Mr.Mouse 14:31, 17 October 2006 (EDT)

Aah, that makes sense... 「ディノ奴千？！」^{? · ☎ Dinoguy1000} 17:11, 17 October 2006 (EDT)

Hey, thank you for writing this. I think my hex editor has stopped making fun of me now. XD -Rev. Confusmo

I've been considering for awhile getting an HTML/WIKI version of the DGTEFF on here, if I start on it, what do you want done, exactly? (ex. do you want it on the DGTEFF page, do you want the layout changed, or info added/removed/updated, etc.?)

Dinoguy1000 21:01, 12 August 2006 (EDT)

Yes, I agree, and Watto and I had the same idea when we put it up here, never got round to doing it. Watto had a new version lying around somewhere. He edited it to beyond 2004 :) I'll contact him about it. I think it would be best to have it on the DGTEFF page indeed, with an index to switch to the chapters and just on top the old link to the PDF, so people can still download it for home reference. Would be bloody great if you cold pull that off!!

--Mr.Mouse

I definitely could, if I could just kick my lazy butt into gear and stick with it till I was done... All I would need is the graphics uploaded, if you want them included in it.

Also, I'm going to be rewording some parts, in order to correct grammer or clarify points. Hope you don't mind!

Dinoguy1000 18:00, 13 August 2006 (EDT)

Watto hasn't responded yet, but i have the latest version in word format anyway. I will mail that to you. Watto is native Australian, so I recon you'd not have to correct the grammer used too much. :)

--Mr.Mouse 04:57, 14 August 2006 (EDT)

Okay, just mail it to the address on my profile page. You wouldn't mind if I added a Version History section, would you? (P.S. you really need to install a hack for auto-adding a signature... that could be nice)

--Dinoguy1000 16:49, 16 August 2006 (EDT)

## Suggested Amendments

### Signed and Unsigned Numbers

(I know this isn't explained well, but hopefully someone can interpret this into normality. :D )

The phrase: "You should note that because the highest bit is being used for another purpose (identifying positive/negative), it cannot be used as part of the number itself." This is a common misconception & is incorrect in all two's-complement processor units - i.e., pretty much everything post-1970. In a one's-complement system the high bit does indeed represent negative/non-negative - and the sum of the other bits is used as a subtraction from zero. In two's complement arithmetic, the explanation of the high-bit being signed/unsigned representation is left-over misconception from one's-complement artithmetic. The whole point of two's-complement arithmetic, in all but multiplication/division (see further down), is that the *processor unit* need make no distinction - only the human-interpreting (i.e., display) portion of programs need make the distinction.

In all but multiplication/division for a two's-complement processor unit (everything modern) the high bit represents both/either 128 and/or -128 depending on how your program cares to use it. The only time a distinction is made by the *processor unit* is when multiplication/division is used: at this point the MUL/IMUL instruction (or comparable instructions/algorithms in non-Intel x86 instruction sets) make an exception to the rule of processor ignorance.

The bit sequence 10000000 can therefore be expressed as either:

Unsigned: 1x2^{7} + 0x2^{6} + <all zeros> + 0x2^{1} + 0x2^{0} = 128

Signed: -1x2^{7} + 0x2^{6} + <all zeros> + 0x2^{1} + 0x2^{0} = -128

It also means that in 8-bit maths, adding 1 to either *unsigned-127* or *signed-positive-127* (take your pick how you as a human cares to interpret it - it's the bit sequence 01111111 either way) equals both *unsigned-128* and *signed-negative-128* (the bit sequence 10000000): the operation is the same discrete circuit on the chip (that of the ADD instruction).

As mentioned above, only when multiplication/division occurs does the processor make a distinction of the high bit (many RISC processors do not have multiplication/division as on-chip instructions and therefore never make any distinction). The MULtiply instruction ignores any signedness intended by the data and uses the high bit as numeric. The Integer MULtiply uses the high bit as the sign bit by masking off the pair of high bits (multiplication requires two numbers after all) and XORing them together to represent the result's high bit with the rest of the numbers being used for the multiplication. (Note also that any multiplication operation extends the bit representation to the next higher category: 8-bit multiplication results in one 16-bit number and 16-bit multiplication results in one 32-bit number). --Barthax 05:52, 19 October 2006 (EDT)

Hehe, a mate just pointed out that processors typically support different comparator operators for unsigned/signed comparisons... but then, that's not arithmetic, that's logic. :D --Barthax 11:20, 19 October 2006 (EDT)