Re: Intel Assembly error

[Vasilis Vasaitis <vasaitv@visual.bt.co.uk>]

On Fri, Aug 18, 2000 at 09:54:20AM -0500, Joseph Carter wrote:
> On Wed, Aug 16, 2000 at 10:27:45AM +0200, Paul Slootman wrote:
> > No, you have AH to access the high 16 bits of EAX, and AL for the low
> > 16 bits of EAX. Or was that the high 8 bits of AX etc...
> 
> Here's the layout of the EAX register...
> 
> |              EAX             |
> |               |      AX      |
> |               |  AH  ||  AL  |
> 
> I do not know if there is a way to access the rest of EAX when accessing
> AX, AL, etc.  Not sure how endianness applies to EAX offhand (I've been up
> a whole 10 minutes) but given 0x12345678 in EAX, AX may contain 0x5678
> which is where the confusion comes from.  I'd have to write some asm to be
> sure about that and I haven't done any in more than six years - and then
> my assembler didn't have 386 instructions so I was limited to db 66h'ing
> my accesses of AX if I wished to access EAX so I didn't use 386
> instructions except for memory copying and the like.

  OK, here goes. If EAX contains 0x12345678, then AX contains 0x5678, AL
contains 0x78 and AH contains 0x56. Note that this has nothing to do with
endianness, really.

> > Apart from that, using assembler is evil (if there isn't a C language
> > alternative) because then your source will never run on anything
> > besides the processor the assembler code is written for.
> 
> I think the problem is this is what gcc was doing to the C.  I never
> became clear on that.  Sometimes that C alternative is only useful for
> porting the asm to a new language because the C would run too slowly for
> acceptable results.  (quake for example..)

  Many libraries, such as GMP or Hermes, have generic C versions of some
code as well as hand-written, optimized assembly versions for particular
processors. This way the library runs everywhere, and it runs really fast
almost everywhere.

-- 
Vasilis Vasaitis
vasaitv@visual.bt.co.uk