Warning: mysqli::__construct(): (HY000/1203): User howardkn already has more than 'max_user_connections' active connections in D:\Inetpub\vhosts\howardknight.net\al.howardknight.net\includes\artfuncs.php on line 21
Failed to connect to MySQL: (1203) User howardkn already has more than 'max_user_connections' active connections
Warning: mysqli::query(): Couldn't fetch mysqli in D:\Inetpub\vhosts\howardknight.net\al.howardknight.net\index.php on line 66
Article <685ba7ef315af10861fde494ed489709@www.novabbs.org>
Deutsch   English   Français   Italiano  
<685ba7ef315af10861fde494ed489709@www.novabbs.org>

View for Bookmarking (what is this?)
Look up another Usenet article

Path: ...!news.misty.com!weretis.net!feeder9.news.weretis.net!i2pn.org!i2pn2.org!.POSTED!not-for-mail
From: mitchalsup@aol.com (MitchAlsup1)
Newsgroups: comp.arch
Subject: Re: is Vax adressing sane today
Date: Fri, 6 Sep 2024 18:31:05 +0000
Organization: Rocksolid Light
Message-ID: <685ba7ef315af10861fde494ed489709@www.novabbs.org>
References: <vbd6b9$g147$1@dont-email.me> <memo.20240905225550.19028d@jgd.cix.co.uk> <2024Sep6.080535@mips.complang.tuwien.ac.at>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Info: i2pn2.org;
	logging-data="1090872"; mail-complaints-to="usenet@i2pn2.org";
	posting-account="65wTazMNTleAJDh/pRqmKE7ADni/0wesT78+pyiDW8A";
User-Agent: Rocksolid Light
X-Spam-Checker-Version: SpamAssassin 4.0.0
X-Rslight-Site: $2y$10$AO3KX.6X/dETsnS9FSgtwuxCTiYXvRYOx5VxmcgrUhWeVj0oYtscm
X-Rslight-Posting-User: ac58ceb75ea22753186dae54d967fed894c3dce8
Bytes: 5367
Lines: 87

On Fri, 6 Sep 2024 6:05:35 +0000, Anton Ertl wrote:

> jgd@cix.co.uk (John Dallman) writes:
>>Memory-to-memory instructions, in general, are hard to get to run fast
>>with today's processors and memory, simply because memory access times
>>are long enough for many register-to-register instructions to execute.
>
> Given modern OoO technology, even VAX can fly.  It does not matter
> whether, say,
>
> *a++ = *b++ + *c++;
>
> is encoded as 1 VAX instruction, or as 4 ARM A64 instructions, or as 7
> RISC-V instructions, what goes on inside the OoO engine is pretty
> similar in all cases, and so is the performance.
>
> In recent years a number of implementations have 0-cycle store-to-load
> forwarding, so the misconception that a memory operand is as cheap as
> a register operand if only the instruction set has memory operands of
> operate instructions is a little bit closer to reality.  It is still a
> misconception, because such an implementation can read and write
> several times as many registers per cycle as memory operands.
>
>>A
>>lot of that time can be hidden with good caches and prefetchers, but if
>>your memory access patterns are complicated, those speedups can fail to
>>work.
>
> Whether operate instructions in an instruction set have 0, 1, or 3
> memory operands makes little difference in that case.
>
>>One reason for memory-to-memory instructions was to avoid the need to
>>dedicate registers to operands, but that's not much of a problem these
>>days, since we have space in the CPU for lots of registers and rename
>>systems for them.
>
> That may have been a consideration in the NOVA or the 6800, but in
> case of the VAX with its 16 registers, that corresponds to a
> load/store-architecture with 18 registers, so for the VAX this is just
> a minor issue.
>
> Some time ago I thought a bit about which kind of architecture to
> design with the transistor budget of the 6502, but with the RISC
> lessons under the belt.  One problem with a big RISC-like register set
> is the instruction bandwidth.  You really want to stick to 8-bit
> instructions if you only have an 8-bit data bus.  With a register
> architecture that means 2-bits for register operands, and that means
> you would need a lot of loads and stores in a load/store architecture.
> So the narrow instruction word almost forces you to use implicit
> register operands or at small special-purpose register sets (e.g., 2
> accumulators and 4 index registers, as in the 6809) rather than
> general-purpose registers.
>
> However, the VAX 11/780 does not have these restrictions.  It has a
> wider memory bus and it has a cache.
>
>>DEC spent a lot of time and money trying to keep VAX competitive and took
>>too long to accept that was impractical. That was one of the seeds of
>>their downfall.
>
> Either that, or they failed to stick to VAX for the few more years
> until they would have developed an OoO implementation, which would
> have leveled the playing field again (see Pentium Pro).  The Alpha
> came out in 1992, the Pentium Pro in 1995, so if DEC has stuck to the
> VAX and managed a timely OoO implementation, they would have needed to
> survive just 3 years.  And it seems that they lost a lot of customers
> in the transition from VAX to Alpha.
>
> Of course, the question is if the customers would have stayed with DEC
> if they had continued with the VAX.  The vibe at the time was that
> CISCs are doomed.  OTOH, Intel stuck with IA-32 and won with the P6,
> and IBM stuck with the S390.  But VAX customers are not S390
> customers, and maybe they would have defected to Intel even if the VAX
> had been there.

In my opinion, DEC was caught at an ugly time for them. They did not
have the transistor budget for a GBOoO implementation at exactly the
time they also needed a clean transition to 64-bits (even more trans-
istors). DEC did have the transistors for a medium OoO implementation
but unlikely the 64-bit transition.

> From what I read, the VAX 9000 was a big nail in the DEC coffin.  In
> hindsight they should have canceled the project early, but that does
> not mean that they could not have continued with VAX (they could even
> have competed with the IBM mainframes, which took quite long to gain
> superscalar and OoO implementations).
>
> - anton