Path: ...!weretis.net!feeder9.news.weretis.net!i2pn.org!i2pn2.org!.POSTED!not-for-mail
From: mitchalsup@aol.com (MitchAlsup1)
Newsgroups: comp.arch
Subject: Re: architectural goals, Byte Addressability And Beyond
Date: Wed, 5 Jun 2024 17:00:09 +0000
Organization: Rocksolid Light
Message-ID: <b32e1eae3727b59852faf25d4350ccf3@www.novabbs.org>
References: <20240603130821.000076b3@yahoo.com> <memo.20240605094016.3656K@jgd.cix.co.uk> <2024Jun5.123225@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="3286391"; mail-complaints-to="usenet@i2pn2.org";
	posting-account="65wTazMNTleAJDh/pRqmKE7ADni/0wesT78+pyiDW8A";
User-Agent: Rocksolid Light
X-Rslight-Site: $2y$10$93uGO7urXPYbpIPLwi0sV.8ujKa4989ih9muI0Pg8MBFAYo70Tb/q
X-Rslight-Posting-User: ac58ceb75ea22753186dae54d967fed894c3dce8
X-Spam-Checker-Version: SpamAssassin 4.0.0
Bytes: 2476
Lines: 36

Anton Ertl wrote:

> jgd@cix.co.uk (John Dallman) writes:
>>I would like to keep testing the commercial product I work on in a
>>big-endian, alignment-trapping environment.

> Computer architecture exhibits convergence.  Starting in the 1960s it
> converged on byte addressing with 8-bit bytes and on 2s-complement,
> starting in the 1980s it converged on IEEE FP, and ending in the 2010s

Although we did not converge on doing denorms properly until the mid
2000s.

GPUs followed a more meandering path:: starting out with crappy but
fast
FP, then adopting IEEE containers, then over several generations
adopting
more and more of IEEE 754 semantics.

Then there are the SW (and a few HW) holdouts that still believe that
denorms are hard/slow and we need mechanisms to flush them from the
numerics. No, we don't, we need circuitry where denorms are not slower 
than norms without having slowed down the norms.

> it converged on supporting unaligned accesses and on little-endian
> byte order.  Your difficulties in getting hardware for testing whether
> software can work with alignment restrictions and with big-endian byte
> order is a result of that convergence.  Maybe your desire to keep your
> software ready for big-endian hardware and hardware with alignment
> restrictions is misguided.

>>New SPARC boxes are expensive, dealing with Oracle is hard work, and the
>>architecture has no future. 

> Ebay?

> - anton