The Intel 8086 supported unaligned loads and stores of 16-bit data, e.g. mov ax, foo was guaranteed to work even if foo was odd.

What did this cost, in terms of performance and chip area, compared to an alternative architecture that would have been the same except for unaligned access being a trap or undefined behavior?

To be clear, I'm not talking about the dynamic behavior of code. On the actual 8086, access was still faster if the pointer did happen to be even. I'm asking, suppose all your pointers for word access were actually even, how much bigger and slower was the chip made by having to support the possibility that some of them could have been odd?

My first thought is that obviously a load/store circuit that doesn't need to take into account the possibility of unaligned access (and be ready to do the complicated fallback routine of two accesses and splicing the parts together) must clearly be simpler, therefore smaller and faster, then one does need to take into account this possibility.

On the other hand, the instruction decoder needs to support unaligned access anyway.

On the third hand, that might not be relevant here; the instruction decoder is probably a completely separate circuit that doesn't share parts with the data load/store circuitry.

Which points back to the conclusion that the chip could have been smaller and faster if it didn't support unaligned access.

Then again, maybe the test for the fallback case, wasn't a bottleneck in cycle time? In that case, maybe it only cost chip area?

Or maybe it was an extra microcode stage? In that case, every aligned access would have been at least one full clock cycle slower, just to support the possibility of unaligned access?

According to Russell Wallace <russell.wallace@gmail.com>:
>The Intel 8086 supported unaligned loads and stores of 16-bit data, e.g. mov ax, foo was guaranteed to work even if foo was odd.
>
>What did this cost, in terms of performance and chip area, compared to an alternative architecture that would have been the same except for unaligned
>access being a trap or undefined behavior?

The 8086 was generally constrained by memory speed, so it cost little if anything.

A few years later the 486 and RISC-ish i860 were implemented with
similar technology and the 860 was a lot faster, maybe a factor of
two. But I think that was because it was easier to decode the instructions
and pipeline them, not anything about aligned memory and some odd hacks to
help pipeline repetitive floating point operations.

The original S/360 required everything to be aligned, while S/370
allowed all data to be misaligned. IBM did a great deal of simulation
before making architecture choices so I assume they had good reason to
believe it would be an improvement.

--
Regards,
John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

On Wednesday, July 5, 2023 at 3:14:05 PM UTC-5, Russell Wallace wrote:
> The Intel 8086 supported unaligned loads and stores of 16-bit data, e.g. mov ax, foo was guaranteed to work even if foo was odd.
>
> What did this cost, in terms of performance and chip area, compared to an alternative architecture that would have been the same except for unaligned access being a trap or undefined behavior?
>
> To be clear, I'm not talking about the dynamic behavior of code. On the actual 8086, access was still faster if the pointer did happen to be even. I'm asking, suppose all your pointers for word access were actually even, how much bigger and slower was the chip made by having to support the possibility that some of them could have been odd?
>
> My first thought is that obviously a load/store circuit that doesn't need to take into account the possibility of unaligned access (and be ready to do the complicated fallback routine of two accesses and splicing the parts together) must clearly be simpler, therefore smaller and faster, then one does need to take into account this possibility.
>
> On the other hand, the instruction decoder needs to support unaligned access anyway.
>
> On the third hand, that might not be relevant here; the instruction decoder is probably a completely separate circuit that doesn't share parts with the data load/store circuitry.
<
Decoder was byte by byte.
>
> Which points back to the conclusion that the chip could have been smaller and faster if it didn't support unaligned access.
<
It would have been significantly small without segmentation but with misaligned support, too.
<
Since it was basically running at bus performance, faster remains in question.
>
> Then again, maybe the test for the fallback case, wasn't a bottleneck in cycle time? In that case, maybe it only cost chip area?
>
> Or maybe it was an extra microcode stage? In that case, every aligned access would have been at least one full clock cycle slower, just to support the possibility of unaligned access?
<
Probably something close to 5-gates (recognize the misalignment), 2-words of microcode
(special sequence, few bits set), and one 8-bit registers (data feed around..) And maybe one
16-bit 2:1 multiplexer (byte-swap).
<
OR less than one segmentation register !!
<
8086 had ~30,000 transistors, in 3µNMOS I could build the above in ~145 transistors.
Today in gate only design it would take ~450 transistors.
or about ½%.

On Wednesday, July 5, 2023 at 3:53:12 PM UTC-5, John Levine wrote:
> According to Russell Wallace <russell...@gmail.com>:
> >The Intel 8086 supported unaligned loads and stores of 16-bit data, e.g. mov ax, foo was guaranteed to work even if foo was odd.
> >
> >What did this cost, in terms of performance and chip area, compared to an alternative architecture that would have been the same except for unaligned
> >access being a trap or undefined behavior?
> The 8086 was generally constrained by memory speed, so it cost little if anything.
>
> A few years later the 486 and RISC-ish i860 were implemented with
> similar technology and the 860 was a lot faster, maybe a factor of
> two. But I think that was because it was easier to decode the instructions
> and pipeline them, not anything about aligned memory and some odd hacks to
> help pipeline repetitive floating point operations.
>
> The original S/360 required everything to be aligned, while S/370
> allowed all data to be misaligned. IBM did a great deal of simulation
> before making architecture choices so I assume they had good reason to
> believe it would be an improvement.
<
FORTRAN common blocks required misaligned DP FP accesses.
>
> --
> Regards,
> John Levine, jo...@taugh.com, Primary Perpetrator of "The Internet for Dummies",
> Please consider the environment before reading this e-mail. https://jl.ly

John Levine <johnl@taugh.com> schrieb:
> According to Russell Wallace <russell.wallace@gmail.com>:
>>The Intel 8086 supported unaligned loads and stores of 16-bit data, e.g. mov ax, foo was guaranteed to work even if foo was odd.
>>
>>What did this cost, in terms of performance and chip area, compared to an alternative architecture that would have been the same except for unaligned
>>access being a trap or undefined behavior?
>
> The 8086 was generally constrained by memory speed, so it cost little if anything.
>
> A few years later the 486 and RISC-ish i860 were implemented with
> similar technology and the 860 was a lot faster, maybe a factor of
> two. But I think that was because it was easier to decode the instructions
> and pipeline them, not anything about aligned memory and some odd hacks to
> help pipeline repetitive floating point operations.
>
> The original S/360 required everything to be aligned, while S/370
> allowed all data to be misaligned. IBM did a great deal of simulation
> before making architecture choices so I assume they had good reason to
> believe it would be an improvement.

