Very Computer

Quote:> architecture". How can an i486 package be for a different architecture
> than a 486 running an i486 kernel? Surely it isn't because the CPU is
> AMD.

And irregardless of the souped up 4x86 or 80486, i486 means Intel's 486
architecture.  AMD would have had to duplicate it perfectly to fully
qualify for i486 compatibility.

--

Software Developer, Engineering Services
Red Hat, Inc.

QUIPd 1.00: (355 of 539)
-> What is written without effort is in general read without pleasure.
-> - Samuel Johnson

AM> I tried --rebuilding this package on my athlon for the i486, with
AM> the--target i486 option. I then took the rpm, with i486 as part of its
AM> filename, out of the RPMS/i486 directory and sent it to my 486. Rpm on
AM> the 486 would not work with it since it was "for a different
AM> architecture". How can an i486 package be for a different architecture
AM> than a 486 running an i486 kernel? Surely it isn't because the CPU is
AM> AMD.

--target i486?  I did not know there was such a target.  A '486 is just
a '386+'387 on a single piece of silicon.  Try --target i386.  I just
checked -- under /usr/src/linux/configs/ there is NO config for a i486,
just i386, i586, and i686 (RH 6.x, kernel 2.2.x).  While there are some
optimization options for the 486 under gcc, I don't think they make much
difference -- is the '486 really different from a '386+'387, from a code
generation point of view?  I *know* that putting the '387 logic on the
same chip as the '386 optimizes the hardware interface between the
integer ('386) and floating ('387) hardware, which gives a big speed up
(above an beyond the fact the the '486 uses a different flavor of
transister size (faster clock speeds)).

My guess is that '--target i486' did something weird and RPM on the
'486 was confused -- I suspect it is expecting a *.i386.rpm file.

AM> --
AM>         Angus March
AM>           VE2 UFP
AM> Concordia University Amateur Radio

AM> http://www.ece.concordia.ca/~ac_march/addr.html (very frivolous)
AM>  

--
                                     \/


http://www.deepsoft.com              /\FidoNet:    1:321/153

