Re: Hangs after "Loading" but before "Uncompressing"

From: Richard B. Johnson (root@chaos.analogic.com)
Date: Thu Jan 27 2000 - 11:56:07 EST


On Thu, 27 Jan 2000, Manfred Spraul wrote:

> "Richard B. Johnson" wrote:
> > Okay, you found the procedure that's hanging. Now, I glanced through
> > video.S and I see where somebody has decided to use an undocumented
> > op-code. At line 1010, there is a GS segment override for LODSW.
> >
> > Segment overrides are not specified to work with the ix86 string
> > opcodes.
>
> No. Segment overrides work with string _load_ instructions, and that's
> documented. They do not work with string _store_ instructions:
>
> Pentium Processor Family Developoer's Manual, Volume 3, Chapter 4.6.2
> [STRING OPERATIONS]
> <<<<<<<<
> The ESI register points to source operands. By default, the ESI register
> is used with the DS segment register. A segment-override prefix allows
> the ESI register to be used with the CS, SS, ES, FS or GS segment
> registers. The EDI register points to destination operands. It uses the
> segment indicated by the ES segment register; no segment override is
> allowed.
> >>>>>>>>>

Well! We went over this two years ago. The problem is that segment
overrides are specifically excluded for the LODS, LODSB, LODSW, and
LODSD instructions on the '486. (Page 16-203, Intel Rag called
Intel 486 Microprocessor Family, Programmer's Reference Manual).
This comes about (shown on page E-23) because the sreg field
is two bits on some instructions and 3 bits on others. Three
bits allows FS and GS segments to be specified, two bits allows
only the ES, CS, DS, and SS segments. The sreg field in the
LODxx instruction does not exist! (page E-9). So you get whatever
you get.

However, many respondents showed that they __worked__! It was the
general consensus that we had better not use such undocumented
op-codes even if for no other reason that a segment-prefix is an
extra instruction that eats CPU time.

There is absolutely no reason whatsoever to use segment-overides in
any of the code. The problem is that to eliminate them would require
a complete rewrite from scratch. The original 'asm' boot code was
not too bad. However, through the years it's been added to in many
"strange and wonderful" ways. The result is obvious. The recent
rewrite to GAS assembly did not improve anything.

Cheers,
Dick Johnson

Penguin : Linux version 2.3.39 on an i686 machine (800.63 BogoMips).

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/



This archive was generated by hypermail 2b29 : Mon Jan 31 2000 - 21:00:18 EST