And then the 801 people came along and found out that compilers rarely,
if ever, issued misaligned loads and stores, and the RISC people turned
back the clock to aligned. High-end RISC systems generally support it
by now (even POWER), low-end microcontrollers may not, and RISC-V is
RISC-V because it may be even be trap/emulate there.

On Wednesday, July 5, 2023 at 4:03:26 PM UTC-5, Thomas Koenig wrote:
> John Levine <jo...@taugh.com> schrieb:
> > According to Russell Wallace <russell...@gmail.com>:
> >>The Intel 8086 supported unaligned loads and stores of 16-bit data, e.g.. mov ax, foo was guaranteed to work even if foo was odd.
> >>
> >>What did this cost, in terms of performance and chip area, compared to an alternative architecture that would have been the same except for unaligned
> >>access being a trap or undefined behavior?
> >
> > The 8086 was generally constrained by memory speed, so it cost little if anything.
> >
> > A few years later the 486 and RISC-ish i860 were implemented with
> > similar technology and the 860 was a lot faster, maybe a factor of
> > two. But I think that was because it was easier to decode the instructions
> > and pipeline them, not anything about aligned memory and some odd hacks to
> > help pipeline repetitive floating point operations.
> >
> > The original S/360 required everything to be aligned, while S/370
> > allowed all data to be misaligned. IBM did a great deal of simulation
> > before making architecture choices so I assume they had good reason to
> > believe it would be an improvement.
> And then the 801 people came along and found out that compilers rarely,
> if ever, issued misaligned loads and stores, and the RISC people turned
> back the clock to aligned. High-end RISC systems generally support it
> by now (even POWER), low-end microcontrollers may not, and RISC-V is
> RISC-V because it may be even be trap/emulate there.
<
How much consternation in SW is worth ½% chip area ???

On Thursday, July 6, 2023 at 12:03:26 AM UTC+3, Thomas Koenig wrote:
> John Levine <jo...@taugh.com> schrieb:
> > According to Russell Wallace <russell...@gmail.com>:
> >>The Intel 8086 supported unaligned loads and stores of 16-bit data, e.g.. mov ax, foo was guaranteed to work even if foo was odd.
> >>
> >>What did this cost, in terms of performance and chip area, compared to an alternative architecture that would have been the same except for unaligned
> >>access being a trap or undefined behavior?
> >
> > The 8086 was generally constrained by memory speed, so it cost little if anything.
> >
> > A few years later the 486 and RISC-ish i860 were implemented with
> > similar technology and the 860 was a lot faster, maybe a factor of
> > two. But I think that was because it was easier to decode the instructions
> > and pipeline them, not anything about aligned memory and some odd hacks to
> > help pipeline repetitive floating point operations.
> >
> > The original S/360 required everything to be aligned, while S/370
> > allowed all data to be misaligned. IBM did a great deal of simulation
> > before making architecture choices so I assume they had good reason to
> > believe it would be an improvement.
> And then the 801 people came along and found out that compilers rarely,
> if ever, issued misaligned loads and stores, and the RISC people turned
> back the clock to aligned. High-end RISC systems generally support it
> by now (even POWER), low-end microcontrollers may not,

World leading 32-bit microcontroller architecture, i.e. Arm Cortex-M, supports
unaligned accesses.

> and RISC-V is
> RISC-V because it may be even be trap/emulate there.

According to MitchAlsup <MitchAlsup@aol.com>:
>> The original S/360 required everything to be aligned, while S/370
>> allowed all data to be misaligned. IBM did a great deal of simulation
>> before making architecture choices so I assume they had good reason to
>> believe it would be an improvement.
><
>FORTRAN common blocks required misaligned DP FP accesses.

To some extent. You could indeed use COMMON and EQUIVALENCE statements
to misalign data. The Fortran library normally caught the misaligned
data exception and simulated the failed instruction. We all knew how
slow that was so if we cared how fast our programs ran, which we usually
did, we made sure to align correctly, which was not hard.

Then the 360/91 came along, with imprecise interrupts so the fixups
didn't work. Oops. By 1968 the 360/195 had the Byte Oriented Operand
feature that handled misaligned data in hardware.

The motivation wasn't performance, it was that there were programs
that worked on slower machines and failed on the /91. That was pretty
embarassing, to be sure, not the only embarassing thing about the /91.

--
Regards,
John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

On Wednesday, July 5, 2023 at 11:53:12 PM UTC+3, John Levine wrote:
>
> and the 860 was a lot faster, maybe a factor of two.

I heard very varying accounts about it, including claims that on majority
of real-world codes i860 was much slower than both i486 and and all
but the lowest end members of i960 family.
In practice, i860 was quickly relegated to role of floating-point DSP, so
very few people had 1st-hand experience of using it for anything general-
purpose.

According to Michael S <already5chosen@yahoo.com>:
>On Wednesday, July 5, 2023 at 11:53:12 PM UTC+3, John Levine wrote:
>>
>> and the 860 was a lot faster, maybe a factor of two.
>
>I heard very varying accounts about it, including claims that on majority
>of real-world codes i860 was much slower than both i486 and and all
>but the lowest end members of i960 family.
>In practice, i860 was quickly relegated to role of floating-point DSP, so
>very few people had 1st-hand experience of using it for anything general-
>purpose.

I can believe it. Apparently the 860 was originally intended as an
embedded chip, changed at the last minute to a general purpose RISC,
while the 960 went the other way. System programming on the 860 was a
nightmare, keeping process status and context switching and stuff
nearly impossible.

Also, it was hard to generate good code for the 860 viz. that floating
point pipeline thing, so it makes sense to use it for hand optimized
DSP codes.

--
Regards,
John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

On 7/5/2023 4:22 PM, Michael S wrote:
> On Thursday, July 6, 2023 at 12:03:26 AM UTC+3, Thomas Koenig wrote:
>> John Levine <jo...@taugh.com> schrieb:
>>> According to Russell Wallace <russell...@gmail.com>:
>>>> The Intel 8086 supported unaligned loads and stores of 16-bit data, e.g. mov ax, foo was guaranteed to work even if foo was odd.
>>>>
>>>> What did this cost, in terms of performance and chip area, compared to an alternative architecture that would have been the same except for unaligned
>>>> access being a trap or undefined behavior?
>>>
>>> The 8086 was generally constrained by memory speed, so it cost little if anything.
>>>
>>> A few years later the 486 and RISC-ish i860 were implemented with
>>> similar technology and the 860 was a lot faster, maybe a factor of
>>> two. But I think that was because it was easier to decode the instructions
>>> and pipeline them, not anything about aligned memory and some odd hacks to
>>> help pipeline repetitive floating point operations.
>>>
>>> The original S/360 required everything to be aligned, while S/370
>>> allowed all data to be misaligned. IBM did a great deal of simulation
>>> before making architecture choices so I assume they had good reason to
>>> believe it would be an improvement.
>> And then the 801 people came along and found out that compilers rarely,
>> if ever, issued misaligned loads and stores, and the RISC people turned
>> back the clock to aligned. High-end RISC systems generally support it
>> by now (even POWER), low-end microcontrollers may not,
>
> World leading 32-bit microcontroller architecture, i.e. Arm Cortex-M, supports
> unaligned accesses.
>

