cvs.gedasymbols.org/archives/browse.cgi   search  
Mail Archives: djgpp-workers/1998/01/01/23:44:03

Date: Thu, 1 Jan 1998 23:43:51 -0500 (EST)
Message-Id: <199801020443.XAA04096@delorie.com>
From: DJ Delorie <dj AT delorie DOT com>
To: Vik DOT Heyndrickx AT rug DOT ac DOT be
CC: djgpp-workers AT delorie DOT com
In-reply-to: <349A4CEA.63DA@rug.ac.be> (message from Vik Heyndrickx on Fri, 19
Dec 1997 11:31:06 +0100)
Subject: Re: minor bug in stub for 2.02

> I think I found a minor bug in stub.asm, but I haven't had the time to
> correct it. 

Did you read that comment at the beginning of stub.asm that baseically
said "Don't even *look* here unless you *really* know what you're
doing"?  It applies!

> The program's environment is scanned for the end while keeping track of
> the location of environment variable PATH. Whenever PATH would be the
> first env. var. in the list, it will not be seen.

Just before the loop (where the rep/scasb is that skips to the null)
there's a "db 0xa9".  What's that for?  Well, the first time through,
that byte turns the "rep scasb" into "test ax,..." and the next opcode
is the compare for PATH.  The end result is that the first thing it
does is look for "PATH", *not* scan for the null!

This is faster and shorter than coding a "jmp check_path_first" just
before the "scan_environment" label.

Note that this means at the end of the loop, we (effectively) jump
into the middle of an opcode!

Assembler programmers are *not* known to produce maintainable (or even
readable) code.

Of course, all of this means that we may still be wrong.  Did you
actually test it, or just inspect it?

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019