On 8/30/2024 1:11 PM, MitchAlsup1 wrote:
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
Not usually a thing. Pretty much everything seems to treat integer overflow as silently wrapping.
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.
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).
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 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.
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.
One other option could be a TTL, say, where a request times out and "decays' into a response if it cycles the bus for long enough.
>
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.
AFAICT, this wasn't required for the 1985 spec...
Things like "optional trap on denormal" seems like it should be OK (this is what MIPS and friends did at the time).
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.
The lack of single-rounded FMA shouldn't matter, since this wasn't added until later.
Support for Binary16 is a bonus feature (since 85 spec only gave Single / Double / Extended), but Binary16 is useful...
>
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?...
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.
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.
Granted, running the main OS in an emulator wouldn't be great for performance. But, in most contexts, this isn't really a thing.
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).
But, in any case, one doesn't need any special ISA level support to make things like QEMU and DOSBox work.
And, if a person wants to essentially use something like QEMU to run the whole OS, nothing really is stopping them.
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).
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").
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).
>
Seems many of the extant RV implementations don't have this either.
Then not of Industrial quality !!
They are releasing a lot of devboards.
There is also now a RISC-V laptop, and I think I saw a video with a RISC-V based ATX motherboard some months back.
They basically work, albeit they struggle to run anything much newer than OpenArena, or YouTube videos at resolutions much over 240p or so.
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() ??
OK, there is a dispatch table and some extra branches and NOPs and similar (when building a PE image).
isr_syscall:
#ifndef __USRONLY__
mov 0x123456789ABCDEF, r16 //96-bit pad
//adjust return point to be somewhere after syscall op
mov spc, r16
add 8, r16
mov r16, spc
bra __isr_syscall
#endif
nop
nop
nop
break
nop
isr_tlbfault:
#ifndef __USRONLY__
bra __isr_tlbfault
#endif
nop
nop
nop
break
nop
.balign 128
isr_table:
bra8b _start
bra8b isr_except
bra8b isr_inter
bra8b isr_tlbfault
bra8b isr_syscall
// bra8b __isr_syscall
nop4b
nop4b
nop4b
nop4b
For the BootROM, the compiler generates the table directly.
The wonk for adjusting SPC in ASM may need to go away (and be handled by the syscall ISR), as it is possible that GLIBC's syscall instruction wont be followed by generous NOPs (it is necessary to adjust the saved PC to be to a point after the SYSCALL / EBREAK instruction, but I wasn't super confident that SPC will always point exactly at the instruction in question).
Either way this sort of manual adjustment was needed to avoid getting stuck in an infinite loop (default behavior of the interrupt mechanism would result in it endlessly re-executing the instruction; which is not the correct behavior for SYSCALL).
If I moved this to C, it would basically be the same as the TLB fault case.
Some of this was also "debugging paranoia"...
Or, maybe could do it like:
.balign 128
isr_table:
#ifndef __USRONLY__
bra8b _start
bra8b __isr_except
bra8b __isr_inter
bra8b __isr_tlbfault
bra8b __isr_syscall
#else
bra8b __isr_debugbreak
bra8b __isr_debugbreak
bra8b __isr_debugbreak
bra8b __isr_debugbreak
bra8b __isr_debugbreak
#endif
nop4b
nop4b
nop4b
nop4b
Where, the ".balign" is mostly because the interrupt mechanism generates the target address using bit-slicing.
Only way to totally eliminate this would be to either have the compiler generate the branch table in this case, or give each ISR its own CR (not gonna happen).
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.
I am not really aware of all that many systems where this sort of thing is actually a thing.
AFAIK, mostly it is limited to x86-64 and newer ARM variants.
>
Multi-location ATOMIC events
>
Possibly true.
Maybe the "volatile" mechanism is weak.
Computer architects leaving Intel...
Re: Computer architects leaving Intel...