Yeah.

Apart from "smallest core possible", allowing for unaligned access makes
sense.

But, if one is going to skip support for misaligned access, it may also
makes sense to skip having things like shift and multiply. Since, after
all, one can fake these in software without "too much" cost if they do
actually need the smallest core possible.

But, by the time a core is big enough to support things like a floating
point unit or virtual memory, as I see it, lacking things like
misaligned access (or indexed load/store for that matter) is kind of a
design fail IMO.

That said, misaligned access is still uncommon for normal code, and the
main "selling point" for misaligned access is mostly that it simplifies
things like making "memcpy()" moderately fast (and other related tasks,
like LZ77 decompression, ...).

>> and RISC-V is
>> RISC-V because it may be even be trap/emulate there.

Trap emulation is a possible tradeoff.

Main drawback is that it is basically the slowest option possible
(within reason).

As I see it though, RISC-V is a little unbalanced though, as it adds
many expensive/advanced features without addressing some code
deficiencies that are likely to have a detrimental effect on performance
(and in some cases seems to sway more towards ideology than to
optimizing for the cost/benefit tradeoffs).

Then again, I guess it is possible that someone could disagree with me
in terms of where the cost/benefit tradeoffs lead to.

Thomas Koenig wrote:
> John Levine <johnl@taugh.com> schrieb:
>> According to Russell Wallace <russell.wallace@gmail.com>:
>>> The Intel 8086 supported unaligned loads and stores of 16-bit data, e.g. mov ax, foo was guaranteed to work even if foo was odd.
>>>
>>> What did this cost, in terms of performance and chip area, compared to an alternative architecture that would have been the same except for unaligned
>>> access being a trap or undefined behavior?
>> The 8086 was generally constrained by memory speed, so it cost little if anything.
>>
>> A few years later the 486 and RISC-ish i860 were implemented with
>> similar technology and the 860 was a lot faster, maybe a factor of
>> two. But I think that was because it was easier to decode the instructions
>> and pipeline them, not anything about aligned memory and some odd hacks to
>> help pipeline repetitive floating point operations.
>>
>> The original S/360 required everything to be aligned, while S/370
>> allowed all data to be misaligned. IBM did a great deal of simulation
>> before making architecture choices so I assume they had good reason to
>> believe it would be an improvement.
>
> And then the 801 people came along and found out that compilers rarely,
> if ever, issued misaligned loads and stores, and the RISC people turned
> back the clock to aligned. High-end RISC systems generally support it
> by now (even POWER), low-end microcontrollers may not, and RISC-V is
> RISC-V because it may be even be trap/emulate there.

And then the Standford MIPS came along, believed this, eliminated unaligned
loads and stores, and found out that while compilers may not issue these
humans do it *a lot*. Faced with the prospect of rewriting lots of code
to suit their processor they chose to add it back in for their first
commercial version, the MIPS R2000.

And then the Alpha 21064 came along, believed this, eliminated unaligned
loads and stores, and found out humans do this *a lot*.
Then DEC lied it caused problems, blamed the humans, claimed the code was
broken to begin with (it wasn't), quietly published manuals on how to
rewrite code to suit their processor, and finally added it back in again
claiming it was to support Windows. By which time they had, in my opinion,
driven away Alpha's market due to incompatibility and it never recovered.

On Wednesday, July 5, 2023 at 2:58:36 PM UTC-6, MitchAlsup wrote:
> On Wednesday, July 5, 2023 at 3:53:12 PM UTC-5, John Levine wrote:

> > The original S/360 required everything to be aligned, while S/370
> > allowed all data to be misaligned. IBM did a great deal of simulation
> > before making architecture choices so I assume they had good reason to
> > believe it would be an improvement.
> <
> FORTRAN common blocks required misaligned DP FP accesses.

In that case, how did IBM offer a FORTRAN compiler for the IBM System/360?

I suppose they _could_ have allowed unaligned floats, and used MVC instructions
in the code generated to access them, but I'm sure they just gave an error message
if you tried to put a double-precision float in an unaligned location.

And if that made their FORTRAN IV compiler noncompliant with something, nobody
minded.

John Savard

On Wednesday, July 5, 2023 at 2:14:05 PM UTC-6, Russell Wallace wrote:

> What did this cost, in terms of performance and chip area, compared
> to an alternative architecture that would have been the same except
> for unaligned access being a trap or undefined behavior?

What does support for unaligned operations require?

Basically, what has to happen is:

Every time there's a memory access, there has to be a
check for an unaligned access.

If there is an unaligned access, the sequence of events is now
changed: the memory access is broken up into a larger number of
memory accesses, and, in the case of a load, the operand is then
shifted and assembled; in the case of a store, it's broken up and
the parts are shifted before the actual memory access.

John Savard

On Wednesday, July 5, 2023 at 5:48:17 PM UTC-6, EricP wrote:

> And then the Standford MIPS came along,
> And then the Alpha 21064 came along,

Oh, dear. What a pity. While support for unaligned
memory access is a convenience, I would have thought
of it as a frill, that can, and should, be dispensed with on
an architecture designed, say, for ultimate performance
in high-performance computing.

But if, in the real world, you are actually going to have to
occasionally trap and emulate unaligned accesses, then
unless "occasionally" is _very_ rare indeed, hardware support
will be preferred.

Since the original System/360 got along reasonably well,
and people wrote a version of SNOBOL for it, and a version
of LISP for it, and so on... I had always assumed that
unaligned access is not really needed; it's just a frill. But
the history you're giving certainly suggests that for _some_
reason, the world of computers today _is_ basically
dependent on having this feature.

John Savard

EricP <ThatWouldBeTelling@thevillage.com> writes:
>Thomas Koenig wrote:
>> John Levine <johnl@taugh.com> schrieb:
>>> The original S/360 required everything to be aligned, while S/370
>>> allowed all data to be misaligned. IBM did a great deal of simulation
>>> before making architecture choices so I assume they had good reason to
>>> believe it would be an improvement.
>>
>> And then the 801 people came along and found out that compilers rarely,
>> if ever, issued misaligned loads and stores, and the RISC people turned
>> back the clock to aligned. High-end RISC systems generally support it
>> by now (even POWER), low-end microcontrollers may not, and RISC-V is
>> RISC-V because it may be even be trap/emulate there.
>
>And then the Standford MIPS came along, believed this, eliminated unaligned
>loads and stores, and found out that while compilers may not issue these
>humans do it *a lot*. Faced with the prospect of rewriting lots of code
>to suit their processor they chose to add it back in for their first
>commercial version, the MIPS R2000.

It's a long time since I used an R2000 based machine (and slightly
less since I last used an R3000 or R4000-based machine), but I am
pretty sure that the usual loads and stores require natural alignment
and trap on misaligned accesses. They also have lwl, lwr, swl and swr
for synthesizing unaligned accesses; and pseudo-instructions ulw, usw,
ulh, ulhu, ush that expand to sequences of machine instructions.
Raymond Chen describes this in
<https://devblogs.microsoft.com/oldnewthing/20180409-00/?p=98465>.

