Re: Computer architects leaving Intel...

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).

>
Things like "optional trap on denormal" seems like it should be OK (this
is what MIPS and friends did at the time).

I am talking about FMUL and getting the proper result--no
denorms needed.

For the most part, seems like the '85 spec was more "uses these formats
and gets more or less the same values, good enough". A lot of the
pedantic rounding stuff, etc, seemed to be more something for the 2008
spec.

Then you fail to grasp the spirit of the spec.

>
>
The lack of single-rounded FMA shouldn't matter, since this wasn't added
until later.

It was in the 19985 spec.

Support for Binary16 is a bonus feature (since 85 spec only gave Single
/ Double / Extended), but Binary16 is useful...

So is a dildo for some people. Irrelevant to the issues at hand.

>

>

Floating Point Transcendentals

>
Not present in many/most ISA's I have looked at.

>
Its time has come.
>

>
Then who has done it, besides x87 and similar?...

I am talking about transcendentals that take FDIV number of cycles
Not FADD taking 200 cycles.

Not going to put much weight in something if:
The only real known example is the legacy x87 ISA;
Pretty much everyone else (including on x86-64) is using unrolled
Taylor-series expansion and similar.

At least spell it Chebychev.

>
>

HyperVisors/Secure Monitors

>
Possible. I had considered doing it essentially with emulators, but
granted, this is not quite the same thing.

>
How can something of lesser privilege emulate something of greater
privilege ??
>

>
Top level OS (or hypervisor layer) runs an emulator, which runs any VMs
holding guest OS instances.

But if the most you have is Supervisor how do you emulate something
of higher privilege efficiently ??

>
Granted, running the main OS in an emulator wouldn't be great for
performance. But, in most contexts, this isn't really a thing.

Quit acting stupid. You are better than that.

Like, pretty sure Windows and Linux still tend to run bare-metal on most
systems, ... (or, if a VM layer exists, it is unclear what if-any
purpose it would serve).

You can run both windows and linux at the same time.
Windows for games and documents, linux for CAD.

>
But, in any case, one doesn't need any special ISA level support to make
things like QEMU and DOSBox work.

Quit acting stupid. You are better than that.

>
And, if a person wants to essentially use something like QEMU to run the
whole OS, nothing really is stopping them.

Quit acting stupid. You are better than that.

>
Well, except maybe how slow that QEMU and DOSBox tend to be on something
like a RasPi (on a 50MHz CPU, one would likely be hard-pressed to even
run something like SimCity at acceptable speeds).

Quit acting stupid. You are better than that.

>
>
Not yet tried porting something like DOSBox to my stuff though...
>
>
But, a more clever emulator could likely leverage things like hardware
address translation and maybe only JIT parts of the target system (vs,
say, fully emulating the memory access and using JIT compilation or
interpretation for "pretty much everything").

You need efficient 2-level (or more) translation.

>
Say, for example, if the host system and guest OS are running the same
ISA (vs, say, the guest OS running x86 or x86-64; on a host running a
different ISA).

What if one thread wants 386, another wants 486, another x86-64
AND all three get the proper undefined instruction trapping.