Re: New Vax - future directions :-)

[Mouse <mouse%Rodents-Montreal.ORG@localhost>]

>> Yes...but do you still have only 16 GPRs?
> Honestly, I donâ??t see a great deal of need to extend the register file on $

I don't see any particular need to, either, but it's the kind of thing
I would like to examine overtly, even if it ends up being discarded.

>>> The JMP/JSR/RET/... might need a Q counterpart, [...]
>> And that's another issue with preserving legacy compatability.
> As I stated before, I think a PSL mode bit to enable â??64-bit modeâ?? is pe$

Possibly.  I'm not sure whether I prefer that or to just have VAX32
hardware and VAX64 hardware, with neither running the other's machine
code.

There are multiple cases of what are basically 32- and 64-bit variants
on the same architecture: i386/amd64 and sparc/sparc64 are the ones I
know enough to comment on, but I can't imagine those are the only
cases - are there any where the 64-bit hardware lacks a mode that runs
the 32-bit's machine code?  I think sparc64 supports sparc32 machine
code only for userland, though I'm not certain whether that's a
hardware limitation or a NetBSD limitation.  The lack of any
instructions for running a full sparc32 OS on sparc64 hardware argues
it's the former.

>>> Kernel; the hardware structures (SCB, PCB, ...) must all be
>>> expanded.  Memory management changed (but the existing leave much
>>> to wish for anyway).  All this is probably a quite simple update to
>>> the architecture.
>> All true...but it leaves me asking how much you can change and still
>> preserve the elegance that makes a VAX feel like a VAX.
> I think you can preserve quite a lot.  Honestly, the standard â??VAX-32â?? V$

It is.  The only respect in which I think it's elegant is that it's
very simple.

Personally, I feel no need for executive or supervisor mode.

> As for the PCB, I would just do away with P{0,1}{B,L}R and replace them with$

I would do something else, certainly.  I'm not competent to comment on
the Alpha model, since I don't know enough about it.

As for memory, I don't know what you consider "reasonable".  But the
obvious practical answer is "for the same reason I run amd64 rather
than i386 even on hardware with <1G of RAM" and there's also the simple
"hack value" answer.

>> Possible thought: make addresses bit addresses, [...]
> I donâ??t really see the point in this, really.  Seems too clever by half, d$

Different?  Yes.  Weird?  Only in that it's different, I think; it
feels weird to me too, but on examining that feeling I think it's more
weird as in unusual than it is weird as in wrong.

I see no fundamental difference between a 64-bit value made up of 8
octets on an octet-addressed machine and an 8-bit value made up of 8
bits on a bit-addressed machine.

And it's another opportunity to experiment with alternatives to a
monoculture - in this case, the monoculture being octets as the
addressing unit.

>>> IEEE floating point:

>> Considered abstractly, I prefer IEEE floats to VAX floats; the IEEE
>> scheme fixes a number of issues with the VAX scheme.

>> But I also do not like monocultures, and IEEE floats are one.

> Well, it also means â??hey, more software works!â??.

At least to me, that does not, by itself, carry much weight.  I don't
see this being a workhorse production machine, one used where a
computer is just a tool and software - especially software that makes
nonportable assumptions about its floating point - Just Working is
worth compromising other things for.  I expect it to be used only by
people, and in situations, for which hack value is a major component of
the motivation.

Not that having software Just Work is an ignorable criterion in all
those situations.  But, to me, it does carry less weight.

>>> - AND.  Vax have BIC instead, but [...]
> [...].  I must admit it would be nice, though.
> Alpha kept BIC, but added AND and I think having AND would be pretty valuabl$

I think the major cost would be instruction-set space, not
implementation logic.

There are a few other instructions I'd like to see, too, but (a) it is
hardly appropriate to throw everybody's favourite currently-nonexistent
instruction into the pot and (b) if, as I expect, Ragge releases the
implementation source code, then people can, at least sort of, add such
experiments on their own.

/~\ The ASCII				  Mouse
\ / Ribbon Campaign
 X  Against HTML		mouse%rodents-montreal.org@localhost
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B