>And then the Alpha 21064 came along, believed this, eliminated unaligned
>loads and stores, and found out humans do this *a lot*.
>Then DEC lied it caused problems, blamed the humans, claimed the code was
>broken to begin with (it wasn't),

I don't remember this for the Alpha, but it's a common pattern.

>quietly published manuals on how to
>rewrite code to suit their processor, and finally added it back in again
>claiming it was to support Windows.

It's also been a while since I used an Alpha, but even on the 21264B
we saw notices of unaligned accesses by programs in the Linux kernel
logs, and I wrote <https://www.complang.tuwien.ac.at/anton/uace.c> to
control this Linux kernel feature (a similar program uac was available
on Digital OSF/1 (or whatever it had been renamed to at the time), and
as a result I (and my students) got SIGBUS signals on unaligned
accesses even on Linux (where normally the kernel emulated unaligned
accesses).

Alpha also has ldq_u (which performed an aligned access using a
possibly unaligned address), and pseudo-instructions like ustq (which
expands to 11 instructions IIRC). I actually found that the gas
implementation of ustq was broken, which showed that no Linux software
used this pseudo-instruction.

You may be confusing the unaligned access issue with byte and 16-bit
memory access, which was added in EV56.

Trapping on unaligned accesses was very common at the time: the 68000
and 68010 do it (but the 68020 and onwards support unaligned
accesses), and all the first-generation RISCs also trap on unaligned
accesses: ARM, HPPA, MIPS, SPARC, 88k. In the second generation
(Power and Alpha) only Power in big-endian mode supports unaligned
accesses.

Even Intel jumped on the alignment-requiring bandwagon: they added the
AC flag in the 486 (1989) and alignment-requiring memory accesses with
SSE (1999); of course, they did both in an idiotic way:

1) Setting AC requires 8-byte alignment for 8-byte FP numbers, but the
Intel-designed ABI requires 8-byte FP numbers to be stored with 4-byte
alignment, which means that you could not set AC except in very
confined circumstances.

2) Aligned SSE memory accesses require 16-byte alignments, while the
elements were smaller; this means that you either use the unaligned
load and store instructions, or your vectorized code has to
special-case the first and last elements to achieve alignment. AMD
added a flag for dropping the alignment requirement for implicit SSE
memory accesses. Intel did not follow AMD in that, but dropped the
alignment requirement in AVX; this would have been ok if AVX had been
universally available, but unfortunately AVX was not implemented in
Intel's cheap cores up to Gracemont, and often disabled on lower-end
SKUs of their expensive cores.

Back to earlier times: Many RISCs died over the years, with IA-64's
prospect bing particularly deadly: HPPA, MIPS (as GP-computer
architecture), and Alpha were cancelled and intended to be replaced
with IA-64.

IA-64 also did not guarantee that unaligned accesses work. More
precisely,
<https://www.ece.lsu.edu/ee4720/doc/itanium-arch-2.1-v2.pdf> says on
page 2:78:

|When PSR.ac is 1, any Itanium data memory reference that is not
|aligned on a boundary the size of the operand results in an Unaligned
|Data Reference fault; e.g., 1, 2, 4, 8, 10, and 16-byte datums should
|be aligned on 1, 2, 4, 8, 16, and 16-byte boundaries respectively to
|avoid generation of an Unaligned Data Reference fault.
|...
|When PSR.ac is 0, Itanium data memory references that are not aligned
|may or may not result in an Unaligned Data Reference fault based on
|the implementation. The level of unaligned memory support is
|implementation specific. However, all implementations will raise an
|Unaligned Data Reference fault if the datum referenced by an Itanium
|instruction spans a 4K aligned boundary, and many implementations will
|raise an Unaligned Data Reference fault if the datum spans a cache
|line. Implementations may also raise an Unaligned Data Reference
|fault for any other unaligned Itanium memory reference.

The wider support for unaligned accesses came only later: ARM added
support for unaligned accesses, Power had it already for big-endian
(and later added it for little-endian, along with a new form of
little-endian support), IA-64 and SPARC died out, and ARM A64 and
RISC-V support unaligned accesses, leaving only architectures with
unaligned-access support for general-purpose computers.

I guess that the RISC-V decision shows that by that time (early 2010s,
does anybody know a more exact date?) unaligned access support had
won.

It's interesting to speculate why we have had alignment requirements
for so long in RISCs (from the 1980s to the 2000s), and eventually
unaligned won. It seems that the forces involved were relatively
small:

The number of unaligned-access reports in the Linux kernel log on
Alpha were relatively small, so software emulation is a minor cost.

Another cost of alignment requirements is the problem of using the
instructions in a SIMD context (even non-SIMD instructions, e.g.,
performing a hash of a string by loading 8-byte pieces and mixing them
with the hash value up to now). One can use stuff like Alpha's uldq
for such uses and memcpy() to make the compiler generate it in
somewhat recent C compilers, but I guess that doing stuff like *p
(which generates an alignment-requiring ldq on the Alpha) was frequent
enough in the early 2000s (when Linux on IA-32/AMD64 had become the
dominant Unix) that architectures finally added support for unaligned
accesses.

The hardware cost of supporting unaligned accesses is not that large,
as Mitch Alsup explained elsewhere in this thread, and that cost got
relatively smaller as transistor density increased.

I guess that the software environment of the years between 2000 and
2010 and the lowering hardware costs of unaligned-access support
eventually tipped the balance in favour of unaligned accesses. It's
interesting that the same had earlier happened on S/360->S/370 and
68010->68020.

