On Fri, Mar 26, 2010 at 11:03:09AM -0700, Linus Torvalds wrote:
> On Fri, 26 Mar 2010, Ralf Baechle wrote:
> > "The documentation on the 80386 and 80486 states that op1 is undefined if
> > op2 is 0. In reality the 80386 will leave the value in op1 unchanged.
> > The first versions of the 80486 will change op1 to an undefined value.
> > Later version again will leave it unchanged."
> >
> > [1] Die Intel Familie in German language, by Robert Hummel, 1992
>
> Ok, that explains my memory of us having tried this, at least.
>
> But I do wonder if any of the people working for Intel could ask the CPU
> architects whether we could depend on the "don't write" for 64-bit mode.
> If AMD already documents the don't-touch semantics, and if Intel were to
> be ok with documenting it for their 64-bit capable CPU's, we wouldn't then
> need to rely on undefined behavior.
I don't know whether we can get it /documented/, but the architect I
asked said "We'll never get away with reverting to the older behavior,
so in essence the architecture is set to not overwrite."
--
Matthew Wilcox Intel Open Source Technology Centre
"Bill, look, we understand that you're interested in selling us this
operating system, but compare it to ours. We can't possibly take such
a retrograde step."
Matthew Wilcox <[email protected]> wrote:
> I don't know whether we can get it /documented/, but the architect I
> asked said "We'll never get away with reverting to the older behavior,
> so in essence the architecture is set to not overwrite."
Does that mean we can rely on it? Linus?
David
On 04/14/2010 02:49 PM, David Howells wrote:
> Matthew Wilcox<[email protected]> wrote:
>
>
>> I don't know whether we can get it /documented/, but the architect I
>> asked said "We'll never get away with reverting to the older behavior,
>> so in essence the architecture is set to not overwrite."
>>
> Does that mean we can rely on it? Linus?
>
Even if Intel processors behave that way, other processors (real and
emulated) use those manuals as a specification. Emulated processors are
unlikely to touch an undefined register, but real processors may.
(qemu tcg appears not to touch the output)
--
error compiling committee.c: too many arguments to function
Avi Kivity <[email protected]> wrote:
> Even if Intel processors behave that way, other processors (real and
> emulated) use those manuals as a specification. Emulated processors are
> unlikely to touch an undefined register, but real processors may.
>
> (qemu tcg appears not to touch the output)
Possibly because the AMD64 spec specifies that the destination will be
unchanged if the source was 0.
David
On 04/15/2010 11:48 AM, David Howells wrote:
> Avi Kivity<[email protected]> wrote:
>
>
>> Even if Intel processors behave that way, other processors (real and
>> emulated) use those manuals as a specification. Emulated processors are
>> unlikely to touch an undefined register, but real processors may.
>>
>> (qemu tcg appears not to touch the output)
>>
> Possibly because the AMD64 spec specifies that the destination will be
> unchanged if the source was 0.
>
Likely. But we haven't tested all current and future x86 clones, and
they may be based off the Intel documentation instead of the AMD
documentation.
--
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.
Avi Kivity wrote:
> Likely. But we haven't tested all current and future x86 clones, and
> they may be based off the Intel documentation instead of the AMD
> documentation.
I wonder about that too. I got the impression Transmeta did lots of
testing real x86s in all sorts of corner cases, because the manuals
don't cover everything that the broad base of software depends on in
practice. Clone makers have to do it to a much higher standard than
emulators because you can't generally release patches...
I think Via (including whatever the CPU line was formerly called)
have been bitten a few times by not quite matching software
expectations.
Even Intel was caught on x86_64 at the beginning by slight differences
when they cloned AMD's design :-)
-- Jamie