Re: [masaki@eie.monolta.co.jp: GAS bug and etc]

Re: [masaki@eie.monolta.co.jp: GAS bug and etc]

[mycroft]

   The problem with using the 16-bit jcxz is that, even if the offset is
   small, if the target isn't in the first 64K of memory, the program is
   toast.  The reason is that %eip is masked to 0x0000ffff AFTER adding
   the offset.

The comment you're referring to:

rel16/32 indicates that these instructions map to two; one with a 16-bit
relative displacement, the other with a 32-bit relative displacement,
depending on the operand-size attribute of the instruction.

only applies to the `rel16/32' versions of the conditional jump
instructions.  The JCXZ and JECXZ instructions do not allow 16- or
32-bit displacements.

The `Operation' section for that instruction should be more clear.

BTW, why are you using JCXZ or JECXZ at all?  The equivalent sequence:

testl %ecx,%ecx
jz ...

is the same speed on the 386, but faster on the Pentium (and probably
the 486, but I don't have those timing specs).

[masaki@eie.monolta.co.jp: GAS bug and etc]

[Arthur Kreitman]

>   Date: Fri, 11 Nov 94 17:27:20 -0500
>   From: rms@gnu.ai.mit.edu (Richard Stallman)
>
>       The theory is that since gas must already support these 16-bit
>       instructions for the i386 anyway, it should be trivial to tell it that
>       the *default* size should be assumed different, so that it would
>       produce code that assumed it was running in a 16-bit segment instead
>       of a 32-bit segment.
>
>   Well, if the theory holds true, this won't cost us much.
>
>			     Then, the only work that would need to be done
>       is to produce dos-style OMF output, which is also used for some 32-bit
>      systems.
>
>   This isn't useful for the GNU system at all; it should have lower
>   priority than work that does help the GNU project.  That's crucial for
>   people who would work either on this or on some other GNU work.  I
>   hope they'll make sure they are not spending substantial time on this.

   I would also point out that if you're interested, as I am, in being 
compatible with the Evil Empire (Microsoft), that the value of any omf 
or sixteen bit work will be zero real soon. 

Re: [masaki@eie.monolta.co.jp: GAS bug and etc]

[Richard Stallman]

    The theory is that since gas must already support these 16-bit
    instructions for the i386 anyway, it should be trivial to tell it that
    the *default* size should be assumed different, so that it would
    produce code that assumed it was running in a 16-bit segment instead
    of a 32-bit segment.

Well, if the theory holds true, this won't cost us much.

			  Then, the only work that would need to be done
    is to produce dos-style OMF output, which is also used for some 32-bit
    systems.

This isn't useful for the GNU system at all; it should have lower
priority than work that does help the GNU project.  That's crucial for
people who would work either on this or on some other GNU work.  I
hope they'll make sure they are not spending substantial time on this.

Re: [masaki@eie.monolta.co.jp: GAS bug and etc]

[DJ Delorie]

> Supporting 16-bit mode assembly for the 386 is not harmful if it is
> easy, but if it takes up a lot of time, then it might be better off
> left out.  Do we need to have a program that runs in 16-bit mode for
> booting?  If so, how big a program would it have to be?  (I presume
> all it needs to do is switch to 32-bit mode.)  Might it be easier to
> hand assemble that program than to add and subsequently maintain this
> gas feature?

Even when in protected mode, the 386 and up processors support
variable width operations.  For example, when C calls for a "short",
the 386 uses a 16-bit register and thus needs 16-bit operations.  This
has nothing to do with the runtime mode of the CPU or the default size
of the segment (16 vs 32), and must be supported on all 386-based
systems, including Hurd.

The theory is that since gas must already support these 16-bit
instructions for the i386 anyway, it should be trivial to tell it that
the *default* size should be assumed different, so that it would
produce code that assumed it was running in a 16-bit segment instead
of a 32-bit segment.  Then, the only work that would need to be done
is to produce dos-style OMF output, which is also used for some 32-bit
systems.

As for the separate topic of bootstrapping 32-bit programs in the
16-bit world of DOS, we've got that covered already, so that you can
fully bootstrap djgpp 2.0 with nothing but GNU tools.  We wrote a VERY
simple 16-bit assembler with which to assemble the bootstrap code.

DJ

Re: [masaki@eie.monolta.co.jp: GAS bug and etc]

[Richard Stallman]

Supporting 16-bit mode assembly for the 386 is not harmful if it is
easy, but if it takes up a lot of time, then it might be better off
left out.  Do we need to have a program that runs in 16-bit mode for
booting?  If so, how big a program would it have to be?  (I presume
all it needs to do is switch to 32-bit mode.)  Might it be easier to
hand assemble that program than to add and subsequently maintain this
gas feature?

Re: [masaki@eie.monolta.co.jp: GAS bug and etc]

[H.J. Lu]

> 
> > I think gas will add a right address prefix automatically when it sees
> > a large offset. Ken?
> 
> The problem with using the 16-bit jcxz is that, even if the offset is
> small, if the target isn't in the first 64K of memory, the program is

How big is your offset? I need to know the exact number. FYI,
jcxz/jecxz can only take a signed byte disp. But gas treats the
disp as unsigned byte.

> toast.  The reason is that %eip is masked to 0x0000ffff AFTER adding
> the offset.  The 32-bit version doesn't do this.  I can't see this
> behavior being of *any* use in a 32-bit program, unless you *really*
> know what you're doing.
> 

Ken, Ian, I have sent you guys a patch for that. You don't like
it. It may bit them now.


-- 
H.J. Lu
NYNEX Science and Technology, Inc.			hjl@nynexst.com

Re: [masaki@eie.monolta.co.jp: GAS bug and etc]

[DJ Delorie]

> I think gas will add a right address prefix automatically when it sees
> a large offset. Ken?

The problem with using the 16-bit jcxz is that, even if the offset is
small, if the target isn't in the first 64K of memory, the program is
toast.  The reason is that %eip is masked to 0x0000ffff AFTER adding
the offset.  The 32-bit version doesn't do this.  I can't see this
behavior being of *any* use in a 32-bit program, unless you *really*
know what you're doing.

Re: [masaki@eie.monolta.co.jp: GAS bug and etc]

[H.J. Lu]

> 
> > Your patch jusr reversed what I did. Could you please tell
> > me why I was wrong and you were right? I thought I checked
> > the Intel x86 manual when I fixed that bug.
> 
> I didn't try to validate the patch; it was more of an FYI, which is
> why I included the header info.  If it's wrong, or you need more info,
> the original sender is the one to talk with (cc'd in both mails).
> Sorry if my intention wasn't clear.

I just hate that, especially when people say my patch is wrong without
doing their homework first :-).

> 
> Original sender:
> > From: masaki@eie.monolta.co.jp (Kenji  Masaki)
> 
> Note that the "jcxz" opcode in the gas that djgpp's libc was built
> with doesn't work as expected - jecxz does.  This might have confused
> people into thinking that there was a bug, or maybe there really is
> one.  jcxz is the 16-bit version (or pretends to be).
> 

jcxz and jecxz are totally different. One checks cx, the other
checks ecx. You have to decide what you want to use.

> Since jcxz uses both a register (opsize?) and an address (addrsize?),
> there may be a need for both prefixes.

I think gas will add a right address prefix automatically when it sees
a large offset. Ken?


-- 
H.J. Lu
NYNEX Science and Technology, Inc.			hjl@nynexst.com

Re: [masaki@eie.monolta.co.jp: GAS bug and etc]

[DJ Delorie]

> Your patch jusr reversed what I did. Could you please tell
> me why I was wrong and you were right? I thought I checked
> the Intel x86 manual when I fixed that bug.

I didn't try to validate the patch; it was more of an FYI, which is
why I included the header info.  If it's wrong, or you need more info,
the original sender is the one to talk with (cc'd in both mails).
Sorry if my intention wasn't clear.

Original sender:
> From: masaki@eie.monolta.co.jp (Kenji  Masaki)

Note that the "jcxz" opcode in the gas that djgpp's libc was built
with doesn't work as expected - jecxz does.  This might have confused
people into thinking that there was a bug, or maybe there really is
one.  jcxz is the 16-bit version (or pretends to be).

Since jcxz uses both a register (opsize?) and an address (addrsize?),
there may be a need for both prefixes.

DJ

Re: [masaki@eie.monolta.co.jp: GAS bug and etc]

[H.J. Lu]

Your patch jusr reversed what I did. Could you please tell
me why I was wrong and you were right? I thought I checked
the Intel x86 manual when I fixed that bug.

Thanks.

H.J.
-----
Thu Mar 31 19:34:08 1994  Ken Raeburn  (raeburn@cujo.cygnus.com)

	* i386.h (IS_JUMP_ON_ECX_ZERO, "jcxz" pattern): Operand size
	  prefix is 0x66, not 0x67.  Patch from H.J. Lu (hlu@nynexst.com). 
------
> 
> 
> Return-Path: <masaki@eie.minolta.co.jp>
> Date: Fri, 11 Nov 1994 14:27:09 +0900
> To: djgpp@sun.soe.clarkson.edu
> From: masaki@eie.monolta.co.jp (Kenji  Masaki)
> X-Sender: masaki@vivid.eie.minolta.co.jp
> Subject: GAS bug and etc
> Mime-Version: 1.0
> Content-Type: text/plain; charset=iso-2022-jp
> X-Mailer: Eudora-J(1.3.7-J12)
> DJ-Mail-Sort: djgpp@, djgpp
> 
> Hello.^[$B!!^[(BDJ and evrybody
> 
> We (members of FETX at Niftyserve in JAPAN) found a bug of GAS 2.3 , 2.5.1
> and 2.5.2 ,and FIX it as follows.
> 
> By the way, it seems that treatment of long-filename lacks unity in djgpp.
> i.e. _fixpath is called in stat(), while DPMI(DOS) function [is] called 
> directry in access.c.  Shouldn't it be standardized?
> 
>         
> diff --context=2 -r c:/binutils.2/include/opcode/i386.h
> d:/binutils.2/include/opcode/i386.h
> *** c:/binutils.2/include/opcode/i386.h        Thu Mar 31 16:35:32 1994
> --- d:/binutils.2/include/opcode/i386.h        Wed Nov  9 15:44:48 1994
> ***************
> *** 324,332 ****
>   /* these turn into pseudo operations when disp is larger than 8 bits */
>   #define IS_JUMP_ON_CX_ZERO(o) \
> !   (o == 0x66e3)
>   #define IS_JUMP_ON_ECX_ZERO(o) \
>     (o == 0xe3)
>   
> ! {"jcxz", 1, 0x66e3, _, JumpByte, { Disp, 0, 0} },
>   {"jecxz", 1, 0xe3, _, JumpByte, { Disp, 0, 0} },
>   --- 324,332 ----
>   /* these turn into pseudo operations when disp is larger than 8 bits */
>   #define IS_JUMP_ON_CX_ZERO(o) \
> !   (o == 0x67e3)   /* by members of FEXT niftyserve */
>   #define IS_JUMP_ON_ECX_ZERO(o) \
>     (o == 0xe3)
>   
> ! {"jcxz", 1, 0x67e3, _, JumpByte, { Disp, 0, 0} }, /* by members of FEXT
> niftyserve */
>   {"jecxz", 1, 0xe3, _, JumpByte, { Disp, 0, 0} },
>   
> ---------- Kenji Masaki
> ------------------------------
>     Kenji  Masaki^[$B!!^[(B
> ^[$B!!^[(B  Image Infomation Engineering
>      Division
>    MINOLTA  Co. Ltd. , JAPAN   
> ------------------------------

[masaki@eie.monolta.co.jp: GAS bug and etc]

[DJ Delorie]

Return-Path: <masaki@eie.minolta.co.jp>
Date: Fri, 11 Nov 1994 14:27:09 +0900
To: djgpp@sun.soe.clarkson.edu
From: masaki@eie.monolta.co.jp (Kenji  Masaki)
X-Sender: masaki@vivid.eie.minolta.co.jp
Subject: GAS bug and etc
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-2022-jp
X-Mailer: Eudora-J(1.3.7-J12)
DJ-Mail-Sort: djgpp@, djgpp

Hello.^[$B!!^[(BDJ and evrybody

We (members of FETX at Niftyserve in JAPAN) found a bug of GAS 2.3 , 2.5.1
and 2.5.2 ,and FIX it as follows.

By the way, it seems that treatment of long-filename lacks unity in djgpp.
i.e. _fixpath is called in stat(), while DPMI(DOS) function [is] called 
directry in access.c.  Shouldn't it be standardized?

        
diff --context=2 -r c:/binutils.2/include/opcode/i386.h
d:/binutils.2/include/opcode/i386.h
*** c:/binutils.2/include/opcode/i386.h        Thu Mar 31 16:35:32 1994
--- d:/binutils.2/include/opcode/i386.h        Wed Nov  9 15:44:48 1994
***************
*** 324,332 ****
  /* these turn into pseudo operations when disp is larger than 8 bits */
  #define IS_JUMP_ON_CX_ZERO(o) \
!   (o == 0x66e3)
  #define IS_JUMP_ON_ECX_ZERO(o) \
    (o == 0xe3)
  
! {"jcxz", 1, 0x66e3, _, JumpByte, { Disp, 0, 0} },
  {"jecxz", 1, 0xe3, _, JumpByte, { Disp, 0, 0} },
  --- 324,332 ----
  /* these turn into pseudo operations when disp is larger than 8 bits */
  #define IS_JUMP_ON_CX_ZERO(o) \
!   (o == 0x67e3)   /* by members of FEXT niftyserve */
  #define IS_JUMP_ON_ECX_ZERO(o) \
    (o == 0xe3)
  
! {"jcxz", 1, 0x67e3, _, JumpByte, { Disp, 0, 0} }, /* by members of FEXT
niftyserve */
  {"jecxz", 1, 0xe3, _, JumpByte, { Disp, 0, 0} },
  
---------- Kenji Masaki
------------------------------
    Kenji  Masaki^[$B!!^[(B
^[$B!!^[(B  Image Infomation Engineering
     Division
   MINOLTA  Co. Ltd. , JAPAN   
------------------------------