Concerning the original question: One may also ask what the support
for unaligned accesses bought the 8086: The 8086 was designed to be
8080-compatible at the assembly level (from what I read, this feature
helped create an initial software base, even though it was not really
used in later years), and this meant that unaligned accesses would
need to be supported, too. If they had skimped on unaligned accesses,
maybe the 8086 would have been much less successful than they were;
but it was actually the 8088 that was successful, and unaligned
accesses were for free on that, so it would not have changed much if
the 8086 required alignment (if that requirement was not inherited to
the 8088).

- anton
--
'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
Mitch Alsup, <c17fcd89-f024-40e7-a594-88a85ac10d20o@googlegroups.com>

On Thursday, July 6, 2023 at 4:18:08 AM UTC-4, Anton Ertl wrote:
> EricP <ThatWould...@thevillage.com> writes:
> >Thomas Koenig wrote:
> >> John Levine <jo...@taugh.com> schrieb:
> >>> The original S/360 required everything to be aligned, while S/370
> >>> allowed all data to be misaligned. IBM did a great deal of simulation
> >>> before making architecture choices so I assume they had good reason to
> >>> believe it would be an improvement.
> >>
> >> And then the 801 people came along and found out that compilers rarely,
> >> if ever, issued misaligned loads and stores, and the RISC people turned
> >> back the clock to aligned. High-end RISC systems generally support it
> >> by now (even POWER), low-end microcontrollers may not, and RISC-V is
> >> RISC-V because it may be even be trap/emulate there.
> >
> >And then the Standford MIPS came along, believed this, eliminated unaligned
> >loads and stores, and found out that while compilers may not issue these
> >humans do it *a lot*. Faced with the prospect of rewriting lots of code
> >to suit their processor they chose to add it back in for their first
> >commercial version, the MIPS R2000.
> It's a long time since I used an R2000 based machine (and slightly
> less since I last used an R3000 or R4000-based machine), but I am
> pretty sure that the usual loads and stores require natural alignment
> and trap on misaligned accesses. They also have lwl, lwr, swl and swr
> for synthesizing unaligned accesses; and pseudo-instructions ulw, usw,
> ulh, ulhu, ush that expand to sequences of machine instructions.
> Raymond Chen describes this in
> <https://devblogs.microsoft.com/oldnewthing/20180409-00/?p=98465>.
> >And then the Alpha 21064 came along, believed this, eliminated unaligned
> >loads and stores, and found out humans do this *a lot*.
> >Then DEC lied it caused problems, blamed the humans, claimed the code was
> >broken to begin with (it wasn't),
> I don't remember this for the Alpha, but it's a common pattern.
> >quietly published manuals on how to
> >rewrite code to suit their processor, and finally added it back in again
> >claiming it was to support Windows.
> It's also been a while since I used an Alpha, but even on the 21264B
> we saw notices of unaligned accesses by programs in the Linux kernel
> logs, and I wrote <https://www.complang.tuwien.ac.at/anton/uace.c> to
> control this Linux kernel feature (a similar program uac was available
> on Digital OSF/1 (or whatever it had been renamed to at the time), and
> as a result I (and my students) got SIGBUS signals on unaligned
> accesses even on Linux (where normally the kernel emulated unaligned
> accesses).
>
> Alpha also has ldq_u (which performed an aligned access using a
> possibly unaligned address), and pseudo-instructions like ustq (which
> expands to 11 instructions IIRC). I actually found that the gas
> implementation of ustq was broken, which showed that no Linux software
> used this pseudo-instruction.
>
> You may be confusing the unaligned access issue with byte and 16-bit
> memory access, which was added in EV56.
>
> Trapping on unaligned accesses was very common at the time: the 68000
> and 68010 do it (but the 68020 and onwards support unaligned
> accesses), and all the first-generation RISCs also trap on unaligned
> accesses: ARM, HPPA, MIPS, SPARC, 88k. In the second generation
> (Power and Alpha) only Power in big-endian mode supports unaligned
> accesses.
>
> Even Intel jumped on the alignment-requiring bandwagon: they added the
> AC flag in the 486 (1989) and alignment-requiring memory accesses with
> SSE (1999); of course, they did both in an idiotic way:
>
> 1) Setting AC requires 8-byte alignment for 8-byte FP numbers, but the
> Intel-designed ABI requires 8-byte FP numbers to be stored with 4-byte
> alignment, which means that you could not set AC except in very
> confined circumstances.
>
> 2) Aligned SSE memory accesses require 16-byte alignments, while the
> elements were smaller; this means that you either use the unaligned
> load and store instructions, or your vectorized code has to
> special-case the first and last elements to achieve alignment. AMD
> added a flag for dropping the alignment requirement for implicit SSE
> memory accesses. Intel did not follow AMD in that, but dropped the
> alignment requirement in AVX; this would have been ok if AVX had been
> universally available, but unfortunately AVX was not implemented in
> Intel's cheap cores up to Gracemont, and often disabled on lower-end
> SKUs of their expensive cores.
>
> Back to earlier times: Many RISCs died over the years, with IA-64's
> prospect bing particularly deadly: HPPA, MIPS (as GP-computer
> architecture), and Alpha were cancelled and intended to be replaced
> with IA-64.
>
> IA-64 also did not guarantee that unaligned accesses work. More
> precisely,
> <https://www.ece.lsu.edu/ee4720/doc/itanium-arch-2.1-v2.pdf> says on
> page 2:78:
>
> |When PSR.ac is 1, any Itanium data memory reference that is not
> |aligned on a boundary the size of the operand results in an Unaligned
> |Data Reference fault; e.g., 1, 2, 4, 8, 10, and 16-byte datums should
> |be aligned on 1, 2, 4, 8, 16, and 16-byte boundaries respectively to
> |avoid generation of an Unaligned Data Reference fault.
> |...
> |When PSR.ac is 0, Itanium data memory references that are not aligned
> |may or may not result in an Unaligned Data Reference fault based on
> |the implementation. The level of unaligned memory support is
> |implementation specific. However, all implementations will raise an
> |Unaligned Data Reference fault if the datum referenced by an Itanium
> |instruction spans a 4K aligned boundary, and many implementations will
> |raise an Unaligned Data Reference fault if the datum spans a cache
> |line. Implementations may also raise an Unaligned Data Reference
> |fault for any other unaligned Itanium memory reference.
>
> The wider support for unaligned accesses came only later: ARM added
> support for unaligned accesses, Power had it already for big-endian
> (and later added it for little-endian, along with a new form of
> little-endian support), IA-64 and SPARC died out, and ARM A64 and
> RISC-V support unaligned accesses, leaving only architectures with
> unaligned-access support for general-purpose computers.
>
> I guess that the RISC-V decision shows that by that time (early 2010s,
> does anybody know a more exact date?) unaligned access support had
> won.
>
> It's interesting to speculate why we have had alignment requirements
> for so long in RISCs (from the 1980s to the 2000s), and eventually
> unaligned won. It seems that the forces involved were relatively
> small:
>
> The number of unaligned-access reports in the Linux kernel log on
> Alpha were relatively small, so software emulation is a minor cost.
>
> Another cost of alignment requirements is the problem of using the
> instructions in a SIMD context (even non-SIMD instructions, e.g.,
> performing a hash of a string by loading 8-byte pieces and mixing them
> with the hash value up to now). One can use stuff like Alpha's uldq
> for such uses and memcpy() to make the compiler generate it in
> somewhat recent C compilers, but I guess that doing stuff like *p
> (which generates an alignment-requiring ldq on the Alpha) was frequent
> enough in the early 2000s (when Linux on IA-32/AMD64 had become the
> dominant Unix) that architectures finally added support for unaligned
> accesses.
>
> The hardware cost of supporting unaligned accesses is not that large,
> as Mitch Alsup explained elsewhere in this thread, and that cost got
> relatively smaller as transistor density increased.
>
> I guess that the software environment of the years between 2000 and
> 2010 and the lowering hardware costs of unaligned-access support
> eventually tipped the balance in favour of unaligned accesses. It's
> interesting that the same had earlier happened on S/360->S/370 and
> 68010->68020.
>
> Concerning the original question: One may also ask what the support
> for unaligned accesses bought the 8086: The 8086 was designed to be
> 8080-compatible at the assembly level (from what I read, this feature
> helped create an initial software base, even though it was not really
> used in later years), and this meant that unaligned accesses would
> need to be supported, too. If they had skimped on unaligned accesses,
> maybe the 8086 would have been much less successful than they were;
> but it was actually the 8088 that was successful, and unaligned
> accesses were for free on that, so it would not have changed much if
> the 8086 required alignment (if that requirement was not inherited to
> the 8088).
>
> - anton
> --
> 'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
> Mitch Alsup, <c17fcd89-f024-40e7...@googlegroups.com>

