Re: Computer architects leaving Intel...

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

On 8/29/2024 11:23 AM, MitchAlsup1 wrote:

>

Time to up your game to an industrial quality ISA.

>
Open question of what an "industrial quality" ISA has that BJX2 lacks...
   Limiting the scope to things that RISC-V and ARM have.

>
Proper handling of exceptions (ignoring them is not proper)

>
If you mean FPU exceptions, maybe.
>
As far as general interrupt handling, mechanism isn't too far off from
what SH-4 had used, and apparently also RISC-V's CLINT and MIPS work in
a similar way.
>
Though, with differences as to how they divide up exceptions.
   In my case:
     Reset;
     General Fault;
     External Interrupt;
     TLB/MMU;
     Syscall.

Integer Overflow
Bad Instruction encoding--OpCode exists but not as this
    instruction uses it. Random code generation can use
    every instruction without privilege.
Bad address--address exists but you are not allowed to touch it
    with LD or ST instruction or to attempt to execute it.

>

Proper IEEE 754-2018 handling of FMAC (compute all the  bits)

>
Possibly true.
My FPU can more-or-less pass the 1985 spec, but not the 2018 spec.

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.

>

Floating Point Transcendentals

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

Its time has come.

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 ??

>
Seems many of the extant RV implementations don't have this either.

Then not of Industrial quality !!

Write Interrupt service routines entirely in HLL

>
If you mean C... I do have this.
>
#ifdef TK_REGSAVE_TBR
__interrupt_tbrsave void __isr_syscall(void)
#else
__interrupt void __isr_syscall(void)
#endif
{
....
}

So there is NO (nadda == 0) ASM instructions between "Core takes
interrupt" and control arrives at __isr_call() ??

AKA: What exactly is the '__interrupt' for?...
>
However, the ISR's can't access virtual memory apart from manually
translating the pointers.
>
The various architectural CR's can be accessed from C as well, such as
"__arch_tbr" to access TBR, etc.
>
>

proper Privileges and Priorities

>
?...

OS cannot access Hypervisor data/code
Hypervisor cannot access Secure Monitor data/code
Every thread runs at its proper priority at all cycles that it has
control.
Thus, you cannot receive interrupt control and then set priority,
priority
needs to be part of delivering control.
Threads are always re-entrant eave the instant they receive control.
Application can call OS
OS can call Hypervisor
Hypervisor can call secure Monitor
as easily as thread can call itself.
Interrupts need no maintenance when Hypervisor changes OS[k] to OS[j]
Interrupts need no maintenance when Secure monitor changes
Hypervisor[k] to Hypervisor]j]
System has a means to detect DRAM failures and map-out affected
pages.
System has a means to detect Device failure and restart device
or change mapping to device.

>

Multi-location ATOMIC events

>
Possibly true.
   Maybe the "volatile" mechanism is weak.