64 bit architectures and C/C++

[jeh at cmkrnl.uucp]

In article <521 at heurikon.heurikon.com>, daves at ex.heurikon.com (Dave Scidmore)
 writes:
> [...]
> On the other hand the little
> endian convention looks odd when you do a dump of memory and try to find long
> words within a series of bytes.

Yup.  But this can be solved.  The VAX is a little-endian machine, and VMS
utilities address [ahem] this problem by always showing hex contents with
increasing addresses going from right to left across the page.  Since
significance of the bytes (actually the nibbles) increases with increasing
addresses, this looks perfectly correct... the most significant nibble goes on
the left, just the way you'd "naturally" write it.  For example, the value 1
stored in 32 bits gets displayed as 00000001.  

If you get a hex-plus-Ascii dump, such as is produced by DUMP (for files) or
ANALYZE/SYSTEM (lets you look at live memory), the hex goes from right to left,
and the ascii from left to right, like this: 

SDA> ex 200;60
0130011A 0120011B 0130011E 0110011F  ......0... ...0.     00000200
01200107 02300510 04310216 04210218  ..!...1...0... .     00000210
01100103 01100104 01200105 01200106  .. ... .........     00000220
44412107 01100100 01100101 01100102  .............!AD     00000230
4B202020 20444121 44412106 42582321  !#XB.!AD!AD    K     00000240
00524553 55525055 53434558 454E5245  ERNEXECSUPRUSER.     00000250

In the last row, the string "EXEC" is at address 253, and the last byte on the
line, 25F, contains hex 00.  In the first row, the word (16 bits) at location
204 contains hex value 11E; if you address the same location as a longword, you
get the value 0130011E.  

This looks completely bizarre at first, but once you get used to it (a few
minutes or so for most folks) it makes perfect sense.  

The VAX is consistent in bit numbering too:  The least significant bit of a 
byte is called bit 0, and when you draw bit maps of bytes or larger items,
you always put the lsb on the right.  

	--- Jamie Hanrahan, Kernel Mode Consulting, San Diego CA
Chair, VMS Internals Working Group, U.S. DECUS VAX Systems SIG 
Internet:  jeh at dcs.simpact.com, hanrahan at eisner.decus.org, or jeh at crash.cts.com
Uucp:  ...{crash,scubed,decwrl}!simpact!cmkrnl!jeh