Quadibloc wrote:
> On Wednesday, July 5, 2023 at 5:48:17 PM UTC-6, EricP wrote:
>
>> And then the Standford MIPS came along,
>> And then the Alpha 21064 came along,
>
> Oh, dear. What a pity. While support for unaligned
> memory access is a convenience, I would have thought
> of it as a frill, that can, and should, be dispensed with on
> an architecture designed, say, for ultimate performance
> in high-performance computing.
>
> But if, in the real world, you are actually going to have to
> occasionally trap and emulate unaligned accesses, then
> unless "occasionally" is _very_ rare indeed, hardware support
> will be preferred.

The overhead of trap-and-emulate is the problem people most often cite
because it is in their face.

The far more insidious hidden problem is that while byte memory access cpus
*define* that reads and writes to adjacent memory cells are independent,
this is NOT true for cpus that use larger alignment and must perform
such updates as a read-modify-write operation in registers.

That RMW sequence means that adjacent byte and word and all unaligned
accesses are not independent as an update to one variable can clobber
and lose a concurrent update to an adjacent variable.

This race condition can show up even on uni-processors due to interrupts
and exceptions.

The fix is that all such byte, word and misaligned writes must be performed
as atomic LL-SC sequences. But since you don't know which variables are
adjacent then to be safe all such updates must be atomic. This turns each
such write into a subroutine call so the performance is terrible.
And this change must be applied to all code, just in case.

