Path: news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: jgd@cix.co.uk (John Dallman)
Newsgroups: comp.arch
Subject: Re: Byte ordering
Date: Sun, 5 Jan 2025 14:48 +0000 (GMT Standard Time)
Organization: A noiseless patient Spider
Lines: 20
Message-ID: <memo.20250105144856.20984i@jgd.cix.co.uk>
References: <2025Jan3.093849@mips.complang.tuwien.ac.at>
Reply-To: jgd@cix.co.uk
Injection-Date: Sun, 05 Jan 2025 15:48:58 +0100 (CET)
Injection-Info: dont-email.me; posting-host="94833b45f21a59f19c8f02345f94ced3";
	logging-data="1144024"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/XkwhX0VAj3I/Kg7gwNly4NX7r2uYv96A="
Cancel-Lock: sha1:goxjB+0y/T5Wyn7ZfK1MW9lDyXg=
X-Clacks-Overhead-header: GNU Terry Pratchett

In article <2025Jan3.093849@mips.complang.tuwien.ac.at>,
anton@mips.complang.tuwien.ac.at (Anton Ertl) wrote:

> The 8086 has branches with 8-bit offsets and branches and calls 
> with 16-bit offsets. The 386 in 32-bit mode has branches with 
> 8-bit offsets and branches and calls with 32-bit offsets; if 
> 16-bit offsets for branches would be useful enough for performance,
> they could instead have designed the longer branch length to be 
> 16 bits, and maybe a prefix for 32-bit branch offsets.  That would 
> be faster than what you outline, as soon as one call happens.  
> But apparently 16-bit branches are not that beneficial, or they 
> would have gone that way on the 386.

Don't assume that Intel of the early 1980s would have done enough
simulation to explore those possibilities thoroughly. Given the mistakes
they made in the 1970s with iAPX 432 and in the 1990s with Itanium, both
through lack of simulation with varying workloads, they may well have
been working by rules of thumb and engineering "intuition."

John