Talk:DGTEFF
--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)
Contents
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: 1x27 + 0x26 + <all zeros> + 0x21 + 0x20 = 128
Signed: -1x27 + 0x26 + <all zeros> + 0x21 + 0x20 = -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)
Big-Endian and Little-Endian
It is rare for the significance of bit order within a single byte to have any significance: in the majority of systems (regardless of endianness) the first bit in any 8-bit sequence is the most significant. Little-endian and Big-endian differences are very apparent in multi-byte numerics, however, where the first/last byte in 16-bit words are exchanged (and all bytes in larger numbers in reverse order).
Bit significance example in a 4-byte sequence of bytes numbered in sequence 0, 1, 2, 3:
| Byte # | Little endian | Big endian |
| Byte 0 | 07 06 05 04 03 02 01 00 | 31 30 29 28 27 26 25 24 |
| Byte 1 | 15 14 13 12 11 10 09 08 | 23 22 21 20 19 18 17 16 |
| Byte 2 | 23 22 21 20 19 18 17 16 | 15 14 13 12 11 10 09 08 |
| Byte 3 | 31 30 29 28 27 26 25 24 | 07 06 05 04 03 02 01 00 |
Actually, I'm working on a ver. 2.0 (or 1.1, take your pick) of the DGTEFF, based on a newer version provided by WATTO, once that is done, it'll be posted here in place of this one. If you don't mind, could you hold comments until that is done? 「ディノ奴千？！」? · ☎ Dinoguy1000 19:11, 19 October 2006 (EDT)
Dinoguy, the one that I uploaded as wiki pages is in fact I believe the latest of WATTO's revision to the 2004 version. At least it won't differ much I think. So the current version is already based on WATTO's revision. You may have the latest though, I did not check.
As for the suggested chanches to the document, by all means when you have more accurate info, or just additional info, or even a better way of explaining that what is already written, go ahead. This is a WIKI after all, and if we don't like it we can always revert certain parts after we discuss it. The bigger and better the Definitive Guide gets, the more Definitive it gets ;). But like Dinoguy said, it may be a good idea to wait until he uploads the latest version, and THEN start scratching in the document ;) .
--Mr.Mouse 03:24, 20 October 2006 (EDT)
Word and DWord
These are blatantly used in the context of a 16-bit x86 and don't make much sense once you're outside that world. A "word" can vary dependent on the architecture of the processor, so it's best to just avoid it if possible.
Similarly a short int and a long int vary depending on the compiler and the architecture. The safest and least ambiguous way is to just state the bit size (8-, 16-, 24-, 32- or 64-) with the endianness. It may also be worth explaining the abbreviations "LSB", "ESB" and "MSB". — Preceding unsigned comment added by 94.12.161.209 (talk • contribs) 09:29, 28 July 2012
- If you feel up to making corrections, by all means do. =) {:User:Dinoguy1000/signature}} 11:14, 28 July 2012 (EDT)