On Thursday, July 6, 2023 at 2:18:08 AM UTC-6, Anton Ertl wrote:
> EricP <ThatWould...@thevillage.com> writes:
> >And then the Alpha 21064 came along, believed this, eliminated unaligned
> >loads and stores, and found out humans do this *a lot*.
> >Then DEC lied it caused problems, blamed the humans, claimed the code was
> >broken to begin with (it wasn't),

> I don't remember this for the Alpha, but it's a common pattern.

I just remembered that unaligned loads and stores weren't
the _only_ thing the original Alpha didn't support.

They also didn't support any loads and stores of data shorter
than the full 64 bit width of the machine. *That* is something I
do tend to regard as a serious mistake.

John Savard

On Thursday, July 6, 2023 at 7:20:03 AM UTC-6, EricP wrote:

> The far more insidious hidden problem is that while byte memory access cpus
> *define* that reads and writes to adjacent memory cells are independent,
> this is NOT true for cpus that use larger alignment and must perform
> such updates as a read-modify-write operation in registers.
>
> That RMW sequence means that adjacent byte and word and all unaligned
> accesses are not independent as an update to one variable can clobber
> and lose a concurrent update to an adjacent variable.

I thought that x86 CPUs were designed to solve this problem.

The memory bus is organized so that there is one enable line for each seven
data lines, and, therefore, any read or write operation can be made to operate
only on specific bytes, no matter how wide the data bus.

And so a misaligned 64-bit data item, on a computer with a 64-bit data bus,
can always be fetched or written in only two accesses.

Of course, fetches are usually of an entire DRAM data line into the cache,
but that's another issue.

John Savard

On 7/6/2023 3:28 AM, robf...@gmail.com wrote:
> On Thursday, July 6, 2023 at 4:18:08 AM UTC-4, Anton Ertl wrote:
>> EricP <ThatWould...@thevillage.com> writes:
>>> Thomas Koenig wrote:
>>>> John Levine <jo...@taugh.com> schrieb:
>>>>> The original S/360 required everything to be aligned, while S/370
>>>>> allowed all data to be misaligned. IBM did a great deal of simulation
>>>>> before making architecture choices so I assume they had good reason to
>>>>> believe it would be an improvement.
>>>>
>>>> And then the 801 people came along and found out that compilers rarely,
>>>> if ever, issued misaligned loads and stores, and the RISC people turned
>>>> back the clock to aligned. High-end RISC systems generally support it
>>>> by now (even POWER), low-end microcontrollers may not, and RISC-V is
>>>> RISC-V because it may be even be trap/emulate there.
>>>
>>> And then the Standford MIPS came along, believed this, eliminated unaligned
>>> loads and stores, and found out that while compilers may not issue these
>>> humans do it *a lot*. Faced with the prospect of rewriting lots of code
>>> to suit their processor they chose to add it back in for their first
>>> commercial version, the MIPS R2000.
>> It's a long time since I used an R2000 based machine (and slightly
>> less since I last used an R3000 or R4000-based machine), but I am
>> pretty sure that the usual loads and stores require natural alignment
>> and trap on misaligned accesses. They also have lwl, lwr, swl and swr
>> for synthesizing unaligned accesses; and pseudo-instructions ulw, usw,
>> ulh, ulhu, ush that expand to sequences of machine instructions.
>> Raymond Chen describes this in
>> <https://devblogs.microsoft.com/oldnewthing/20180409-00/?p=98465>.
>>> And then the Alpha 21064 came along, believed this, eliminated unaligned
>>> loads and stores, and found out humans do this *a lot*.
>>> Then DEC lied it caused problems, blamed the humans, claimed the code was
>>> broken to begin with (it wasn't),
>> I don't remember this for the Alpha, but it's a common pattern.
>>> quietly published manuals on how to
>>> rewrite code to suit their processor, and finally added it back in again
>>> claiming it was to support Windows.
>> It's also been a while since I used an Alpha, but even on the 21264B
>> we saw notices of unaligned accesses by programs in the Linux kernel
>> logs, and I wrote <https://www.complang.tuwien.ac.at/anton/uace.c> to
>> control this Linux kernel feature (a similar program uac was available
>> on Digital OSF/1 (or whatever it had been renamed to at the time), and
>> as a result I (and my students) got SIGBUS signals on unaligned
>> accesses even on Linux (where normally the kernel emulated unaligned
>> accesses).
>>
>> Alpha also has ldq_u (which performed an aligned access using a
>> possibly unaligned address), and pseudo-instructions like ustq (which
>> expands to 11 instructions IIRC). I actually found that the gas
>> implementation of ustq was broken, which showed that no Linux software
>> used this pseudo-instruction.
>>
>> You may be confusing the unaligned access issue with byte and 16-bit
>> memory access, which was added in EV56.
>>
>> Trapping on unaligned accesses was very common at the time: the 68000
>> and 68010 do it (but the 68020 and onwards support unaligned
>> accesses), and all the first-generation RISCs also trap on unaligned
>> accesses: ARM, HPPA, MIPS, SPARC, 88k. In the second generation
>> (Power and Alpha) only Power in big-endian mode supports unaligned
>> accesses.
>>
>> Even Intel jumped on the alignment-requiring bandwagon: they added the
>> AC flag in the 486 (1989) and alignment-requiring memory accesses with
>> SSE (1999); of course, they did both in an idiotic way:
>>
>> 1) Setting AC requires 8-byte alignment for 8-byte FP numbers, but the
>> Intel-designed ABI requires 8-byte FP numbers to be stored with 4-byte
>> alignment, which means that you could not set AC except in very
>> confined circumstances.
>>
>> 2) Aligned SSE memory accesses require 16-byte alignments, while the
>> elements were smaller; this means that you either use the unaligned
>> load and store instructions, or your vectorized code has to
>> special-case the first and last elements to achieve alignment. AMD
>> added a flag for dropping the alignment requirement for implicit SSE
>> memory accesses. Intel did not follow AMD in that, but dropped the
>> alignment requirement in AVX; this would have been ok if AVX had been
>> universally available, but unfortunately AVX was not implemented in
>> Intel's cheap cores up to Gracemont, and often disabled on lower-end
>> SKUs of their expensive cores.
>>
>> Back to earlier times: Many RISCs died over the years, with IA-64's
>> prospect bing particularly deadly: HPPA, MIPS (as GP-computer
>> architecture), and Alpha were cancelled and intended to be replaced
>> with IA-64.
>>
>> IA-64 also did not guarantee that unaligned accesses work. More
>> precisely,
>> <https://www.ece.lsu.edu/ee4720/doc/itanium-arch-2.1-v2.pdf> says on
>> page 2:78:
>>
>> |When PSR.ac is 1, any Itanium data memory reference that is not
>> |aligned on a boundary the size of the operand results in an Unaligned
>> |Data Reference fault; e.g., 1, 2, 4, 8, 10, and 16-byte datums should
>> |be aligned on 1, 2, 4, 8, 16, and 16-byte boundaries respectively to
>> |avoid generation of an Unaligned Data Reference fault.
>> |...
>> |When PSR.ac is 0, Itanium data memory references that are not aligned
>> |may or may not result in an Unaligned Data Reference fault based on
>> |the implementation. The level of unaligned memory support is
>> |implementation specific. However, all implementations will raise an
>> |Unaligned Data Reference fault if the datum referenced by an Itanium
>> |instruction spans a 4K aligned boundary, and many implementations will
>> |raise an Unaligned Data Reference fault if the datum spans a cache
>> |line. Implementations may also raise an Unaligned Data Reference
>> |fault for any other unaligned Itanium memory reference.
>>
>> The wider support for unaligned accesses came only later: ARM added
>> support for unaligned accesses, Power had it already for big-endian
>> (and later added it for little-endian, along with a new form of
>> little-endian support), IA-64 and SPARC died out, and ARM A64 and
>> RISC-V support unaligned accesses, leaving only architectures with
>> unaligned-access support for general-purpose computers.
>>
>> I guess that the RISC-V decision shows that by that time (early 2010s,
>> does anybody know a more exact date?) unaligned access support had
>> won.
>>
>> It's interesting to speculate why we have had alignment requirements
>> for so long in RISCs (from the 1980s to the 2000s), and eventually
>> unaligned won. It seems that the forces involved were relatively
>> small:
>>
>> The number of unaligned-access reports in the Linux kernel log on
>> Alpha were relatively small, so software emulation is a minor cost.
>>
>> Another cost of alignment requirements is the problem of using the
>> instructions in a SIMD context (even non-SIMD instructions, e.g.,
>> performing a hash of a string by loading 8-byte pieces and mixing them
>> with the hash value up to now). One can use stuff like Alpha's uldq
>> for such uses and memcpy() to make the compiler generate it in
>> somewhat recent C compilers, but I guess that doing stuff like *p
>> (which generates an alignment-requiring ldq on the Alpha) was frequent
>> enough in the early 2000s (when Linux on IA-32/AMD64 had become the
>> dominant Unix) that architectures finally added support for unaligned
>> accesses.
>>
>> The hardware cost of supporting unaligned accesses is not that large,
>> as Mitch Alsup explained elsewhere in this thread, and that cost got
>> relatively smaller as transistor density increased.
>>
>> I guess that the software environment of the years between 2000 and
>> 2010 and the lowering hardware costs of unaligned-access support
>> eventually tipped the balance in favour of unaligned accesses. It's
>> interesting that the same had earlier happened on S/360->S/370 and
>> 68010->68020.
>>
>> Concerning the original question: One may also ask what the support
>> for unaligned accesses bought the 8086: The 8086 was designed to be
>> 8080-compatible at the assembly level (from what I read, this feature
>> helped create an initial software base, even though it was not really
>> used in later years), and this meant that unaligned accesses would
>> need to be supported, too. If they had skimped on unaligned accesses,
>> maybe the 8086 would have been much less successful than they were;
>> but it was actually the 8088 that was successful, and unaligned
>> accesses were for free on that, so it would not have changed much if
>> the 8086 required alignment (if that requirement was not inherited to
>> the 8088).
>>
>> - anton
>> --
>> 'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
>> Mitch Alsup, <c17fcd89-f024-40e7...@googlegroups.com>
>
> For a while my Thor core had only partial unaligned access. Partial being
> unaligned access allowed but only if it fit into a cache line. With a cache
> line being 64 bytes unaligned access was mostly supported. Thor has
> since been updated to in theory support any unaligned access. Running
> two memory cycles if the access spans 64 bytes. Yet to be tested. A lot
> of shifting is required just for aligned access when data is coming from
> or going to the cache line.
>
> IMO unaligned access is worth supporting. Even instruction access should
> support unaligned access.

