From: user5857@newsgrouper.org.invalid
quadi posted:
> On Fri, 06 Feb 2026 16:37:00 +0000, John Dallman wrote:
>
> > Isn't that going to create opcode space pressure?
>
> Well, that will be less of an issue in an architecture where the
> instructions are stored in wider memory.
I would think that with 36-bit instructions, you have the OpCode space
to 'blow'...
> > How are you planning to handle UTF-8, UTF-16 and UTF-32 character data?
> > Creating UTF-9, UTF-18 and UTF-36 seems like pointless complexity.
>
> I think UTF-9 was described in an April 1st RFC. But I agree with that.
>
> Essentially, I am now thinking that a CPU with this architecture might
> have its primary application as a numerical co-processor for a
> conventional CPU. This would provide the opportunity for carrying out
> computations with extra exponent range or higher precision without having
> to switch to a much larger floating-point format, thus avoiding loss of
> speed.
>
> One would need to create a new kind of RAM module to support a 144-bit
> wide data bus, but it would be unrealistic to create new video cards and
> so on.
>
> So it would have its own FORTRAN compiler - that would be the highest
> priority in software development, after some kind of operating system for
> the compiler to run within. Well, maybe porting a C compiler would need to
> come first, to allow everything else to be ported.
C and FORTRAN will put you in a position where everything is 9×2^n in
size, so you might as well just design a 72-bit machine. 72-bit registers
72-bit Virtual Address Space, ...
And then have the MMUs do translations between 8-bit Byte-world and 9-bit
Byte-world. Everything in CPU-land is 72-bits... Done right, LDs and STs
through certain PTEs "translate" between 64-bit world and 72-bit world.
If you have MMU doing the translation, you do not need 8×2^n instruction
calculations--saving OpCOde space {from Concertina III !}
> John Savard
Why Quadi ??
--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)
|