Quote:>Side question: what *exactly* does optimizing for a 'i486' mean?  Does
>the proper Intel 80486 have anything in it other than a 80386+80387 on
>a single chip (I'm talking about from a code-generation point of view)?
>Does gcc -m486 do anything really major?  The man pages (for gcc) say
>that code compiled -m486 will run on a i386.

--
        Angus March
          VE2 UFP
Concordia University Amateur Radio

http://www.ece.concordia.ca/~ac_march/addr.html (very frivolous)

Quote:>    Well, let me put it this way: I compiled a kernel for the 486,
> and I've never had a kernel problem. In fact, from what I know, the
> first thing the kernel would do is tell me that my CPU was
> incompatible if I done bad.

*shrug*

--

Software Developer, Engineering Services
Red Hat, Inc.

QUIPd 1.00: (193 of 539)
-> In theory, there is no difference between theory and practice. In
-> practice there is.
-> - Yogi Berra

A '486 is not just a '386+'387 on a single chip.  There are OTHER differences,
such as in the control and debug registers, a few new instructions (such as
CPUID), caching, and instruction pre-fetch.  Furthermore, a '486 is not a
Pentium ('586) either, since the Pentium family has even more internal changes.

If one is going to look that the code generation aspects of the compiler, then
for user applications, there is NO SIGNIFICANT DIFFERENCE at all, even between
a '386 and a Pentium 4 (or AMD K7, or whatever).  Only for "operating systems"
issues will there be a difference, and that difference will be in the OS
management specific structures and instructions.

------
To cross compile, one needs to recompile the compiler for the '486 instruction
set.  Setting "--486" or such similar option will not yield a pure
cross-platform compiler, because it could still compile in Pentium only
instructions.  I have seen that when compiling the file
/usr/src/linux/kernel/i386/i387.c which uses such instructions as FXSAVE or
LDMCSR which don't exist on the '486 but are happily included even in the 486
model if the compiler was built for the Pentium (or newer).

"S> To cross compile, one needs to recompile the compiler for the '486 instruction
"S> set.  Setting "--486" or such similar option will not yield a pure
"S> cross-platform compiler, because it could still compile in Pentium only
"S> instructions.  I have seen that when compiling the file
"S> /usr/src/linux/kernel/i386/i387.c which uses such instructions as FXSAVE or
"S> LDMCSR which don't exist on the '486 but are happily included even in the 486
"S> model if the compiler was built for the Pentium (or newer).

This suggests that the compiler is somewhat broken WRT 486 code
generation and does not properly handle the -m486 option, which
explains the lack of a kernel config for the 486.

"S>
"S>              

--
                                     \/


http://www.deepsoft.com              /\FidoNet:    1:321/153

"S> >AM> I tried --rebuilding this package on my athlon for the i486, with
"S> >AM> the--target i486 option. I then took the rpm, with i486 as part of its
"S> >AM> filename, out of the RPMS/i486 directory and sent it to my 486. Rpm on
"S> >AM> the 486 would not work with it since it was "for a different
"S> >AM> architecture". How can an i486 package be for a different architecture
"S> >AM> than a 486 running an i486 kernel? Surely it isn't because the CPU is
"S> >AM> AMD.
"S> >
"S> >--target i486?  I did not know there was such a target.  A '486 is just
"S> >a '386+'387 on a single piece of silicon.  Try --target i386.  I just
"S> >checked -- under /usr/src/linux/configs/ there is NO config for a i486,
"S> >just i386, i586, and i686 (RH 6.x, kernel 2.2.x).  While there are some
"S> >optimization options for the 486 under gcc, I don't think they make much
"S> >difference -- is the '486 really different from a '386+'387, from a code
"S> >generation point of view?  I *know* that putting the '387 logic on the
"S> >same chip as the '386 optimizes the hardware interface between the
"S> >integer ('386) and floating ('387) hardware, which gives a big speed up
"S> >(above an beyond the fact the the '486 uses a different flavor of
"S> >transister size (faster clock speeds)).
"S> >
"S> >My guess is that '--target i486' did something weird and RPM on the
"S> >'486 was confused -- I suspect it is expecting a *.i386.rpm file.
"S>
"S> Well, above is another answer from the completely clueless.
"S>
"S> A '486 is not just a '386+'387 on a single chip.  There are OTHER differences,
"S> such as in the control and debug registers, a few new instructions (such as
"S> CPUID), caching, and instruction pre-fetch.  Furthermore, a '486 is not a
"S> Pentium ('586) either, since the Pentium family has even more internal changes.

I *know* that a "'486 is not just a '386+'387", just I did not know that
there were any *significant* differences in terms of code generation
aspects of the compiler.  Even for O/S code.  I *never* seen a 486
kernel config file set, so I figured there was little point in such a
thing.

"S>
"S> If one is going to look that the code generation aspects of the compiler, then
"S> for user applications, there is NO SIGNIFICANT DIFFERENCE at all, even between
"S> a '386 and a Pentium 4 (or AMD K7, or whatever).  Only for "operating systems"
"S> issues will there be a difference, and that difference will be in the OS
"S> management specific structures and instructions.
"S>
"S> ------
"S> To cross compile, one needs to recompile the compiler for the '486 instruction
"S> set.  Setting "--486" or such similar option will not yield a pure
"S> cross-platform compiler, because it could still compile in Pentium only
"S> instructions.  I have seen that when compiling the file
"S> /usr/src/linux/kernel/i386/i387.c which uses such instructions as FXSAVE or
"S> LDMCSR which don't exist on the '486 but are happily included even in the 486
"S> model if the compiler was built for the Pentium (or newer).
"S>
"S>              

--
                                     \/


http://www.deepsoft.com              /\FidoNet:    1:321/153