Quadibloc wrote:
> On Thursday, July 6, 2023 at 7:20:03 AM UTC-6, EricP wrote:
>
>> The far more insidious hidden problem is that while byte memory access cpus
>> *define* that reads and writes to adjacent memory cells are independent,
>> this is NOT true for cpus that use larger alignment and must perform
>> such updates as a read-modify-write operation in registers.
>>
>> That RMW sequence means that adjacent byte and word and all unaligned
>> accesses are not independent as an update to one variable can clobber
>> and lose a concurrent update to an adjacent variable.
>
> I thought that x86 CPUs were designed to solve this problem.
>
> The memory bus is organized so that there is one enable line for each seven
> data lines, and, therefore, any read or write operation can be made to operate
> only on specific bytes, no matter how wide the data bus.
>
> And so a misaligned 64-bit data item, on a computer with a 64-bit data bus,
> can always be fetched or written in only two accesses.
>
> Of course, fetches are usually of an entire DRAM data line into the cache,
> but that's another issue.
>
> John Savard

On x86 as on VAX the adjacent bytes are accessed as independent memory cells.
If two independent program variables just happen to be located in adjacent
memory bytes then in the two statements
c1 = ...
c2 = ...
the updates cannot interact.

Stanford MIPS had 32-bit aligned and Alpha 21064 32/64-bit aligned memory
cells. Byte, word and unaligned and straddle accesses were done by reading
a 32/64-bit cell into register, using byte extract and insert instructions
on the register, then writing the whole 32/64-bit memory cell back.

In the second case the variable updates which appear independent may not be
as concurrent exceptions and IO operations can create hidden race conditions
which result in lost updates due to the RMW operation.

For example, if c1 is written by the main program and c2 by a catch handler
which interrupts the RMW sequence for the adjacent c1. The handler updates
c2 and returns, the write of c1 finishes and overwrites the new value in c2
with its prior value.

A program which works fine on VAX or x86 might fail for no apparent reason
on an Alpha 21064. When inspected with the debugger no fault is apparent.
If one introduces a multi-threaded OS then the number of potential race
conditions goes up, and then up again for true SMP multi-processors.

Russell Wallace wrote:
> The Intel 8086 supported unaligned loads and stores of 16-bit data,
> e.g. mov ax, foo was guaranteed to work even if foo was odd.
>
> What did this cost, in terms of performance and chip area, compared
> to an alternative architecture that would have been the same except
> for unaligned access being a trap or undefined behavior?
>
> To be clear, I'm not talking about the dynamic behavior of code. On
> the actual 8086, access was still faster if the pointer did happen to
> be even. I'm asking, suppose all your pointers for word access were
> actually even, how much bigger and slower was the chip made by having
> to support the possibility that some of them could have been odd?

I would suggest that since they already knew that they would make an
8-bit bus version (the 8088 which ended up in the IBM PC), the control
circuits already knew how to combine two 8-bit accesses into a 16-bit
load. In the '86 an aligned 16-bit load would run a single bus cycle
(taking 4 clock cycles), while the same operation on the '88 took twice
as long. Unless the '86 coud do unaligned accesses in less than 8
cycles, I would guess the mechanism was the same!

Terje

--
- <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"

MitchAlsup <MitchAlsup@aol.com> schrieb:

> FORTRAN common blocks required misaligned DP FP accesses.

That is probably the most-ignored part of the Fortran standard.
Even the very first FORTRAN 77 compiler, by Bell Labs, aligned the
data in COMMON blocks.

The x86-64 psABI also specified aligned COMMON blocks (they are
treated the same as structs).

Hm... which ABI actually specifies non-aligned access? I don't
know of any.

On 7/6/2023 11:16 AM, Terje Mathisen wrote:
> Russell Wallace wrote:
>> The Intel 8086 supported unaligned loads and stores of 16-bit data,
>> e.g. mov ax, foo was guaranteed to work even if foo was odd.
>>
>> What did this cost, in terms of performance and chip area, compared
>> to an alternative architecture that would have been the same except
>> for unaligned access being a trap or undefined behavior?
>>
>> To be clear, I'm not talking about the dynamic behavior of code. On
>> the actual 8086, access was still faster if the pointer did happen to
>> be even. I'm asking, suppose all your pointers for word access were
>> actually even, how much bigger and slower was the chip made by having
>> to support the possibility that some of them could have been odd?
>
> I would suggest that since they already knew that they would make an
> 8-bit bus version (the 8088 which ended up in the IBM PC), the control
> circuits already knew how to combine two 8-bit accesses into a 16-bit
> load. In the '86 an aligned 16-bit load would run a single bus cycle
> (taking 4 clock cycles), while the same operation on the '88 took twice
> as long. Unless the '86 coud do unaligned accesses in less than 8
> cycles, I would guess the mechanism was the same!
>

This makes it seem like the 8086/8088 would have been painfully slow?...

Like, how exactly did they run programs like Wolfenstein 3D or the
various platformer games?...

Like, even with all my fancy stuff, and a 1-cycle throughput for many
memory accesses to the L1 cache, still difficult to get any semblance of
usable performance with things like Wolf3D much under ~ 10-14 MHz ...

Granted, a lot of these also required VGA, so maybe running them on the
original PC wasn't really a thing even if they were originally written
for 16-bit real-mode?...

> Terje
>