This is a bit of a strange failure message on a really strange machine.
Perhaps the word "strange" is wrong here. What I mean to say is that it
is very old and obscure in this modern world. I have managed to restore
a 1997 Digital DEC AlphaStation 600 to flawless working order. Which is
to say I tossed a lot of money and time at this thing and it works
perfectly in every measurable way.
It will never ever run Linux. This is because the Alpha 21164 EV5 was
dropped out of the Linux kernel.[1] Therefore the machine runs OpenBSD
and it seems to work great. Even the tape drive. However I must build
anything else I want from sources. C'est la Vie.
Just about everything builds cleanly and I even figured out how to get
really clean IEEE-754 floating point compliance from the monster.
GNU M4 has a single little personality issue here :
centauri$ cat tests/test-suite.log
=========================================
GNU M4 1.4.21: tests/test-suite.log
=========================================
# TOTAL: 382
# PASS: 333
# SKIP: 48
# XFAIL: 0
# FAIL: 1
# XPASS: 0
# ERROR: 0
System information (uname -a): OpenBSD 7.8 GENERIC#628
.. contents:: :depth: 2
FAIL: test-regex
================
Alarm clock
FAIL test-regex (exit status: 142)
centauri$
Yes the hostname of this Alpha is "centauri" ;)
Well there you have it. Alarm clock. Not sure what else to say here
other than it seems to run great. I can post the entire configuration
command line here as well as CFLAGS and there is not much else to say.
centauri$ ./configure --prefix=/opt/bw --disable-silent-rules \
--enable-dependency-tracking --enable-threads=posix \
--with-libsigsegv --with-gnu-ld --with-libsigsegv-prefix=/opt/bw \
--with-libiconv-prefix=/opt/bw --without-libintl-prefix
That seems to "just work"(tm).
centauri$
centauri$ $CC --version
gcc (GCC) 4.2.1 20070719
Copyright (C) 2007 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
centauri$
centauri$ echo $CFLAGS
-g -O0 -mcpu=21164 -mgas -mexplicit-relocs -fno-fast-math -fno-builtin
-fno-unsafe-math-optimizations -mno-soft-float -mfp-trap-mode=sui
-mfp-rounding-mode=n -mtrap-precision=i -mieee-with-inexact
-mieee-conformant
centauri$
centauri$ echo $CPPFLAGS
-D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64
centauri$
A detailed explanation of the CFLAGS can be seen in the lib MPFR mail
list where the machine builds and tests all of GMP, MPFR and that
include the new MPC just fine and dandy.
https://sympa.inria.fr/sympa/arc/mpfr/2026-03/msg00000.html
I can likely ignore this single failure?
--
--
Dennis Clarke
RISC-V/SPARC/PPC/ARM/CISC
UNIX and Linux spoken
[1] see
https://lore.kernel.org/lkml/[email protected]/T/#m48242a03ae584715edb4274247b2fbcd3d104ef3
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1036158
Also some thoughts from Linus are posted below.
--------------------------------------
I have some bad news for you: the old alpha CPU's not only screwed up
the byte/word design, they _also_ screwed up the
load-locked/store-conditional.
You'd think that LL/SC would be done at a cacheline level, like any
sane person would do.
But no.
The 21064 actually did atomicity with an external pin on the bus, the
same way people used to do before caches even existed.
Yes, it has an internal L1 D$, but it is a write-through cache, and
clearly things like cache coherency weren't designed for. In fact,
LL/SC is even documented to not work in the external L2 cache
("Bcache" - don't ask me why the odd naming).
So LL/SC on the 21064 literally works on external memory.
Quoting the reference manual:
"A.6 Load Locked and Store Conditional
The 21064 provides the ability to perform locked memory accesses
through the LDxL (Load_Locked) and STxC (Store_Conditional) cycle
command pair. The LDxL command forces the 21064 to bypass the Bcache
and request data directly from the external memory interface.
The memory interface logic must set a special interlock flag as it
returns the data, and may optionally keep the locked address"
End result: a LL/SC pair is very very slow. It was incredibly slow
even for the time. I had benchmarks, I can't recall them, but I'd like
to say "hundreds of cycles". Maybe thousands.
So actual reliable byte operations are not realistically possible on
the early alpha CPU's. You can do them with LL/SC, sure, but
performance would be so horrendously bad that it would be just sad.
The 21064A had some "fast lock" mode which allows the data from the
LDQ_L to come from the Bcache. So it still isn't exactly fast, and it
still didn't work at CPU core speeds, but at least it worked with the
external cache.
Compilers will generate the sequence that DEC specified, which isn't
thread-safe.
In fact, it's worse than "not thread safe". It's not even safe on UP
with interrupts, or even signals in user space.
It's one of those "technically valid POSIX", since there's
"sig_atomic_t" and if you do any concurrent signal stuff you're
supposed to only use that type. But it's another of those "Yeah, you'd
better make sure your structure members are either 'int' or bigger, or
never accessed from signals or interrupts, or they might clobber
nearby values".
Linus
