Re: Intel Assembly error
On Fri, 18 Aug 2000, Joseph Carter wrote: > 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. It is this way. AX ist the low part of EAX (Since eax and ax shall make the same for values less then 2^16.) And there is no direct way to address to higher 16 Bits. But as a shr eax,16 need only one cycle it is not that serious. Hochachtungsvoll, Bernhard R. Link
Re: Intel Assembly error
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 [EMAIL PROTECTED]
Re: Intel Assembly error
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. > 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..) -- Joseph Carter <[EMAIL PROTECTED]> GnuPG key 1024D/DCF9DAB3 Debian GNU/Linux (http://www.debian.org/) 20F6 2261 F185 7A3E 79FC The QuakeForge Project (http://quakeforge.net/) 44F9 8FF7 D7A3 DCF9 DAB3 dark: caldera? rcw - that's not a distribution, it's a curse Knghtbrd: it's a cursed distribution
Re: Intel Assembly error
Herbert Xu <[EMAIL PROTECTED]> wrote:
>
> int bradon;
> __asm__(".align 2,0x90\n1:\tdecl %0\n\tjns 1b"
> : "=a" (=brandon): "0" (loops));
Make that
int brandon;
__asm__ __volatile__(".align 2,0x90\n1:\tdecl %0\n\tjns 1b"
: "=a" (brandon): "0" (loops));
Oh, and you should probably upgrade your kernel as this is ancient.
--
Debian GNU/Linux 2.2 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: Intel Assembly error
Branden Robinson <[EMAIL PROTECTED]> wrote:
>> /* the original bogomips code from the Linux kernel */
>> static __inline__ void delay(int loops)
>> {
>> __asm__(".align 2,0x90\n1:\tdecl %0\n\tjns 1b": :"a" (loops):"ax");
>> }
You can either read the GCC FAQ or the GCC info on the details of this
problem.
But in order to add some signal to this message, the above line should be
rewritten as
int bradon;
__asm__(".align 2,0x90\n1:\tdecl %0\n\tjns 1b"
: "=a" (=brandon): "0" (loops));
> I am not an assembly guru on any architecture, but here's what I think this
> means. Please be warned that these could be the ravings of a deranged
> lunatic.
Which they are, as usual.
--
Debian GNU/Linux 2.2 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: Intel Assembly error
On Wed 16 Aug 2000, Branden Robinson wrote: > I am not an assembly guru on any architecture, but here's what I think this > means. Please be warned that these could be the ravings of a deranged > lunatic. Ditto. > The AX register is an old 16-bit register from 8086 days. When you're > running in 32-bit mode, as all Linux systems do, the register should be > accessed by its 32-bit name, EAX. Actually, I believe they are separate entities. > I think at some point gcc (or gas) used to automatically convert such > misreferences. There's a whole slew of register names on the IA32 from the > old 16-bit days that have a 32-bit version with the "E" prepended. > > (I think, in some contexts, you can actually use the 16-bit register names > to fetch the low-order 16 bits out of the actual 32-bit register.) 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... 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. Paul Slootman -- home: [EMAIL PROTECTED] http://www.wurtel.demon.nl/ work: [EMAIL PROTECTED] http://www.murphy.nl/ debian: [EMAIL PROTECTED] http://www.debian.org/ isdn4linux: [EMAIL PROTECTED] http://www.isdn4linux.de/
Re: Intel Assembly error
On Tue, Aug 15, 2000 at 04:44:37PM -0700, Richard Hecker wrote:
> I ran into a compiler error that I do not recognize. Instead of
> spinning my wheels further with this, I was hoping someone familiar
> with Intel assembly language on this list could shed some light on
> what is happening here. As can be seen from the comments, it is
> an ancient line that was lifted from the kernel. For this reason
> I am including the output from gcc -v.
>
> gcc -o 6x86_reg 6x86_reg.c
> 6x86_reg.c: In function `delay':
> 6x86_reg.c:86: Invalid `asm' statement:
> 6x86_reg.c:86: fixed or forbidden register 0 (ax) was spilled for class
> AREG.
>
> --- routine in the C source file ---
> /* the original bogomips code from the Linux kernel */
> static __inline__ void delay(int loops)
> {
> __asm__(".align 2,0x90\n1:\tdecl %0\n\tjns 1b": :"a" (loops):"ax");
> }
I am not an assembly guru on any architecture, but here's what I think this
means. Please be warned that these could be the ravings of a deranged
lunatic.
The AX register is an old 16-bit register from 8086 days. When you're
running in 32-bit mode, as all Linux systems do, the register should be
accessed by its 32-bit name, EAX.
I think at some point gcc (or gas) used to automatically convert such
misreferences. There's a whole slew of register names on the IA32 from the
old 16-bit days that have a 32-bit version with the "E" prepended.
(I think, in some contexts, you can actually use the 16-bit register names
to fetch the low-order 16 bits out of the actual 32-bit register.)
Hopefully someone who has actual knowledge will be able to answer your
question. Maybe Randolph Chung, who works for Intel? :)
--
G. Branden Robinson |A committee is a life form with six or
Debian GNU/Linux|more legs and no brain.
[EMAIL PROTECTED] |-- Robert Heinlein
http://www.debian.org/~branden/ |
pgpSuAivy5wCg.pgp
Description: PGP signature
Intel Assembly error
Hi;
I ran into a compiler error that I do not recognize. Instead of
spinning my wheels further with this, I was hoping someone familiar
with Intel assembly language on this list could shed some light on
what is happening here. As can be seen from the comments, it is
an ancient line that was lifted from the kernel. For this reason
I am including the output from gcc -v.
gcc -o 6x86_reg 6x86_reg.c
6x86_reg.c: In function `delay':
6x86_reg.c:86: Invalid `asm' statement:
6x86_reg.c:86: fixed or forbidden register 0 (ax) was spilled for class
AREG.
--- routine in the C source file ---
/* the original bogomips code from the Linux kernel */
static __inline__ void delay(int loops)
{
__asm__(".align 2,0x90\n1:\tdecl %0\n\tjns 1b": :"a" (loops):"ax");
}
--- output from my woody system ---
gcc -v
Reading specs from /usr/lib/gcc-lib/i386-linux/2.95.2/specs
gcc version 2.95.2 2220 (Debian GNU/Linux)
Thanks in advance.
--
Richard A. Hecker
"if it isn't source, it isn't software"
brought to you courtesy of NASA
