Started integrating Windows Debugger segment load info with PCjs Debugger symbol tables

blog/2014/10/26/README.md

@@ -23,28 +23,31 @@ To verify, type the following into any JavaScript REPL (eg, Node):
 	> n == -0x80000000
 	true
 
-So the notion that bitwise operators yield 32-bit results isn't exactly right; the sign (bit 31) of every 32-bit
-result is always extended into the entire 52 "significand" bits of the underlying 64-bit float.  And it's
-impossible to simply "mask away" those additional sign bits, thanks to the fundamental restriction of JavaScript bitwise
-operators: they operate *only* on the low 32 bits.
+The sign (bit 31) of every 32-bit result is always extended into the entire 52 "significand" bits of the underlying
+64-bit float.  And it's impossible to simply "mask away" those additional sign bits, thanks to a fundamental
+restriction of JavaScript bitwise operators: they operate *only* on the low 32 bits.
 
-The easiest way to remove the high-order sign bits from a negative 32-bit value is to add the 33-bit value 0x100000000:
+With one exception: the unsigned right-shift operator.  It does more than simply shift zero bits in from
+the left; it also zeros all the bits above the sign bit.  This means that `n >>> 0`, while leaving the low 32 bits
+unchanged, also clears the upper bits, resulting in a value that is positive, albeit outside the signed 32-bit range.
+It is equivalent to adding the 33-bit value 0x100000000 to a negative 32-bit number:
 
 	> n = (n < 0? n + 0x100000000 : n)
 	2147483648
 	> n.toString(16)
 	'80000000'
 
-This works because JavaScript is perfectly capable of representing 0x80000000, or any other 32-bit value, as a positive
-number, albeit in floating point.  And be careful, because as soon as you perform *any* bitwise operation on a value
-with bit 31 set, even an operation as innocuous-looking as:
+These operations work because JavaScript is perfectly capable of representing 0x80000000, or any other 32-bit value,
+as a positive number, but it must use a floating point value to do so.  And be careful, because as soon as you perform
+*any* bitwise operation on a value with bit 31 set, even an operation as innocuous-looking as:
 
 	> n |= 0
 	-2147483648
 	> n.toString(16)
     '-80000000'
 
-Viola: instant negative number!
+the result will be negative again.  This is simply how all bitwise operators (except for unsigned right-shift) operate:
+they truncate the result to a signed 32-bit value.
 
 This might tempt you to think that the right way to write negative 32-bit constants in hex is to simply precede 
 them with a minus sign.  But that would be wrong.  For example, if you wrote the constant 0x80000080 as "-0x80000080",
@@ -52,8 +55,8 @@ JavaScript would treat that as negation of 2147483776, resulting in a value whos
 0x80000080.
 
 The safest way to write a 32-bit constant like 0x80000080 is "0x80000080|0", which will produce -2147483520.  If you
-write all your negative 32-bit constants that way, then you won't have to resort to 33-bit addition and potential
-floating point operations.
+write all your negative 32-bit constants that way, then you won't have to resort to using either unsigned right-shifts
+or 33-bit addition, which in turn avoids the use of floating point values.
 
 To continue the fun, try setting bit 0 of 0x80000000, which should give you 0x80000001:
 
@@ -71,4 +74,4 @@ explain, for a negative number, toString() returns the positive representation o
 *not* the "two's complement" of the number.
  
 *[@jeffpar](http://twitter.com/jeffpar)*  
-*October 26, 2014*
+*October 26, 2014 (Updated September 8, 2015)*