Re: Computer architects leaving Intel...

MitchAlsup1 wrote:

On Fri, 30 Aug 2024 22:42:19 +0000, BGB wrote:
 

On 8/30/2024 1:11 PM, MitchAlsup1 wrote:

On Thu, 29 Aug 2024 19:07:29 +0000, BGB wrote:
Integer Overflow

>
Not usually a thing. Pretty much everything seems to treat integer
overflow as silently wrapping.

 ADA wants these.
 

>
>

Bad Instruction encoding--OpCode exists but not as this
 Â Â  instruction uses it. Random code generation can use
 Â Â  every instruction without privilege.

>
Hit or miss.
>
Will usually fault on invalid instructions.

 Must be 100% to guarantee upwards compatibility.
 

There is logic in place to reject privileged instructions in user-mode,
if the CPU is actually run in user-mode. Some of this is still TODO
(currently, TestKern is still running everything in Supervisor Mode).

 Yes, it is a pain--but a pain that is absolutely worth it.
 

>
The alternative is to treat them as UB, so they may be one of:
   Trap;
   Do something else (like, if an instruction was added);
   Do something wonky / unintended.
>
In practice, this seems to be more how it works.

 Bad practice == not industrial quality.
 

>
 > Bad address--address exists but you are not allowed to touch it>   Â
with LD or ST instruction or to attempt to execute it.
>
If the MMU is enabled, it should fault on bad memory accesses.
>
In physical addressing mode, it does not trap.

 YOU FAIL TO UNDERSTAND--there is an area in memory where the
preserved registers are stored--stored in a way that only 3
instructions can access--and the PTE is marked RWE=000
This prevents damaging the contract between callee and caller.
3 instructions can access these pages ENTER, EXIT and RET
nothing else.
 

>
IIRC, there was a mechanism on the bus to deal with accesses to bad
physical addresses (returning all zeroes). Otherwise, trying to access
an invalid address would cause the CPU to deadlock.

 It is NOT a BAD address--it is a good but inaccessible address
outside those 3 instructions.

>
>

>
As I understand it, you don't even get FMUL correctly rounded.
To get it properly rounded you have to compute the full 53*53
product.

>
AFAICT, this wasn't required for the 1985 spec...

 You Cannot get rounding correct unless you "compute as if to
infinite precision" and then follow the rules of rounding
(all modes).

This rule is in fact really simple:
In all versions of the standard, from the very first up to the upcoming 2029, the core instructions (FADD/FSUB/FMUL/FDIV/FSQRT) MUST result in the correctly rounded result, according to whatever the current rounding mode is/was.
This does mean that you have to act as if you did the calculation to arbitrary/infinite precision, which really means "enough bits so that any following bits do not matter for the rounding result".
It was a revelation to me when I wrote my first fp emulation code and grok'ed how having a single guard bit followed by a sticky bit was sufficient to do this for all rounding modes.
At that point I only needed to maintain enough intermediate bits to guarantee I would still have those rounding bits after normalization.
This doesn't mean that I could skip calculating all the bits of the full NxN->2N mantissa product, only that I didn't need to keep them all around after normalization.
FMAC (with single rounding, which is the interesting one) you can of course get catastrophic cancellation, so you need all the 2N mantissa bits of the multiplication plus the N bits from the addend, then you either need a normalizer wide enough to take in any possibly alignments of the two parts, or you must have separate logic for each of the major cases.
Terje
--
- <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"