Re: Computer architects leaving Intel...

Liste des GroupesRevenir à c arch 
Sujet : Re: Computer architects leaving Intel...
De : cr88192 (at) *nospam* gmail.com (BGB)
Groupes : comp.arch
Date : 30. Aug 2024, 23:42:19
Autres entêtes
Organisation : A noiseless patient Spider
Message-ID : <vathse$m1vn$1@dont-email.me>
References : 1 2 3 4 5 6 7 8 9 10
User-Agent : Mozilla Thunderbird
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.

Date Sujet#  Auteur
27 Aug 24 * Computer architects leaving Intel...539Thomas Koenig
27 Aug 24 +- Re: Computer architects leaving Intel...1Michael S
27 Aug 24 +- Re: Computer architects leaving Intel...1Stephen Fuld
27 Aug 24 `* Re: Computer architects leaving Intel...536John Dallman
28 Aug 24  +* Re: Computer architects leaving Intel...529BGB
28 Aug 24  i`* Re: Computer architects leaving Intel...528MitchAlsup1
28 Aug 24  i `* Re: Computer architects leaving Intel...527BGB
28 Aug 24  i  +* Re: Computer architects leaving Intel...2Robert Finch
28 Aug 24  i  i`- Re: Computer architects leaving Intel...1BGB
28 Aug 24  i  `* Re: Computer architects leaving Intel...524MitchAlsup1
29 Aug 24  i   `* Re: Computer architects leaving Intel...523BGB
29 Aug 24  i    +* Re: Computer architects leaving Intel...511MitchAlsup1
29 Aug 24  i    i`* Re: Computer architects leaving Intel...510BGB
30 Aug 24  i    i +* Re: Computer architects leaving Intel...499John Dallman
30 Aug 24  i    i i+* Re: Computer architects leaving Intel...11Thomas Koenig
30 Aug 24  i    i ii+- Re: Computer architects leaving Intel...1Michael S
30 Aug 24  i    i ii+* Re: Computer architects leaving Intel...8Anton Ertl
30 Aug 24  i    i iii+* Re: Computer architects leaving Intel...2Michael S
30 Aug 24  i    i iiii`- Re: Computer architects leaving Intel...1Anton Ertl
30 Aug 24  i    i iii`* Re: Computer architects leaving Intel...5John Dallman
30 Aug 24  i    i iii `* Re: Computer architects leaving Intel...4Brett
30 Aug 24  i    i iii  +- Re: Computer architects leaving Intel...1John Dallman
2 Sep 24  i    i iii  `* Re: Computer architects leaving Intel...2Terje Mathisen
2 Sep 24  i    i iii   `- Re: Computer architects leaving Intel...1Thomas Koenig
30 Aug 24  i    i ii`- Re: Computer architects leaving Intel...1BGB
30 Aug 24  i    i i`* Re: Computer architects leaving Intel...487Anton Ertl
30 Aug 24  i    i i +* Re: Computer architects leaving Intel...302John Dallman
30 Aug 24  i    i i i`* Re: Computer architects leaving Intel...301David Brown
30 Aug 24  i    i i i +* Re: Computer architects leaving Intel...293Anton Ertl
30 Aug 24  i    i i i i`* Re: Computer architects leaving Intel...292Bernd Linsel
31 Aug 24  i    i i i i +- Re: Computer architects leaving Intel...1Thomas Koenig
31 Aug 24  i    i i i i `* Re: Computer architects leaving Intel...290Thomas Koenig
31 Aug 24  i    i i i i  +- Re: Computer architects leaving Intel...1Thomas Koenig
31 Aug 24  i    i i i i  `* Re: Computer architects leaving Intel...288Bernd Linsel
31 Aug 24  i    i i i i   +- Re: Computer architects leaving Intel...1Thomas Koenig
31 Aug 24  i    i i i i   +* Re: Computer architects leaving Intel...2Thomas Koenig
31 Aug 24  i    i i i i   i`- Re: Computer architects leaving Intel...1Bernd Linsel
31 Aug 24  i    i i i i   `* Re: Computer architects leaving Intel...284Anton Ertl
31 Aug 24  i    i i i i    +* Re: Computer architects leaving Intel...279Thomas Koenig
31 Aug 24  i    i i i i    i+* Re: Computer architects leaving Intel...157Bernd Linsel
31 Aug 24  i    i i i i    ii+* Re: Computer architects leaving Intel...153MitchAlsup1
1 Sep 24  i    i i i i    iii`* Re: Computer architects leaving Intel...152Stephen Fuld
2 Sep 24  i    i i i i    iii `* Re: Computer architects leaving Intel...151Terje Mathisen
2 Sep 24  i    i i i i    iii  `* Re: Computer architects leaving Intel...150Stephen Fuld
3 Sep 24  i    i i i i    iii   +* Re: Computer architects leaving Intel...139David Brown
3 Sep 24  i    i i i i    iii   i+* Re: Computer architects leaving Intel...108Stephen Fuld
4 Sep 24  i    i i i i    iii   ii`* Re: Computer architects leaving Intel...107David Brown
4 Sep 24  i    i i i i    iii   ii +* Re: Computer architects leaving Intel...103Terje Mathisen
4 Sep 24  i    i i i i    iii   ii i+* Re: Computer architects leaving Intel...101David Brown
4 Sep 24  i    i i i i    iii   ii ii+* Re: Computer architects leaving Intel...97jseigh
4 Sep 24  i    i i i i    iii   ii iii`* Re: Computer architects leaving Intel...96David Brown
4 Sep 24  i    i i i i    iii   ii iii `* Re: Computer architects leaving Intel...95Brett
4 Sep 24  i    i i i i    iii   ii iii  +- Re: Computer architects leaving Intel...1Thomas Koenig
4 Sep 24  i    i i i i    iii   ii iii  +- Re: Computer architects leaving Intel...1MitchAlsup1
5 Sep 24  i    i i i i    iii   ii iii  +* Re: Computer architects leaving Intel...8BGB
5 Sep 24  i    i i i i    iii   ii iii  i`* Re: Computer architects leaving Intel...7MitchAlsup1
5 Sep 24  i    i i i i    iii   ii iii  i `* Re: Computer architects leaving Intel...6David Brown
5 Sep 24  i    i i i i    iii   ii iii  i  `* Re: Computer architects leaving Intel...5Niklas Holsti
5 Sep 24  i    i i i i    iii   ii iii  i   `* Re: Computer architects leaving Intel...4David Brown
6 Sep 24  i    i i i i    iii   ii iii  i    `* Re: Computer architects leaving Intel...3BGB
6 Sep 24  i    i i i i    iii   ii iii  i     `* Re: Computer architects leaving Intel...2David Brown
9 Sep 24  i    i i i i    iii   ii iii  i      `- Re: Computer architects leaving Intel...1BGB
5 Sep 24  i    i i i i    iii   ii iii  +* Re: Computer architects leaving Intel...83David Brown
5 Sep 24  i    i i i i    iii   ii iii  i`* Re: Computer architects leaving Intel...82Terje Mathisen
5 Sep 24  i    i i i i    iii   ii iii  i +* Re: Computer architects leaving Intel...79David Brown
5 Sep 24  i    i i i i    iii   ii iii  i i+* Re: Computer architects leaving Intel...2Thomas Koenig
7 Sep 24  i    i i i i    iii   ii iii  i ii`- Re: Computer architects leaving Intel...1Tim Rentsch
5 Sep 24  i    i i i i    iii   ii iii  i i+* Re: Computer architects leaving Intel...74Terje Mathisen
5 Sep 24  i    i i i i    iii   ii iii  i ii+* Re: Computer architects leaving Intel...16David Brown
9 Sep 24  i    i i i i    iii   ii iii  i iii`* Re: Computer architects leaving Intel...15Terje Mathisen
9 Sep 24  i    i i i i    iii   ii iii  i iii +* Re: Computer architects leaving Intel...12David Brown
9 Sep 24  i    i i i i    iii   ii iii  i iii i`* Re: Computer architects leaving Intel...11Brett
10 Sep 24  i    i i i i    iii   ii iii  i iii i +* Re: Computer architects leaving Intel...5Terje Mathisen
10 Sep 24  i    i i i i    iii   ii iii  i iii i i`* Re: Computer architects leaving Intel...4Brett
10 Sep 24  i    i i i i    iii   ii iii  i iii i i +* Re: Computer architects leaving Intel...2Michael S
11 Sep 24  i    i i i i    iii   ii iii  i iii i i i`- Re: Computer architects leaving Intel...1Brett
11 Sep 24  i    i i i i    iii   ii iii  i iii i i `- Re: Computer architects leaving Intel...1Terje Mathisen
10 Sep 24  i    i i i i    iii   ii iii  i iii i `* Re: Computer architects leaving Intel...5David Brown
10 Sep 24  i    i i i i    iii   ii iii  i iii i  +* Re: Computer architects leaving Intel...3Anton Ertl
10 Sep 24  i    i i i i    iii   ii iii  i iii i  i`* Re: Computer architects leaving Intel...2David Brown
10 Sep 24  i    i i i i    iii   ii iii  i iii i  i `- Re: Computer architects leaving Intel...1Stefan Monnier
10 Sep 24  i    i i i i    iii   ii iii  i iii i  `- Re: Computer architects leaving Intel...1BGB
9 Sep 24  i    i i i i    iii   ii iii  i iii `* Re: Computer architects leaving Intel...2Michael S
10 Sep 24  i    i i i i    iii   ii iii  i iii  `- Re: Computer architects leaving Intel...1Michael S
5 Sep 24  i    i i i i    iii   ii iii  i ii+* Re: Computer architects leaving Intel...45Bernd Linsel
6 Sep 24  i    i i i i    iii   ii iii  i iii+- Re: Computer architects leaving Intel...1David Brown
9 Sep 24  i    i i i i    iii   ii iii  i iii+* Re: Computer architects leaving Intel...2Terje Mathisen
9 Sep 24  i    i i i i    iii   ii iii  i iiii`- Re: Computer architects leaving Intel...1Tim Rentsch
14 Sep 24  i    i i i i    iii   ii iii  i iii`* Re: Computer architects leaving Intel...41Kent Dickey
14 Sep 24  i    i i i i    iii   ii iii  i iii +* Re: Computer architects leaving Intel...32Anton Ertl
14 Sep 24  i    i i i i    iii   ii iii  i iii i+* Re: Computer architects leaving Intel...29MitchAlsup1
14 Sep 24  i    i i i i    iii   ii iii  i iii ii`* Re: Computer architects leaving Intel...28Thomas Koenig
15 Sep 24  i    i i i i    iii   ii iii  i iii ii `* Re: Computer architects leaving Intel...27David Brown
16 Sep 24  i    i i i i    iii   ii iii  i iii ii  +* Re: Computer architects leaving Intel...5Thomas Koenig
16 Sep 24  i    i i i i    iii   ii iii  i iii ii  i`* Re: Computer architects leaving Intel...4David Brown
16 Sep 24  i    i i i i    iii   ii iii  i iii ii  i `* Re: Computer architects leaving Intel...3Thomas Koenig
17 Sep 24  i    i i i i    iii   ii iii  i iii ii  i  +- Re: Upwards and downwards compatible, Computer architects leaving Intel...1John Levine
17 Sep 24  i    i i i i    iii   ii iii  i iii ii  i  `- Re: Computer architects leaving Intel...1David Brown
16 Sep 24  i    i i i i    iii   ii iii  i iii ii  `* Re: Computer architects leaving Intel...21Terje Mathisen
16 Sep 24  i    i i i i    iii   ii iii  i iii ii   `* Re: Computer architects leaving Intel...20David Brown
16 Sep 24  i    i i i i    iii   ii iii  i iii ii    +* Re: Computer architects leaving Intel...14Michael S
17 Sep 24  i    i i i i    iii   ii iii  i iii ii    `* Re: Computer architects leaving Intel...5Terje Mathisen
15 Sep 24  i    i i i i    iii   ii iii  i iii i`* Re: Computer architects leaving Intel...2BGB
14 Sep 24  i    i i i i    iii   ii iii  i iii +* Re: Computer architects leaving Intel...3Thomas Koenig
16 Sep 24  i    i i i i    iii   ii iii  i iii `* Re: Computer architects leaving Intel...5Tim Rentsch
6 Sep 24  i    i i i i    iii   ii iii  i ii+* Re: Computer architects leaving Intel...3Tim Rentsch
7 Sep 24  i    i i i i    iii   ii iii  i ii`* Re: Computer architects leaving Intel...9Chris M. Thomasson
5 Sep 24  i    i i i i    iii   ii iii  i i`* Re: Computer architects leaving Intel...2MitchAlsup1
5 Sep 24  i    i i i i    iii   ii iii  i `* Re: Computer architects leaving Intel...2MitchAlsup1
7 Sep 24  i    i i i i    iii   ii iii  `- Re: Computer architects leaving Intel...1Tim Rentsch
4 Sep 24  i    i i i i    iii   ii ii`* Re: Computer architects leaving Intel...3Thomas Koenig
6 Sep 24  i    i i i i    iii   ii i`- Re: Computer architects leaving Intel...1Chris M. Thomasson
4 Sep 24  i    i i i i    iii   ii +- Re: Computer architects leaving Intel...1jseigh
13 Sep 24  i    i i i i    iii   ii `* Re: Computer architects leaving Intel...2Stephen Fuld
3 Sep 24  i    i i i i    iii   i`* Re: Computer architects leaving Intel...30Stefan Monnier
3 Sep 24  i    i i i i    iii   `* Re: Computer architects leaving Intel...10Terje Mathisen
31 Aug 24  i    i i i i    ii`* Re: Computer architects leaving Intel...3Thomas Koenig
1 Sep 24  i    i i i i    i`* Re: Computer architects leaving Intel...121David Brown
1 Sep 24  i    i i i i    +* Re: Computer architects leaving Intel...3John Dallman
3 Sep 24  i    i i i i    `- Re: Computer architects leaving Intel...1Stefan Monnier
30 Aug 24  i    i i i +- Re: Computer architects leaving Intel...1MitchAlsup1
30 Aug 24  i    i i i +* Re: Computer architects leaving Intel...4Stefan Monnier
30 Aug 24  i    i i i `* Re: Computer architects leaving Intel...2John Dallman
8 Sep 24  i    i i `* Re: Computer architects leaving Intel...184Tim Rentsch
30 Aug 24  i    i `* Re: Computer architects leaving Intel...10MitchAlsup1
31 Aug 24  i    `* Re: Computer architects leaving Intel...11Paul A. Clayton
29 Aug 24  `* Re: Computer architects leaving Intel...6Anton Ertl

Haut de la page

Les messages affichés proviennent d'usenet.

NewsPortal