Talk:DGTEFF - Revision history

imported>Dinoguy1000: fix header, sign, reply

2012-07-28T15:14:00Z

fix header, sign, reply

← Older revision	Revision as of 15:14, 28 July 2012
(No difference)

imported>Dinoguy1000: fix header, sign, reply

2012-07-28T15:14:00Z

fix header, sign, reply

← Older revision		Revision as of 15:14, 28 July 2012
Line 101:		Line 101:


	=== Word and DWord		== 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.		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".		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". <small><span class="autosigned">— Preceding [[Wikipedia:Signatures\|unsigned]] comment added by [[User:94.12.161.209\|94.12.161.209]] ([[User talk:94.12.161.209\|talk]] • [[Special:Contributions/94.12.161.209\|contribs]]) 09:29, 28 July 2012</span></small><!-- Template:Unsigned -->

			:If you feel up to making corrections, by all means do. =) {:User:Dinoguy1000/signature}} 11:14, 28 July 2012 (EDT)

94.12.161.209 at 09:29, 28 July 2012

2012-07-28T09:29:12Z

← Older revision	Revision as of 09:29, 28 July 2012
(No difference)

94.12.161.209 at 09:29, 28 July 2012

2012-07-28T09:29:12Z

← Older revision		Revision as of 09:29, 28 July 2012
Line 99:		Line 99:

	--[[User:Mr.Mouse\|Mr.Mouse]] 03:24, 20 October 2006 (EDT)		--[[User:Mr.Mouse\|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".

imported>Mr.Mouse: Reverted edits by YhaSnf (Talk); changed back to last version by Dinoguy1000

2007-04-12T11:06:46Z

Reverted edits by YhaSnf (Talk); changed back to last version by Dinoguy1000

← Older revision	Revision as of 11:06, 12 April 2007
(No difference)

imported>Mr.Mouse: Reverted edits by YhaSnf (Talk); changed back to last version by Dinoguy1000

2007-04-12T11:06:46Z

Reverted edits by YhaSnf (Talk); changed back to last version by Dinoguy1000

← Older revision		Revision as of 11:06, 12 April 2007
Line 46:		Line 46:
	(I know this isn't explained well, but hopefully someone can interpret this into normality. :D )		(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		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<sup>7</sup> + 0x2<sup>6</sup> + <all zeros> + 0x2<sup>1</sup> + 0x2<sup>0</sup> = 128

			Signed: -1x2<sup>7</sup> + 0x2<sup>6</sup> + <all zeros> + 0x2<sup>1</sup> + 0x2<sup>0</sup> = -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). --[[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)

			=== [[DGTEFF#Big-Endian and Little-Endian\|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:

			{\| border="1"
			\|-
			\|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? {{:User:Dinoguy1000/Signature}} 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 ;) .

			--[[User:Mr.Mouse\|Mr.Mouse]] 03:24, 20 October 2006 (EDT)

imported>YhaSnf at 22:00, 11 April 2007

2007-04-11T22:00:16Z

← Older revision	Revision as of 22:00, 11 April 2007
(No difference)

imported>YhaSnf at 22:00, 11 April 2007

2007-04-11T22:00:16Z

← Older revision		Revision as of 22:00, 11 April 2007
Line 46:		Line 46:
	(I know this isn't explained well, but hopefully someone can interpret this into normality. :D )		(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.		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

	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<sup>7</sup> + 0x2<sup>6</sup> + <all zeros> + 0x2<sup>1</sup> + 0x2<sup>0</sup> = 128~~

	~~Signed: -1x2<sup>7</sup> + 0x2<sup>6</sup> + <all zeros> + 0x2<sup>1</sup> + 0x2<sup>0</sup> = -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). --[[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)

	~~=== [[DGTEFF#Big-Endian and Little-Endian\|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:~~

	~~{\| border="1"~~
	\|-
	~~\|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? {{:User:Dinoguy1000/Signature}} 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 ;) .

	~~--[[User:Mr.Mouse\|Mr.Mouse]] 03:24, 20 October 2006 (EDT)~~

imported>Dinoguy1000: Reverted edits by 86.57.173.34 (Talk); changed back to last version by Dinoguy1000

2006-12-25T02:26:29Z

Reverted edits by 86.57.173.34 (Talk); changed back to last version by Dinoguy1000

← Older revision	Revision as of 02:26, 25 December 2006
(No difference)

imported>Dinoguy1000: Reverted edits by 86.57.173.34 (Talk); changed back to last version by Dinoguy1000

2006-12-25T02:26:29Z

Reverted edits by 86.57.173.34 (Talk); changed back to last version by Dinoguy1000

← Older revision		Revision as of 02:26, 25 December 2006
Line 99:		Line 99:

	--[[User:Mr.Mouse\|Mr.Mouse]] 03:24, 20 October 2006 (EDT)		--[[User:Mr.Mouse\|Mr.Mouse]] 03:24, 20 October 2006 (EDT)

	~~== hoodia ==~~

	~~Perfect work.~~
	~~I wish my page was so good and informative.~~
	~~<a href="http://hoodia-4you.blogspot.com/">hoodia</a>~~
	~~[url=http://hoodia-4you.blogspot.com/]hoodia[/url]~~