POWER tries to minimize software licensing expenses.
Including by playing dirty game of calling something that for most
practical purposes is a dual-core or quad-core cluster "a core".
On Sun, 22 Mar 2026 11:22:36 +0000, Thomas Koenig wrote:
Ah, that's where the people who furnished the Fountainhead project at
Data General got their ideas about programming-language dependent
microcode from.
IBM did do a lot of things connected with making their computers more powerful by doing stuff in microcode. Much better known than the 360/25 FORTRAN was a project to implement APL in microcode.
Slaps hood of RISC-V;
"You wouldn't believe how many non-free but rarely encountered and essentially useless edge cases we fit in there".
On Sun, 22 Mar 2026 03:28:36 +0200, Michael S wrote:
POWER tries to minimize software licensing expenses.
Including by playing dirty game of calling something that for most
practical purposes is a dual-core or quad-core cluster "a core".
I'm a bit puzzled. Why would IBM design their PowerPC chips so as to cheat >themselves?
On Sun, 22 Mar 2026 03:28:36 +0200, Michael S wrote:
POWER tries to minimize software licensing expenses.
Including by playing dirty game of calling something that for most
practical purposes is a dual-core or quad-core cluster "a core".
I'm a bit puzzled. Why would IBM design their PowerPC chips so as to cheat themselves?
BGB [2026-03-23 14:36:14] wrote:
Slaps hood of RISC-V;
"You wouldn't believe how many non-free but rarely encountered and
essentially useless edge cases we fit in there".
I'd be interested to hear about the cases you encountered.
Interesting that Power and S390x still persevere. For S390x I expect
that the customers are not price-sensitive, and lots of legacy code in assembly language tied to some proprietary OS makes porting extra-hard
and extra-risky. For Power, maybe the AS/400 customers are in a
similar position. For MIPS, HPPA and SPARC there were lots of Unix
customers for whom the jump to Linux was not that hard. For Alpha the
VMS customer base apparently was not captured with enough ties to
sustain Alpha (or later IA-64).
According to Tim Rentsch <tr.17687@z991.linuxsc.com>:
quadi <quadibloc@ca.invalid> writes:
On Tue, 17 Mar 2026 20:18:00 +0000, John Dallman wrote:
Think about it. If this is possible, the parity checks must be
implemented by microcode.
It is true that nearly all System/360 models, except the Model 75 and the >>> 91/95/195, were microcoded.
There was also the 360/44 if I am not mistaken.
The 360/44 was an odd machine with a hardware implmentation of a
scientific subset of the 360's instruction set. It had optional
priority interrupt and a high speed direct data channel intended for real-time data acquisition and control. It also had a knob to control floating point precision, so you could get less accurate answers
faster, which I suppose was intended to help tight time budgets in
real-time calculations.
I don't think they made very many of them. The 16-bit rack mounted 1800
was a lot more popular.
On Sun, 22 Mar 2026 03:28:36 +0200, Michael S wrote:
POWER tries to minimize software licensing expenses.
Including by playing dirty game of calling something that for most practical purposes is a dual-core or quad-core cluster "a core".
I'm a bit puzzled. Why would IBM design their PowerPC chips so as to
cheat themselves?
But then there was the famous lawsuit against AMD because in some of
their older chips, two cores shared one vector unit.
John Savard
On Mon, 23 Mar 2026 19:18:49 -0000 (UTC)
quadi <quadibloc@ca.invalid> wrote:
On Sun, 22 Mar 2026 03:28:36 +0200, Michael S wrote:
POWER tries to minimize software licensing expenses.
Including by playing dirty game of calling something that for most
practical purposes is a dual-core or quad-core cluster "a core".
I'm a bit puzzled. Why would IBM design their PowerPC chips so as to
cheat themselves?
Because Oracle on Power is more popular than DB2 on Power.
They are trying to help their customers to cheat Larry.
F/D:
Mu original FPU design: Simpler/cheaper The RV F/D extensions required
adding a bunch of stuff;
Now I am thinking it makes more sense to go back to a simpler FPU and
trap on anything that the simple FPU doesn't do natively.
So, at the ISA level, we want it to look like all of F/D is present and works, and implements full IEEE semantics.
quadi <quadibloc@ca.invalid> schrieb:
On Sun, 22 Mar 2026 03:28:36 +0200, Michael S wrote:
POWER tries to minimize software licensing expenses.
Including by playing dirty game of calling something that for most
practical purposes is a dual-core or quad-core cluster "a core".
I'm a bit puzzled. Why would IBM design their PowerPC chips so as to cheat >> themselves?
If (non-IBM) software is paid for per core by IBM's customers, then
the IBM customer has an advantage, which is a possible motivation
to buy IBM hardware, if software license costs dominate.
On 3/23/2026 2:52 PM, Stefan Monnier wrote:
BGB [2026-03-23 14:36:14] wrote:
Slaps hood of RISC-V;
"You wouldn't believe how many non-free but rarely encountered and
essentially useless edge cases we fit in there".
I'd be interested to hear about the cases you encountered.
JAL and JALR:
Rd as pretty much anything other than X0 or X1;
It is cheaper for hardware to hard-wire the link register.
Most instructions:
Rd is X0..X3:
X0/ZR: Most instructions are Hint instructions;
X1/RA: Mostly doesn't happen (excluding LD)
X2/SP: Mostly doesn't happen
X3/GP: Mostly doesn't happen
X1: Rarely used as an input except for JALR and SD.
X2: Primarily used as a base register, or adjusted by an ADDI
X3: Almost exclusively used as a base register.
For most instructions, can disallow using X1..X3 as inputs.
Particularly as inputs for Rs2.
These registers can be treated as special because they may either need special handling in the register fetch logic or because it makes sense
for architectural reasons to have "side-channel access for them".
Contrast, X4..X31 can be treated as "true GPRs".
Most other edge cases are more narrow in scope.Surprising.
Some others, like "REM*", are just so rarely used as to not be worth bothering with supporting natively.
So, say:
MULW: Semi-common;
MUL: Semi-Rare
DIVW: Semi-Rareunsurprising.
DIV: Rare
REMW and REM: Very rare.
MUL and DIVW are in a gray area:
Rare enough to make it hard to justify making them fast;
Too common to justify throwing them to a trap handler.
REM and REMW cross into the domain where a trap handler starts seeming sane.
Some LUTS can be saved by narrowing the scope of the Shift-ADD unit to
not include REM/REMW.
The 'A' instructions ("AMOxx"):
Mostly unused in practice.
May see LR/SC in Mutex handling, but can trap for this.
Less efficient than using a syscall, but, ...
These have "noble purpose", but not the same as saying this makes sense.
F/D:
Mu original FPU design: Simpler/cheaper
The RV F/D extensions required adding a bunch of stuff;
Now I am thinking it makes more sense to go back to a simpler FPU and
trap on anything that the simple FPU doesn't do natively.
So, at the ISA level, we want it to look like all of F/D is present and works, and implements full IEEE semantics.
But, what is actually needed here, is more narrow in scope.That removes the need for IEEE semantics.
So, "actual FPU":
FADD/FSUB/FMUL
DAZ+FTZ
RNE and RTZ only (with DYN for C land FPU ops)Err, no.
...
Then pretty much anything else either immediately traps (like FDIV or FMADD), or traps based on inputs or outputs:
Any of the operations encountering a subnormal input;Thinking small again.
Output goes out of range (overflow/underflow);Thinking very small again.
Rounding fails for RNE (would carry across too many bits of the mantissa); FMUL with low-order input bits as non-zero (in IEEE emulation mode).
...
Or, say:
RV64I (Mostly)
M: Partial
A: Skip (Emulated)
F/D: Partial
C: Maybe/Optional (needed for RV64GC).
Then, just sorta pretend it is RV64G or RV64GC.
Part of the goal being to find practical ways to reduce costs enough to allow use on cheaper FPGA boards (within the limit though that the FPGA boards will still need DDR RAM chips or similar). Like, as-is, one needs
one some the larger chips from the Spartan-7 Artix-7 lines (but, a lot
of the boards with the smaller Spartan and Artix FPGAs tend to lack RAM chips).
Well, even if something like an Arty board or Nexys-A7 or similar is
kinda expensive (say, vs a CMod).
For cheaper cores, could implement RV64IM and then emulate the rest in
trap handlers.
On Mon, 23 Mar 2026 17:38:24 -0500, BGB wrote:
F/D:
Mu original FPU design: Simpler/cheaper The RV F/D extensions required
adding a bunch of stuff;
Now I am thinking it makes more sense to go back to a simpler FPU and
trap on anything that the simple FPU doesn't do natively.
So, at the ISA level, we want it to look like all of F/D is present and
works, and implements full IEEE semantics.
I can't comment on the other RISC-V edge cases, and the principle of
trapping things that are exremely rare certainly is sound... but depending
on the usage case of a particular RISC-V implementation, of course,
anything that heavily uses floating-point is going to encounter denormals often enough so that handling them by trapping is likely to noticeably
affect performance.
On 3/24/2026 6:40 AM, quadi wrote:
On Mon, 23 Mar 2026 17:38:24 -0500, BGB wrote:
F/D:
Mu original FPU design: Simpler/cheaper The RV F/D extensions required
adding a bunch of stuff;
Now I am thinking it makes more sense to go back to a simpler FPU and
trap on anything that the simple FPU doesn't do natively.
So, at the ISA level, we want it to look like all of F/D is present and
works, and implements full IEEE semantics.
I can't comment on the other RISC-V edge cases, and the principle of
trapping things that are exremely rare certainly is sound... but
depending
on the usage case of a particular RISC-V implementation, of course,
anything that heavily uses floating-point is going to encounter denormals
often enough so that handling them by trapping is likely to noticeably
affect performance.
Potentially it is cause for concern.
Looking at the stats:
BGB <cr88192@gmail.com> posted:
On 3/23/2026 2:52 PM, Stefan Monnier wrote:They did this because they wanted to put all those STs in prologue
BGB [2026-03-23 14:36:14] wrote:
Slaps hood of RISC-V;
"You wouldn't believe how many non-free but rarely encountered and
essentially useless edge cases we fit in there".
I'd be interested to hear about the cases you encountered.
JAL and JALR:
Rd as pretty much anything other than X0 or X1;
It is cheaper for hardware to hard-wire the link register.
and all those LDs in epilogue in separate subroutines (ASM with
multiple entry points).
Most instructions:
Rd is X0..X3:
X0/ZR: Most instructions are Hint instructions;
X1/RA: Mostly doesn't happen (excluding LD)
X2/SP: Mostly doesn't happen
X3/GP: Mostly doesn't happen
These have to go somewhere::
a) My 66000 needs no zero register
b) My 66000 needs no Frame Pointer 90%+ of the time
c) R0 gets Return address on a call (non-safe-stack mode)
*CSP-- gets Return address on a safe-stack call
R0 is a GPR at other times
R0 is a proxy for IP when used as base register
RO is a proxy for zero when used as index register
X1: Rarely used as an input except for JALR and SD.
X2: Primarily used as a base register, or adjusted by an ADDI
X3: Almost exclusively used as a base register.
For most instructions, can disallow using X1..X3 as inputs.
Particularly as inputs for Rs2.
So, in effect RISC-V only has 28 GPRs ....
These registers can be treated as special because they may either needSurprising.
special handling in the register fetch logic or because it makes sense
for architectural reasons to have "side-channel access for them".
Contrast, X4..X31 can be treated as "true GPRs".
Most other edge cases are more narrow in scope.
Some others, like "REM*", are just so rarely used as to not be worth
bothering with supporting natively.
So, say:
MULW: Semi-common;
MUL: Semi-Rare
DIVW: Semi-Rareunsurprising.
DIV: Rare
REMW and REM: Very rare.
MUL and DIVW are in a gray area:
Rare enough to make it hard to justify making them fast;
Too common to justify throwing them to a trap handler.
Mc 88100 had 4 cycle MUL in 1987--why do less now ??
REM and REMW cross into the domain where a trap handler starts seeming sane.
If you have high speed MUL and tolerable speed DIV you can make REM
only MUL cycles slower than DIV.
Some LUTS can be saved by narrowing the scope of the Shift-ADD unit toI agree that ATOMIC stuff is absolutely necessary !!
not include REM/REMW.
The 'A' instructions ("AMOxx"):
Mostly unused in practice.
May see LR/SC in Mutex handling, but can trap for this.
Less efficient than using a syscall, but, ...
These have "noble purpose", but not the same as saying this makes sense. >>
I might disagree that LL/SC is noble.
F/D:
Mu original FPU design: Simpler/cheaper
The RV F/D extensions required adding a bunch of stuff;
Now I am thinking it makes more sense to go back to a simpler FPU and
trap on anything that the simple FPU doesn't do natively.
I used to think that way: now I prefer an FPU that "does everything else" {FDIV, SQRT, SIN, COS, LN, EXP, POW, ATAN, Conversions, ...}
So, at the ISA level, we want it to look like all of F/D is present and
works, and implements full IEEE semantics.
Finally...
But, what is actually needed here, is more narrow in scope.That removes the need for IEEE semantics.
So, "actual FPU":
FADD/FSUB/FMUL
DAZ+FTZ
RNE and RTZ only (with DYN for C land FPU ops)Err, no.
...
Then pretty much anything else either immediately traps (like FDIV or
FMADD), or traps based on inputs or outputs:
So any calculation with other than RNE and RTZ trap ?!?
Unworkable.
Any of the operations encountering a subnormal input;Thinking small again.
Output goes out of range (overflow/underflow);Thinking very small again.
Rounding fails for RNE (would carry across too many bits of the mantissa); >> FMUL with low-order input bits as non-zero (in IEEE emulation mode).
So, let me get this right:
a) you support IEEE 754-2019 semantics
b) but don't want to actually support IEEE 754-2019 semantics !?!?
...A chip with 16 cores is not "core bound" but {PCIe root complex, DRAM controller, L3, intra-chip interconnect, often l2, and Pin interface}
Or, say:
RV64I (Mostly)
M: Partial
A: Skip (Emulated)
F/D: Partial
C: Maybe/Optional (needed for RV64GC).
Then, just sorta pretend it is RV64G or RV64GC.
Part of the goal being to find practical ways to reduce costs enough to
allow use on cheaper FPGA boards (within the limit though that the FPGA
boards will still need DDR RAM chips or similar). Like, as-is, one needs
one some the larger chips from the Spartan-7 Artix-7 lines (but, a lot
of the boards with the smaller Spartan and Artix FPGAs tend to lack RAM
chips).
Well, even if something like an Arty board or Nexys-A7 or similar is
kinda expensive (say, vs a CMod).
For cheaper cores, could implement RV64IM and then emulate the rest in
trap handlers.
bound.
On 3/24/2026 12:35 PM, BGB wrote:
On 3/24/2026 6:40 AM, quadi wrote:
On Mon, 23 Mar 2026 17:38:24 -0500, BGB wrote:
F/D:
Mu original FPU design: Simpler/cheaper The RV F/D extensions required >>>> adding a bunch of stuff;
Now I am thinking it makes more sense to go back to a simpler FPU and
trap on anything that the simple FPU doesn't do natively.
So, at the ISA level, we want it to look like all of F/D is present and >>>> works, and implements full IEEE semantics.
I can't comment on the other RISC-V edge cases, and the principle of
trapping things that are exremely rare certainly is sound... but
depending
on the usage case of a particular RISC-V implementation, of course,
anything that heavily uses floating-point is going to encounter
denormals
often enough so that handling them by trapping is likely to noticeably
affect performance.
Potentially it is cause for concern.
Looking at the stats:
I would be reluctant to assume generality for any statistics where the benchmarks were strictly game programs. There are publicly available programs that, I suspect, are different enough from games to give you potentially different results.
On 3/24/2026 3:48 PM, Stephen Fuld wrote:
On 3/24/2026 12:35 PM, BGB wrote:
On 3/24/2026 6:40 AM, quadi wrote:
On Mon, 23 Mar 2026 17:38:24 -0500, BGB wrote:
F/D:
Mu original FPU design: Simpler/cheaper The RV F/D extensions required >>>>> adding a bunch of stuff;
Now I am thinking it makes more sense to go back to a simpler FPU and >>>>> trap on anything that the simple FPU doesn't do natively.
So, at the ISA level, we want it to look like all of F/D is present >>>>> and
works, and implements full IEEE semantics.
I can't comment on the other RISC-V edge cases, and the principle of
trapping things that are exremely rare certainly is sound... but
depending
on the usage case of a particular RISC-V implementation, of course,
anything that heavily uses floating-point is going to encounter
denormals
often enough so that handling them by trapping is likely to noticeably >>>> affect performance.
Potentially it is cause for concern.
Looking at the stats:
I would be reluctant to assume generality for any statistics where the
benchmarks were strictly game programs. There are publicly available
programs that, I suspect, are different enough from games to give you
potentially different results.
Maybe...
Are you thinking I should try porting LINPACK or similar?...
Or something like ODE or Bullet?...
On 3/24/2026 2:19 PM, MitchAlsup wrote:-------------------------
Mc 88100 had 4 cycle MUL in 1987--why do less now ??
MULW (32-bit) is fast, mostly for sake of DSPs allowing for fast 32-bit multiply.
MUL (64-bit) is harder to make fast...
This is a pretty big ask for the DSPs.
Shift-and-ADD works, but is slower.
There isn't really a good intermediate option.
At this stage, I am not saying that one doesn't have it at the ISA
level, but it is harder to justify it at the hardware level.
But trying to fit a single core with a non-awful FPU into an FPGA with
33k LUTs is an issue...
And, if you can afford 40 or 45 kLUT for the CPU core, can probably
afford a "less bad" FPU.
So, people, what would you recommend for BGB to use for FP testing?
Stephen Fuld <sfuld@alumni.cmu.edu.invalid> posted:
SPEC FP.
So, people, what would you recommend for BGB to use for FP testing?
On 3/24/2026 6:21 PM, MitchAlsup wrote:
Stephen Fuld <sfuld@alumni.cmu.edu.invalid> posted:
SPEC FP.
So, people, what would you recommend for BGB to use for FP testing?
Is there a version of SPEC FP that is available for free? I get the impression that BGB doesn't have a lot of money to spend on such things.
IIUC HPPA had production problems and HP going for IA-64 broke
confidence in long term viablity of HPPA.
I think Alpha had similar situation: DEC folded and HP had too
many architectures.
And HP actively tried to migrate customers from Alpha to IA-64.
When IA-64 disater became clear those customers did not go back
for Alpha.
I have no first hand experience with Power, but various published
numbers suggested that it performed well.
On 3/24/2026 6:21 PM, MitchAlsup wrote:
Stephen Fuld <sfuld@alumni.cmu.edu.invalid> posted:
SPEC FP.
So, people, what would you recommend for BGB to use for FP testing?
Is there a version of SPEC FP that is available for free?
I get the impression that BGB doesn't have a lot of money to spend on such things.
On 3/24/2026 8:37 PM, Stephen Fuld wrote:
On 3/24/2026 6:21 PM, MitchAlsup wrote:
Stephen Fuld <sfuld@alumni.cmu.edu.invalid> posted:
SPEC FP.
So, people, what would you recommend for BGB to use for FP testing?
Is there a version of SPEC FP that is available for free? I get the
impression that BGB doesn't have a lot of money to spend on such things.
Yeah, and not going to use a proprietary benchmark here...
Thomas Koenig <tkoenig@netcologne.de> writes:
quadi <quadibloc@ca.invalid> schrieb:
On Sun, 22 Mar 2026 03:28:36 +0200, Michael S wrote:
POWER tries to minimize software licensing expenses.
Including by playing dirty game of calling something that for most
practical purposes is a dual-core or quad-core cluster "a core".
I'm a bit puzzled. Why would IBM design their PowerPC chips so as to cheat >>> themselves?
If (non-IBM) software is paid for per core by IBM's customers, then
the IBM customer has an advantage, which is a possible motivation
to buy IBM hardware, if software license costs dominate.
Why would an ISV pay the cost of the Power port and then charge less
for the license on a similar-capacity machine.
BGB <cr88192@gmail.com> schrieb:
On 3/24/2026 8:37 PM, Stephen Fuld wrote:
On 3/24/2026 6:21 PM, MitchAlsup wrote:
Stephen Fuld <sfuld@alumni.cmu.edu.invalid> posted:
SPEC FP.
So, people, what would you recommend for BGB to use for FP testing?
Is there a version of SPEC FP that is available for free? I get the
impression that BGB doesn't have a lot of money to spend on such things. >>>
Yeah, and not going to use a proprietary benchmark here...
You could use coremark, https://github.com/eembc/coremark , Whetstone https://www.netlib.org/benchmark/whetstone.c , Dhrystone https://homepages.cwi.nl/~steven/dry.c or embench https://github.com/embench/embench-iot .
Anton Ertl <anton@mips.complang.tuwien.ac.at> schrieb:
Thomas Koenig <tkoenig@netcologne.de> writes:
quadi <quadibloc@ca.invalid> schrieb:
On Sun, 22 Mar 2026 03:28:36 +0200, Michael S wrote:
POWER tries to minimize software licensing expenses.
Including by playing dirty game of calling something that for
most practical purposes is a dual-core or quad-core cluster "a
core".
I'm a bit puzzled. Why would IBM design their PowerPC chips so as
to cheat themselves?
If (non-IBM) software is paid for per core by IBM's customers, then
the IBM customer has an advantage, which is a possible motivation
to buy IBM hardware, if software license costs dominate.
Why would an ISV pay the cost of the Power port and then charge less
for the license on a similar-capacity machine.
They pay per core. If the core happens to have 8-way multithreading
and has more performance because of that - well, that's what hardware
vendors have to deal with.
On Wed, 25 Mar 2026 20:31:35 -0000 (UTC)
Thomas Koenig <tkoenig@netcologne.de> wrote:
Anton Ertl <anton@mips.complang.tuwien.ac.at> schrieb:
Thomas Koenig <tkoenig@netcologne.de> writes:
quadi <quadibloc@ca.invalid> schrieb:
On Sun, 22 Mar 2026 03:28:36 +0200, Michael S wrote:
POWER tries to minimize software licensing expenses.
Including by playing dirty game of calling something that for
most practical purposes is a dual-core or quad-core cluster "a
core".
I'm a bit puzzled. Why would IBM design their PowerPC chips so as
to cheat themselves?
If (non-IBM) software is paid for per core by IBM's customers, then
the IBM customer has an advantage, which is a possible motivation
to buy IBM hardware, if software license costs dominate.
Why would an ISV pay the cost of the Power port and then charge less
for the license on a similar-capacity machine.
They pay per core. If the core happens to have 8-way multithreading
and has more performance because of that - well, that's what hardware
vendors have to deal with.
Didn' you mean "software vendors have to deal with" ?
In case of Oracle, they certainly fight back, by charging more per
each POWER core than per other types of cores. But they can not charge
too much, because there exists competition, including from IBM
themselves (DB2).
On 3/25/2026 11:31 AM, Thomas Koenig wrote:
BGB <cr88192@gmail.com> schrieb:
On 3/24/2026 8:37 PM, Stephen Fuld wrote:
On 3/24/2026 6:21 PM, MitchAlsup wrote:
Stephen Fuld <sfuld@alumni.cmu.edu.invalid> posted:
SPEC FP.
So, people, what would you recommend for BGB to use for FP
testing?
Is there a version of SPEC FP that is available for free? I get
the impression that BGB doesn't have a lot of money to spend on
such things.
Yeah, and not going to use a proprietary benchmark here...
You could use coremark, https://github.com/eembc/coremark ,
Whetstone https://www.netlib.org/benchmark/whetstone.c , Dhrystone https://homepages.cwi.nl/~steven/dry.c or embench https://github.com/embench/embench-iot .
Thank you Thomas. I hoped someone (and I suspected you :-)) would
respond.
BGB <cr88192@gmail.com> schrieb:
On 3/24/2026 8:37 PM, Stephen Fuld wrote:
On 3/24/2026 6:21 PM, MitchAlsup wrote:
Stephen Fuld <sfuld@alumni.cmu.edu.invalid> posted:
SPEC FP.
So, people, what would you recommend for BGB to use for FP testing?
Is there a version of SPEC FP that is available for free? I get the
impression that BGB doesn't have a lot of money to spend on such things. >>>
Yeah, and not going to use a proprietary benchmark here...
You could use coremark, https://github.com/eembc/coremark , Whetstone https://www.netlib.org/benchmark/whetstone.c , Dhrystone https://homepages.cwi.nl/~steven/dry.c or embench https://github.com/embench/embench-iot .
On Wed, 25 Mar 2026 13:59:02 -0700
Stephen Fuld <sfuld@alumni.cmu.edu.invalid> wrote:
On 3/25/2026 11:31 AM, Thomas Koenig wrote:
BGB <cr88192@gmail.com> schrieb:
On 3/24/2026 8:37 PM, Stephen Fuld wrote:
On 3/24/2026 6:21 PM, MitchAlsup wrote:
Stephen Fuld <sfuld@alumni.cmu.edu.invalid> posted:
SPEC FP.
So, people, what would you recommend for BGB to use for FP
testing?
Is there a version of SPEC FP that is available for free? I get
the impression that BGB doesn't have a lot of money to spend on
such things.
Yeah, and not going to use a proprietary benchmark here...
You could use coremark, https://github.com/eembc/coremark ,
Whetstone https://www.netlib.org/benchmark/whetstone.c , Dhrystone
https://homepages.cwi.nl/~steven/dry.c or embench
https://github.com/embench/embench-iot .
Thank you Thomas. I hoped someone (and I suspected you :-)) would
respond.
My response is: those are toy benchmarks. Even 37 years ago people
already recognize them as toys. That's why SPEC was so successful
when they published their first suite in 1989.
Anton Ertl <anton@mips.complang.tuwien.ac.at> schrieb:
Thomas Koenig <tkoenig@netcologne.de> writes:
quadi <quadibloc@ca.invalid> schrieb:
On Sun, 22 Mar 2026 03:28:36 +0200, Michael S wrote:
POWER tries to minimize software licensing expenses.
Including by playing dirty game of calling something that for most
practical purposes is a dual-core or quad-core cluster "a core".
I'm a bit puzzled. Why would IBM design their PowerPC chips so as to cheat >>>> themselves?
If (non-IBM) software is paid for per core by IBM's customers, then
the IBM customer has an advantage, which is a possible motivation
to buy IBM hardware, if software license costs dominate.
Why would an ISV pay the cost of the Power port and then charge less
for the license on a similar-capacity machine.
Finally, I came up with a solution. The new header type is 64 bits long.
That distributes the overhead bits between two instructions, so now both
of the instructions embedded in the header can be either a register-to- register operate instruction, or a restricted memory-reference
instruction.
However, the opcode space I used for that new header type turned out to
be already in use for 15-bit short instructions. However, I was able to
fix this problem, and doing so was considerably easier than I had
feared.
It is based on the assumption that System i (if that is this week's name
for AS/400) has enough margin to pay for Power development, while
RS/6000 (whatever its current name is) competes head-on with Intel and
AMD servers in the Linux and pretty much also in the AIX markets. My
guess is that IBM charges very little or nothing of Power development to RS/6000, but while it is available thanks to System i, they sell it;
even if they made no profits on that, one benefit would be the marketing aspect of supporting the architecture that long, longer than all the competitors from the 1990s).
I have no numbers to support my guesses, but the fact that Power is
still there while everything else including SPARC has been cancelled
makes me doubt that the AIX and Linux business are keeping Power alive.
On Wed, 25 Mar 2026 13:59:02 -0700
Stephen Fuld <sfuld@alumni.cmu.edu.invalid> wrote:
On 3/25/2026 11:31 AM, Thomas Koenig wrote:
BGB <cr88192@gmail.com> schrieb:
On 3/24/2026 8:37 PM, Stephen Fuld wrote:
On 3/24/2026 6:21 PM, MitchAlsup wrote:
Stephen Fuld <sfuld@alumni.cmu.edu.invalid> posted:
SPEC FP.
So, people, what would you recommend for BGB to use for FP
testing?
Is there a version of SPEC FP that is available for free? I get
the impression that BGB doesn't have a lot of money to spend on
such things.
Yeah, and not going to use a proprietary benchmark here...
You could use coremark, https://github.com/eembc/coremark ,
Whetstone https://www.netlib.org/benchmark/whetstone.c , Dhrystone
https://homepages.cwi.nl/~steven/dry.c or embench
https://github.com/embench/embench-iot .
Thank you Thomas. I hoped someone (and I suspected you :-)) would
respond.
My response is: those are toy benchmarks. Even 37 years ago people
already recognize them as toys.
That's why SPEC was so successful
when they published their first suite in 1989.
Anton Ertl <anton@mips.complang.tuwien.ac.at> schrieb:
Why would an ISV pay the cost of the Power port and then charge less
for the license on a similar-capacity machine.
They pay per core. If the core happens to have 8-way multithreading
and has more performance because of that - well, that's what hardware
vendors have to deal with.
Michael S <already5chosen@yahoo.com> schrieb:
On Wed, 25 Mar 2026 13:59:02 -0700
Stephen Fuld <sfuld@alumni.cmu.edu.invalid> wrote:
On 3/25/2026 11:31 AM, Thomas Koenig wrote:
BGB <cr88192@gmail.com> schrieb:
On 3/24/2026 8:37 PM, Stephen Fuld wrote:
On 3/24/2026 6:21 PM, MitchAlsup wrote:
Stephen Fuld <sfuld@alumni.cmu.edu.invalid> posted:
SPEC FP.
So, people, what would you recommend for BGB to use for FP
testing?
Is there a version of SPEC FP that is available for free? I
get the impression that BGB doesn't have a lot of money to
spend on such things.
Yeah, and not going to use a proprietary benchmark here...
You could use coremark, https://github.com/eembc/coremark ,
Whetstone https://www.netlib.org/benchmark/whetstone.c ,
Dhrystone https://homepages.cwi.nl/~steven/dry.c or embench
https://github.com/embench/embench-iot .
Thank you Thomas. I hoped someone (and I suspected you :-)) would
respond.
My response is: those are toy benchmarks. Even 37 years ago people
already recognize them as toys.
Coremark was initially developed in 2009 (17 years ago), embench
in 2019 (a bit less than seven years ago). If somebody recognized
them as toys 37 years ago, they had access to a time machine.
For Dhrystone and Whetstone - interesting for historical comparisonsYes. But they are not very expensive. Their Web site says:
and if/when the compiler does not optimize too aggresively. Since
BGB's compiler is hand-made, that should not matter too much
(no work by a single person can compete with the man-centuries
that go into a major compiler).
That's why SPEC was so successful
when they published their first suite in 1989.
I have two main gripes about SPEC: First, it is paywalled.
Second, they refuse to change sources or their verification
conditions even when the code is wrong, and depends (for example)
on re-ordering of an expression that compilers are allowed to do.
They would rather pessimize everybody else's code.
It is useful if run continuosly to catch regressions, especially
speed, see https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163 .
Thomas Koenig <tkoenig@netcologne.de> writes:
Anton Ertl <anton@mips.complang.tuwien.ac.at> schrieb:
Why would an ISV pay the cost of the Power port and then charge
less for the license on a similar-capacity machine.
They pay per core. If the core happens to have 8-way multithreading
and has more performance because of that - well, that's what hardware >vendors have to deal with.
That's not an answer to my question. The ISVs can charge on whatever
basis they want. They may charge per core, or per thread, or based on
some benchmark results they have on the hardware. Or they may just
save the cost of porting to Power, like John Dallman's company is
doing. So why would an ISV port to Power and then charge so much less
for the same capacity on Power that people pay the hardware premium
because it saves them in ISV licensing fees. Any ISV that does that
is the enemy of their own profits.
As for the claim that Power has more performance because of 8-way multithreading, I did a little experiment, all based on the latex
benchmark in <http://www.complang.tuwien.ac.at/anton/latex-bench/>.
I compared a Power10 machine and a Ryzen 8700G (Zen 4)
The value of CORE in the following command was 8-15 on the Power10 and
5,13 on the 8700G. Both signify the threads of one core.
Interestingly, it's hard to see on Linux-Power that the hardware has
fewer cores than threads and which threads belong to which core. I
finally found it out by measuring the slowdowns when assigning tasks
to "CPUs".
for i in 0 1 2 3 4 5 6 7; do (mkdir -p $i; cd $i; cp ../bench.tex ../types.bib .; latex bench >/dev/null; bibtex bench >/dev/null;
latex bench >/dev/null; taskset -c $CORE perf stat -r 100 latex bench >/dev/null 2>timing) & done; wait; cat */timing
This runs 8 single-threaded tasks, each a 100 times (for averaging out
timing variations), on a single core (if CORE is set correctly).
On the Power 10 I see:
grep -h elapsed */timing|sort -n
1.307213 +- 0.000873 seconds time elapsed ( +- 0.07% )
1.30727 +- 0.00111 seconds time elapsed ( +- 0.08% )
1.308162 +- 0.000841 seconds time elapsed ( +- 0.06% )
1.308368 +- 0.000781 seconds time elapsed ( +- 0.06% )
1.31040 +- 0.00223 seconds time elapsed ( +- 0.17% )
1.31081 +- 0.00308 seconds time elapsed ( +- 0.23% )
1.31085 +- 0.00219 seconds time elapsed ( +- 0.17% )
1.31112 +- 0.00324 seconds time elapsed ( +- 0.25% )
On the Ryzen 8700G I see:
1.69460 +- 0.00313 seconds time elapsed ( +- 0.18% )
1.69974 +- 0.00264 seconds time elapsed ( +- 0.16% )
1.69979 +- 0.00302 seconds time elapsed ( +- 0.18% )
1.70200 +- 0.00426 seconds time elapsed ( +- 0.25% )
1.70213 +- 0.00565 seconds time elapsed ( +- 0.33% )
1.70286 +- 0.00599 seconds time elapsed ( +- 0.35% )
1.70381 +- 0.00636 seconds time elapsed ( +- 0.37% )
1.7049 +- 0.0109 seconds time elapsed ( +- 0.64% )
So the Power 10 looks faster in this setting indeed than the 8700G.
There is one caveat: This latex benchmark is somewhat sensitive to how
many LaTeX packages are installed on the system. I tried to estimate
this with
strace -e trace=file latex bench 2>&1 >/dev/null |wc -l
This gave me 1025 on the Power 10 machine and 1255 on the 8700G, so
the 8700G apparently has to search through more packages, but it's not
clear how much this affects the run-time. Probably not the factor 1.3
in speed difference.
Let's see how the machines fare with only a single thread (same script
as above, but without 1 2 3 4 5 6 7):
Power 10: 0.475022 +- 0.000204 seconds time elapsed ( +- 0.04% )
Ryzen 8700G: 0.270851 +- 0.000569 seconds time elapsed ( +- 0.21% )
So here the 8700G clearly wins.
What about two threads?
Power 10:
0.475873 +- 0.000257 seconds time elapsed ( +- 0.05% )
0.475875 +- 0.000265 seconds time elapsed ( +- 0.06% )
No slowdown from SMT? Strange. I was wondering if maybe there were
two cores in the set 8-15, but when trying 8-9, the result is similar,
so unless the core numbering is strange for 8-9, but straightforward
for 8-15, Power 10 has a slow start, but the scales well with more
threads.
Ryzen 8700G:
0.399935 +- 0.000251 seconds time elapsed ( +- 0.06% )
0.400696 +- 0.000637 seconds time elapsed ( +- 0.16% )
By contrast, the 8700G suffers measurably from the second thread, but
two threads on the same core on the 8700G are still faster then two
threads on Power 10.
- anton
I have no numbers to support my guesses, but the fact that Power is
still there while everything else including SPARC has been cancelled
makes me doubt that the AIX and Linux business are keeping Power alive.
I am certainly in full agreement with your analysis.
For the moment, System z has not yet gone the way of the Unisys
mainframes, and so it isn't made as software running on PowerPC
hardware... but that day may yet come.
On Sun, 22 Mar 2026 08:31:25 +0000, Anton Ertl wrote:
It is based on the assumption that System i (if that is this week's name
for AS/400) has enough margin to pay for Power development, while
RS/6000 (whatever its current name is) competes head-on with Intel and
AMD servers in the Linux and pretty much also in the AIX markets. My
guess is that IBM charges very little or nothing of Power development to
RS/6000, but while it is available thanks to System i, they sell it;
even if they made no profits on that, one benefit would be the marketing
aspect of supporting the architecture that long, longer than all the
competitors from the 1990s).
I have no numbers to support my guesses, but the fact that Power is
still there while everything else including SPARC has been cancelled
makes me doubt that the AIX and Linux business are keeping Power alive.
I am certainly in full agreement with your analysis.
For the moment, System z has not yet gone the way of the Unisys
mainframes, and so it isn't made as software running on PowerPC
hardware... but that day may yet come.
One feature which I find fascinating is that they record a
checkpoint of the CPU architectural state at each cycle so they
can transparently move and move and restart processes (their
R-unit, if you want to google it).
I don't think anybody else does that.
In SAP-SD bnchmark 240-core POWER10 scored 285,030
For comparison, 384-core EPYC 9965 scored 266,100
So, 1.73x higher per-core scores for POWER10.
And this particular SAP benchmark is close to embarassingly purrallel.
In less easy benchmarks, like TPC-C, per core advantage of POWER10 is
likely higher, but nowadays nobody submits TPC-C results.
And this particular SAP benchmark is close to embarassingly^^^^^^^^^
purrallel.
As for the claim that Power has more performance because of 8-way >multithreading, I did a little experiment, all based on the latex
benchmark in <http://www.complang.tuwien.ac.at/anton/latex-bench/>. I compared a Power10 machine and a Ryzen 8700G (Zen 4)
The value of CORE in the following command was 8-15 on the Power10 and
5,13 on the 8700G. Both signify the threads of one core.
There is one caveat: This latex benchmark is somewhat sensitive to how
many LaTeX packages are installed on the system. I tried to estimate
this with
strace -e trace=file latex bench 2>&1 >/dev/null |wc -l
This gave me 1025 on the Power 10 machine and 1255 on the 8700G,
Yes. But they are not very expensive. Their Web site says:
"The SPEC CPU 2017 Benchmark price is $1000 for new customers, $250 for qualified non profit organizations and $50 accredited academic
institutions."
The ISVs can charge on whatever basis they want. They may charge
per core, or per thread, or based on some benchmark results they
have on the hardware. Or they may just save the cost of porting
to Power, like John Dallman's company is doing.
AFAIK AIX has continued to be big-endian, only Linux switched.
Thomas Koenig <tkoenig@netcologne.de> writes:
One feature which I find fascinating is that they record a
checkpoint of the CPU architectural state at each cycle so they
can transparently move and move and restart processes (their
R-unit, if you want to google it).
I don't think anybody else does that.
Every modern OoO architecture checkpoints the CPU architectural state
at every branch and every potentially-trapping instruction, possibly
more than once per cycle. However, checkpointing the remainder of the process's state and using all of that to move the process is another
issue. VMs tend to feature the ability to save and move their guests;
I don't know what they use for that, what the granularity is and why
one would want to do that on a per-cycle basis, though.
- anton
On Sun, 22 Mar 2026 08:49:43 +0000, Anton Ertl wrote:
AFAIK AIX has continued to be big-endian, only Linux switched.
Huh? I thought Linux was of course little-endian on x86... and
big-endian on big-endian hardware. Of course, by now it may have
dropped support for all big-endian architectures.
As for POWER, I wasn't aware that it gained the option of running
in a little-endian mode, but it's certainly possible they followed
the lead of ARM in becoming endian-agnostic.
On Fri, 27 Mar 2026 03:32:07 +0300, Michael S wrote:
Yes. But they are not very expensive. Their Web site says:
"The SPEC CPU 2017 Benchmark price is $1000 for new customers, $250
for qualified non profit organizations and $50 accredited academic institutions."
I would agree that $50 is not very expensive, but I would not say the
same for $1,000. Unless you have reason to believe that the poster
with the project under discussion is a student, therefore, I am
puzzled.
John Savard
On 2026-03-27 2:50, Michael S wrote:
And this particular SAP benchmark is close to embarassingly^^^^^^^^^
purrallel.
Hm... something to do with herding multiple cats, purrhaps?
In article <10q5ucb$3nqnp$2@dont-email.me>, quadibloc@ca.invalid (quadi) wrote:
On Sun, 22 Mar 2026 08:49:43 +0000, Anton Ertl wrote:
AFAIK AIX has continued to be big-endian, only Linux switched.
Huh? I thought Linux was of course little-endian on x86... and
big-endian on big-endian hardware. Of course, by now it may have
dropped support for all big-endian architectures.
It has not. It still supports MC68000 and IVM Z.
Michael S <already5chosen@yahoo.com> schrieb:
On Wed, 25 Mar 2026 13:59:02 -0700
Stephen Fuld <sfuld@alumni.cmu.edu.invalid> wrote:
On 3/25/2026 11:31 AM, Thomas Koenig wrote:
BGB <cr88192@gmail.com> schrieb:
On 3/24/2026 8:37 PM, Stephen Fuld wrote:
On 3/24/2026 6:21 PM, MitchAlsup wrote:
Stephen Fuld <sfuld@alumni.cmu.edu.invalid> posted:
SPEC FP.
So, people, what would you recommend for BGB to use for FP
testing?
Is there a version of SPEC FP that is available for free? I get
the impression that BGB doesn't have a lot of money to spend on
such things.
Yeah, and not going to use a proprietary benchmark here...
You could use coremark, https://github.com/eembc/coremark ,
Whetstone https://www.netlib.org/benchmark/whetstone.c , Dhrystone
https://homepages.cwi.nl/~steven/dry.c or embench
https://github.com/embench/embench-iot .
Thank you Thomas. I hoped someone (and I suspected you :-)) would
respond.
My response is: those are toy benchmarks. Even 37 years ago people
already recognize them as toys.
Coremark was initially developed in 2009 (17 years ago), embench
in 2019 (a bit less than seven years ago). If somebody recognized
them as toys 37 years ago, they had access to a time machine.
For Dhrystone and Whetstone - interesting for historical comparisons
and if/when the compiler does not optimize too aggresively.
Since
BGB's compiler is hand-made, that should not matter too much
(no work by a single person can compete with the man-centuries
that go into a major compiler).
That's why SPEC was so successful
when they published their first suite in 1989.
I have two main gripes about SPEC: First, it is paywalled.
Second, they refuse to change sources or their verification
conditions even when the code is wrong, and depends (for example)
on re-ordering of an expression that compilers are allowed to do.
They would rather pessimize everybody else's code.
It is useful if run continuosly to catch regressions, especially
speed, see https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163 .
quadi <quadibloc@ca.invalid> schrieb:
On Sun, 22 Mar 2026 08:31:25 +0000, Anton Ertl wrote:
It is based on the assumption that System i (if that is this week's name >> for AS/400) has enough margin to pay for Power development, while
RS/6000 (whatever its current name is) competes head-on with Intel and
AMD servers in the Linux and pretty much also in the AIX markets. My
guess is that IBM charges very little or nothing of Power development to >> RS/6000, but while it is available thanks to System i, they sell it;
even if they made no profits on that, one benefit would be the marketing >> aspect of supporting the architecture that long, longer than all the
competitors from the 1990s).
I have no numbers to support my guesses, but the fact that Power is
still there while everything else including SPARC has been cancelled
makes me doubt that the AIX and Linux business are keeping Power alive.
I am certainly in full agreement with your analysis.
For the moment, System z has not yet gone the way of the Unisys mainframes, and so it isn't made as software running on PowerPC hardware... but that day may yet come.
See the upthread numbers from the IBM annual report I posted -
the combination of IBM Z and Power has very nice margins.
One feature which I find fascinating is that they record a
checkpoint of the CPU architectural state at each cycle so they
can transparently move and move and restart processes (their
R-unit, if you want to google it).
I don't think anybody else does that.
On 2026-03-27 2:50, Michael S wrote:
And this particular SAP benchmark is close to embarassingly^^^^^^^^^
purrallel.
Hm... something to do with herding multiple cats, purrhaps?
On Fri, 27 Mar 2026 03:32:07 +0300, Michael S wrote:
Yes. But they are not very expensive. Their Web site says:
"The SPEC CPU 2017 Benchmark price is $1000 for new customers, $250 for qualified non profit organizations and $50 accredited academic institutions."
I would agree that $50 is not very expensive, but I would not say the same for $1,000. Unless you have reason to believe that the poster with the project under discussion is a student, therefore, I am puzzled.--- Synchronet 3.21f-Linux NewsLink 1.2
John Savard
On Sun, 22 Mar 2026 08:49:43 +0000, Anton Ertl wrote:
AFAIK AIX has continued to be big-endian, only Linux switched.
Huh? I thought Linux was of course little-endian on x86... and big-endian
on big-endian hardware. Of course, by now it may have dropped support for >all big-endian architectures.
As for POWER, I wasn't aware that it gained the option of running in a >little-endian mode, but it's certainly possible they followed the lead of >ARM in becoming endian-agnostic.
Michael S <already5chosen@yahoo.com> schrieb:
On Wed, 25 Mar 2026 13:59:02 -0700
Stephen Fuld <sfuld@alumni.cmu.edu.invalid> wrote:
On 3/25/2026 11:31 AM, Thomas Koenig wrote:
BGB <cr88192@gmail.com> schrieb:
On 3/24/2026 8:37 PM, Stephen Fuld wrote:
On 3/24/2026 6:21 PM, MitchAlsup wrote:
Stephen Fuld <sfuld@alumni.cmu.edu.invalid> posted:
SPEC FP.
So, people, what would you recommend for BGB to use for FP
testing?
Is there a version of SPEC FP that is available for free? I get
the impression that BGB doesn't have a lot of money to spend on
such things.
Yeah, and not going to use a proprietary benchmark here...
You could use coremark, https://github.com/eembc/coremark ,
Whetstone https://www.netlib.org/benchmark/whetstone.c , Dhrystone
https://homepages.cwi.nl/~steven/dry.c or embench
https://github.com/embench/embench-iot .
Thank you Thomas. I hoped someone (and I suspected you :-)) would
respond.
My response is: those are toy benchmarks. Even 37 years ago people
already recognize them as toys.
Coremark was initially developed in 2009 (17 years ago), embench
in 2019 (a bit less than seven years ago). If somebody recognized
them as toys 37 years ago, they had access to a time machine.
For Dhrystone and Whetstone - interesting for historical comparisons
and if/when the compiler does not optimize too aggresively. Since
BGB's compiler is hand-made, that should not matter too much
(no work by a single person can compete with the man-centuries
that go into a major compiler).
That's why SPEC was so successful
when they published their first suite in 1989.
I have two main gripes about SPEC: First, it is paywalled.
Second, they refuse to change sources or their verification
conditions even when the code is wrong, and depends (for example)
on re-ordering of an expression that compilers are allowed to do.
They would rather pessimize everybody else's code.
It is useful if run continuosly to catch regressions, especially
speed, see https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163 .
quadi <quadibloc@ca.invalid> posted:
On Fri, 27 Mar 2026 03:32:07 +0300, Michael S wrote:
Yes. But they are not very expensive. Their Web site says:
"The SPEC CPU 2017 Benchmark price is $1000 for new customers, $250 for
qualified non profit organizations and $50 accredited academic
institutions."
What about someone (me) just screwing around that has nothing to do with academia, not necessarily non-profit, nor industrial or commercial.
I would agree that $50 is not very expensive, but I would not say the same >> for $1,000. Unless you have reason to believe that the poster with the
project under discussion is a student, therefore, I am puzzled.
John Savard
On Thu, 26 Mar 2026 20:29:47 -0000 (UTC)
Thomas Koenig <tkoenig@netcologne.de> wrote:
Michael S <already5chosen@yahoo.com> schrieb:
On Wed, 25 Mar 2026 13:59:02 -0700
Stephen Fuld <sfuld@alumni.cmu.edu.invalid> wrote:
On 3/25/2026 11:31 AM, Thomas Koenig wrote:
You could use coremark, https://github.com/eembc/coremark ,
Whetstone https://www.netlib.org/benchmark/whetstone.c ,
Dhrystone https://homepages.cwi.nl/~steven/dry.c or embench
https://github.com/embench/embench-iot .
Thank you Thomas. I hoped someone (and I suspected you :-)) would
respond.
My response is: those are toy benchmarks. Even 37 years ago people
already recognize them as toys.
Coremark was initially developed in 2009 (17 years ago), embench
in 2019 (a bit less than seven years ago). If somebody recognized
them as toys 37 years ago, they had access to a time machine.
I was talking about Dhrystone and Whetstone.
Coremarks and embench were never intended to measure performance of Server/Workstation/PC class of computers.
Since ~2015 we can add
smartphones to the list of machines that this marks are not intended to evaluate.
For Dhrystone and Whetstone - interesting for historical comparisons
and if/when the compiler does not optimize too aggresively. Since
BGB's compiler is hand-made, that should not matter too much
(no work by a single person can compete with the man-centuries
that go into a major compiler).
That's why SPEC was so successful
when they published their first suite in 1989.
I have two main gripes about SPEC: First, it is paywalled.
Yes. But they are not very expensive. Their Web site says:
"The SPEC CPU 2017 Benchmark price is $1000 for new customers, $250 for qualified non profit organizations and $50 accredited academic
institutions."
Thomas Koenig <tkoenig@netcologne.de> posted:
quadi <quadibloc@ca.invalid> schrieb:
On Sun, 22 Mar 2026 08:31:25 +0000, Anton Ertl wrote:
It is based on the assumption that System i (if that is this week's name >> >> for AS/400) has enough margin to pay for Power development, whileI am certainly in full agreement with your analysis.
RS/6000 (whatever its current name is) competes head-on with Intel and
AMD servers in the Linux and pretty much also in the AIX markets. My
guess is that IBM charges very little or nothing of Power development to >> >> RS/6000, but while it is available thanks to System i, they sell it;
even if they made no profits on that, one benefit would be the marketing >> >> aspect of supporting the architecture that long, longer than all the
competitors from the 1990s).
I have no numbers to support my guesses, but the fact that Power is
still there while everything else including SPARC has been cancelled
makes me doubt that the AIX and Linux business are keeping Power alive. >> >
For the moment, System z has not yet gone the way of the Unisys
mainframes, and so it isn't made as software running on PowerPC
hardware... but that day may yet come.
See the upthread numbers from the IBM annual report I posted -
the combination of IBM Z and Power has very nice margins.
One feature which I find fascinating is that they record a
checkpoint of the CPU architectural state at each cycle so they
can transparently move and move and restart processes (their
R-unit, if you want to google it).
While everybody else just checkpoints every cycle for branch
prediction recovery.
Michael S <already5chosen@yahoo.com> schrieb:
On Thu, 26 Mar 2026 20:29:47 -0000 (UTC)
Thomas Koenig <tkoenig@netcologne.de> wrote:
Michael S <already5chosen@yahoo.com> schrieb:
On Wed, 25 Mar 2026 13:59:02 -0700
Stephen Fuld <sfuld@alumni.cmu.edu.invalid> wrote:
On 3/25/2026 11:31 AM, Thomas Koenig wrote:
You could use coremark, https://github.com/eembc/coremark ,
Whetstone https://www.netlib.org/benchmark/whetstone.c ,
Dhrystone https://homepages.cwi.nl/~steven/dry.c or embench
https://github.com/embench/embench-iot .
Thank you Thomas. I hoped someone (and I suspected you :-)) would
respond.
My response is: those are toy benchmarks. Even 37 years ago people
already recognize them as toys.
Coremark was initially developed in 2009 (17 years ago), embench
in 2019 (a bit less than seven years ago). If somebody recognized
them as toys 37 years ago, they had access to a time machine.
I was talking about Dhrystone and Whetstone.
Coremarks and embench were never intended to measure performance of
Server/Workstation/PC class of computers.
Does that mean that they are useless to run on these computers,
and that no information can be gained from them?
Also, it is not really clear if BGB's machine falls into server/workstation/PC class.
Since ~2015 we can add
smartphones to the list of machines that this marks are not intended to
evaluate.
For Dhrystone and Whetstone - interesting for historical comparisons
and if/when the compiler does not optimize too aggresively. Since
BGB's compiler is hand-made, that should not matter too much
(no work by a single person can compete with the man-centuries
that go into a major compiler).
That's why SPEC was so successful
when they published their first suite in 1989.
I have two main gripes about SPEC: First, it is paywalled.
Yes. But they are not very expensive. Their Web site says:
"The SPEC CPU 2017 Benchmark price is $1000 for new customers, $250 for
qualified non profit organizations and $50 accredited academic
institutions."
So it would be 1000 Dollars for a volunteer co-developer of a
compiler, like me. Thanks, but no thanks - I draw the line
somewhere.
On 3/27/2026 4:38 PM, Thomas Koenig wrote:
Michael S <already5chosen@yahoo.com> schrieb:
On Thu, 26 Mar 2026 20:29:47 -0000 (UTC)
Thomas Koenig <tkoenig@netcologne.de> wrote:
Michael S <already5chosen@yahoo.com> schrieb:
On Wed, 25 Mar 2026 13:59:02 -0700
Stephen Fuld <sfuld@alumni.cmu.edu.invalid> wrote:
On 3/25/2026 11:31 AM, Thomas Koenig wrote:
You could use coremark, https://github.com/eembc/coremark ,
Whetstone https://www.netlib.org/benchmark/whetstone.c ,
Dhrystone https://homepages.cwi.nl/~steven/dry.c or embench
https://github.com/embench/embench-iot .
Thank you Thomas. I hoped someone (and I suspected you :-)) would >>>>>> respond.
My response is: those are toy benchmarks. Even 37 years ago people
already recognize them as toys.
Coremark was initially developed in 2009 (17 years ago), embench
in 2019 (a bit less than seven years ago). If somebody recognized
them as toys 37 years ago, they had access to a time machine.
I was talking about Dhrystone and Whetstone.
Coremarks and embench were never intended to measure performance of
Server/Workstation/PC class of computers.
Does that mean that they are useless to run on these computers,
and that no information can be gained from them?
Also, it is not really clear if BGB's machine falls into
server/workstation/PC class.
Probably, the ISA could be used in theory on PC/workstation, but as-is, probably no...
If it even saw use in mobile, this would probably be a big step up.
If anything, it could make more sense for embedded and DSP.
If I were to place bets, probably:
Servers move to ARM;
PC's follow maybe a short time later;
Mobile then starts moving to RISC-V or similar;
Probably followed by server and PCs.
Likely with less inertia for ARM to RISC-V, as an x86-64 to ARM
transition would have already greatly reduced the friction (particularly
if Microsoft dies off as a major player in the OS space, and RISC-V addresses some of its remaining shortcomings). The likely motivation for
the move is that if ARM gains top position, they might become
increasingly draconian and effectively drive everyone away (with RISC-V remaining as the "we don't need to answer to anyone" option).
But, in the nearer term, x86-64 becomes easier to emulate but also less attractive to run on real hardware, as if Moore's Law ends, this may
well shift power balances some and cause x86-64 to become a less
attractive option (cores will need more power and area relative to computational power).
Though, in-order vs OoO is a little closer it seems (more area and more power, but also, better performance per watt). But, then again, if one
were clearly better in all regards, it would have won already, vs the current split:
OoO for higher-performance higher-power-use devices;
In-order for lower performance, lower-power devices.
So, in much the same way, in-order doesn't currently hold in the server space, much as OoO can't capture the budget smartphone market.
But, in the present, will anyone likely do much serious work with an
FPGA based soft processor; Not really.
But, we may be looking at a different situation in 2050.
Though, early 2030s may see the rise of ARM in the PC space.
Well, alongside a lot of older x86-64 PCs being kept alive...
Probably also not going to be much around in terms of money or jobs for
most people (just whatever they can get, and basic survival). Say, with whole "economy" thing going totally to crap (far worse than it is already).
Well, and then say someone comes along flogging off post-scarcity
economics via bowing down to an AI overlord, and UBI and such, but then
it doesn't work and everything still goes totally to crap (as they
didn't really fix anything, and the underlying system is still broken), ...
...
But, such situations could shift the balances of power in the CPU space.
Granted, different possibilities could emerge, say if:
Moore's law doesn't end;
Economy doesn't mostly collapse;
...
Since ~2015 we can add
smartphones to the list of machines that this marks are not intended to
evaluate.
For Dhrystone and Whetstone - interesting for historical comparisons
and if/when the compiler does not optimize too aggresively. Since
BGB's compiler is hand-made, that should not matter too much
(no work by a single person can compete with the man-centuries
that go into a major compiler).
That's why SPEC was so successful
when they published their first suite in 1989.
I have two main gripes about SPEC: First, it is paywalled.
Yes. But they are not very expensive. Their Web site says:
"The SPEC CPU 2017 Benchmark price is $1000 for new customers, $250 for
qualified non profit organizations and $50 accredited academic
institutions."
So it would be 1000 Dollars for a volunteer co-developer of a
compiler, like me. Thanks, but no thanks - I draw the line
somewhere.
Yeah, if I had that much money to burn on stuff like this, could
probably get a "Nexys Video" board or similar, would probably get more
use out of this than I would get out of SPEC...
But, alas, it may not matter.
I can't do much, mostly just experiment with stuff, and hope it matters
to someone with more resources to realize it as "something actually
useful".
...
Thomas Koenig <tkoenig@netcologne.de> posted:
For Dhrystone and Whetstone - interesting for historical comparisons
and if/when the compiler does not optimize too aggresively.
To a certain extent, Whetstone is responsible for getting rid of
interpreters and requiring compilers.
Since
BGB's compiler is hand-made, that should not matter too much
(no work by a single person can compete with the man-centuries
that go into a major compiler).
That's why SPEC was so successful
when they published their first suite in 1989.
I have two main gripes about SPEC: First, it is paywalled.
In my opinion, SPEC should unpaywall all source not within 2 generations/releases of present.
Second, they refuse to change sources or their verification
conditions even when the code is wrong, and depends (for example)
on re-ordering of an expression that compilers are allowed to do.
To change wrong previous source would change everyone's results--
including those no longer around--diminishing historical utility.
On 2026-03-27 9:59 p.m., BGB wrote:
On 3/27/2026 4:38 PM, Thomas Koenig wrote:I do not dare to do trend analysis. But I think OoO machines will make
Michael S <already5chosen@yahoo.com> schrieb:
On Thu, 26 Mar 2026 20:29:47 -0000 (UTC)
Thomas Koenig <tkoenig@netcologne.de> wrote:
Michael S <already5chosen@yahoo.com> schrieb:
On Wed, 25 Mar 2026 13:59:02 -0700
Stephen Fuld <sfuld@alumni.cmu.edu.invalid> wrote:
On 3/25/2026 11:31 AM, Thomas Koenig wrote:
You could use coremark, https://github.com/eembc/coremark ,
Whetstone https://www.netlib.org/benchmark/whetstone.c ,
Dhrystone https://homepages.cwi.nl/~steven/dry.c or embench
https://github.com/embench/embench-iot .
Thank you Thomas. I hoped someone (and I suspected you :-)) would >>>>>>> respond.
My response is: those are toy benchmarks. Even 37 years ago people >>>>>> already recognize them as toys.
Coremark was initially developed in 2009 (17 years ago), embench
in 2019 (a bit less than seven years ago). If somebody recognized
them as toys 37 years ago, they had access to a time machine.
I was talking about Dhrystone and Whetstone.
Coremarks and embench were never intended to measure performance of
Server/Workstation/PC class of computers.
Does that mean that they are useless to run on these computers,
and that no information can be gained from them?
Also, it is not really clear if BGB's machine falls into
server/workstation/PC class.
Probably, the ISA could be used in theory on PC/workstation, but as-
is, probably no...
If it even saw use in mobile, this would probably be a big step up.
If anything, it could make more sense for embedded and DSP.
If I were to place bets, probably:
Servers move to ARM;
PC's follow maybe a short time later;
Mobile then starts moving to RISC-V or similar;
Probably followed by server and PCs.
Likely with less inertia for ARM to RISC-V, as an x86-64 to ARM
transition would have already greatly reduced the friction
(particularly if Microsoft dies off as a major player in the OS space,
and RISC-V addresses some of its remaining shortcomings). The likely
motivation for the move is that if ARM gains top position, they might
become increasingly draconian and effectively drive everyone away
(with RISC-V remaining as the "we don't need to answer to anyone"
option).
But, in the nearer term, x86-64 becomes easier to emulate but also
less attractive to run on real hardware, as if Moore's Law ends, this
may well shift power balances some and cause x86-64 to become a less
attractive option (cores will need more power and area relative to
computational power).
Though, in-order vs OoO is a little closer it seems (more area and
more power, but also, better performance per watt). But, then again,
if one were clearly better in all regards, it would have won already,
vs the current split:
OoO for higher-performance higher-power-use devices;
In-order for lower performance, lower-power devices.
So, in much the same way, in-order doesn't currently hold in the
server space, much as OoO can't capture the budget smartphone market.
But, in the present, will anyone likely do much serious work with an
FPGA based soft processor; Not really.
But, we may be looking at a different situation in 2050.
Though, early 2030s may see the rise of ARM in the PC space.
Well, alongside a lot of older x86-64 PCs being kept alive...
Probably also not going to be much around in terms of money or jobs
for most people (just whatever they can get, and basic survival). Say,
with whole "economy" thing going totally to crap (far worse than it is
already).
Well, and then say someone comes along flogging off post-scarcity
economics via bowing down to an AI overlord, and UBI and such, but
then it doesn't work and everything still goes totally to crap (as
they didn't really fix anything, and the underlying system is still
broken), ...
...
But, such situations could shift the balances of power in the CPU space.
Granted, different possibilities could emerge, say if:
Moore's law doesn't end;
Economy doesn't mostly collapse;
...
Since ~2015 we can add
smartphones to the list of machines that this marks are not intended to >>>> evaluate.
For Dhrystone and Whetstone - interesting for historical comparisons >>>>> and if/when the compiler does not optimize too aggresively. Since
BGB's compiler is hand-made, that should not matter too much
(no work by a single person can compete with the man-centuries
that go into a major compiler).
That's why SPEC was so successful
when they published their first suite in 1989.
I have two main gripes about SPEC: First, it is paywalled.
Yes. But they are not very expensive. Their Web site says:
"The SPEC CPU 2017 Benchmark price is $1000 for new customers, $250 for >>>> qualified non profit organizations and $50 accredited academic
institutions."
So it would be 1000 Dollars for a volunteer co-developer of a
compiler, like me. Thanks, but no thanks - I draw the line
somewhere.
Yeah, if I had that much money to burn on stuff like this, could
probably get a "Nexys Video" board or similar, would probably get more
use out of this than I would get out of SPEC...
But, alas, it may not matter.
I can't do much, mostly just experiment with stuff, and hope it
matters to someone with more resources to realize it as "something
actually useful".
...
it into more devices based on the simple demand for better performance
and lower power consumption. Also as the technology is better understood.
One never can tell exactly what the future holds, suddenly a bolt of lightning appears and there is a new contender on the block. Every generation seems to have a new CPU.
Not sure about the FPGA based soft-processor. The FPGA based processors
can reach into the hundreds of MHz now. They may gain in possible applications if they gain better performance and power characteristics.
I wonder if a local academic license for SPEC-CPU could be “borrowed” or rented. Seeing as it is only $50 for accredited academic institutions.
quadi <quadibloc@ca.invalid> posted:
On Fri, 27 Mar 2026 03:32:07 +0300, Michael S wrote:
Yes. But they are not very expensive. Their Web site says:
"The SPEC CPU 2017 Benchmark price is $1000 for new customers, $250 for
qualified non profit organizations and $50 accredited academic
institutions."
What about someone (me) just screwing around that has nothing to do with academia, not necessarily non-profit, nor industrial or commercial.
On 2026-03-27, MitchAlsup <user5857@newsgrouper.org.invalid> wrote:
quadi <quadibloc@ca.invalid> posted:
On Fri, 27 Mar 2026 03:32:07 +0300, Michael S wrote:
Yes. But they are not very expensive. Their Web site says:
"The SPEC CPU 2017 Benchmark price is $1000 for new customers, $250 for >>>> qualified non profit organizations and $50 accredited academic
institutions."
What about someone (me) just screwing around that has nothing to do with
academia, not necessarily non-profit, nor industrial or commercial.
No exception there.
Looking at
https://spec.org/order/index.html
they seem to have multiplied the number of benchmarks; for 1000 Dollars,
you would only get a single one of their CPU benchmarks. They have 38 current benchmarks for sale. Ordering all of them would set you back
94500 Dollars.
Sounds excessive if you ask me.
I wonder if a local academic license for SPEC-CPU could be “borrowed” or >rented. Seeing as it is only $50 for accredited academic institutions.
ERROR "unexpected byte sequence starting at index 102: '\xE2'" while decoding:
Robert Finch <robfi680@gmail.com> writes:
I wonder if a local academic license for SPEC-CPU could be âborrowedâ or
rented. Seeing as it is only $50 for accredited academic institutions.
I don't think they will have SPEC CPU at your local university
library, but I might be surprised.
Another approach would be for you to do a research project with a
university, then they could buy SPEC CPU for $50 as part of the
project, and you could use it.
Or you could just approach SPEC and tell them that you are a hobbyist,--- Synchronet 3.21f-Linux NewsLink 1.2
and if they have an appropriate price for that category (maybe with
the addition that you won't submit official results, which probably is
a large part of the cost that companies cause for SPEC).
- anton
As indicated above, it is most likely that they already have it; UNLESS
you are starting off a new CPU research program by <say> teaching
classes and running labs; in which case, $50 is incidental.
On Sat, 28 Mar 2026 20:47:47 +0000, MitchAlsup wrote:
As indicated above, it is most likely that they already have it; UNLESS
you are starting off a new CPU research program by <say> teaching
classes and running labs; in which case, $50 is incidental.
It may well be that BGB is, somehow, in a position to take advantage of
SPEC at a reasonable cost.
But, if he is not, there's Dhrystone, Whetstone, Coremark, and Embench, according to an earlier post. I'd advise to take advantage of those,
however inferior they may be, since that's something one can do without problems.
Later on, if the results are encouraging, opportunities might arise.
And then I saw an obvious tweak so that opcode space would be less fragmented.
Additional header types have been added, primarily to allow for a
security feature to control which instructions may be the target of a
branch.
It may well be that BGB is, somehow, in a position to take advantage of
SPEC at a reasonable cost.
But, if he is not, there's Dhrystone, Whetstone, Coremark, and Embench, according to an earlier post.
make your own benchmarks using some of the same applications they
use: many(most?) are Free Software.
On Fri, 20 Mar 2026 19:29:24 +0000, MitchAlsup wrote:
quadi <quadibloc@ca.invalid> posted:
On Thu, 19 Mar 2026 22:24:09 +0000, MitchAlsup wrote:
Even given all the snipped below text--unless you can get ISA
finished and get a compiler written, software ported and a
microarchitecture built--it is nothing but a mental exercise.
I can't argue with that; it is indisputable.
But I needed to get the basis right before proceeding with the hard
work.
20 years ago I had similar notions. But my experience with My 66000
changed my mind.
a) you have to have a compiler that can compile most things
so that you can see the deficiencies with your ISA
b) you have to have /bin/utils/ mostly compiled to see whatever
damage you have done to yourself in terms of external variables and
functions; SBI into and out of your OS; SBI' into and out of your
HyperVisor, ...
And after using these for a while, go back and correct the ISA.
If you fix ISA too soon you cut off much of your future.
It may well be that when I get to the point of porting Linux, I'll find my current design is a disaster.
On Tue, 31 Mar 2026 12:21:05 -0400, Stefan Monnier wrote:
make your own benchmarks using some of the same applications they
use: many(most?) are Free Software.
Since the application of SPEC is to compare different CPU architectures,
if it makes use of other applications in its testing, I suppose they would _have_ to be open-source programs... in order for it to be possible to compile them to run on the CPU architecture being benchmarked.
On 3/20/2026 9:44 PM, quadi wrote:
On Fri, 20 Mar 2026 19:29:24 +0000, MitchAlsup wrote:
quadi <quadibloc@ca.invalid> posted:
On Thu, 19 Mar 2026 22:24:09 +0000, MitchAlsup wrote:
Even given all the snipped below text--unless you can get ISA
finished and get a compiler written, software ported and a
microarchitecture built--it is nothing but a mental exercise.
I can't argue with that; it is indisputable.
But I needed to get the basis right before proceeding with the hard
work.
20 years ago I had similar notions. But my experience with My 66000
changed my mind.
a) you have to have a compiler that can compile most things
so that you can see the deficiencies with your ISA
b) you have to have /bin/utils/ mostly compiled to see whatever
damage you have done to yourself in terms of external variables and >>> functions; SBI into and out of your OS; SBI' into and out of your >>> HyperVisor, ...
And after using these for a while, go back and correct the ISA.
If you fix ISA too soon you cut off much of your future.
It may well be that when I get to the point of porting Linux, I'll
find my
current design is a disaster.
I think you are undervaluing Mitch's (and also BGB's) advice. Look at
it this way. Your plan is to wait until you port Linux to find any
flaws in your architecture.
But getting to that point is a lot of work, both in hardware design
(memory system - caches, paging, including TLBs etc, hardware reset, I/O capabilities - you need these to boot, etc.) and software (developing/ porting a compiler, compiling the C library, writing a BIOS, . . .).
However, note that developing a working compiler is a part of that "to
do" list. By doing that work, which you would have to do anyway,
earlier in the design process, there are three possible outcomes.
1. You find no problems and have developed the perfect architecture - possible, but with all due respect, not likely.
2. You find that it is, as you say, a disaster. This will save you a lot of time wasted in doing the other stuff above for a disaster architecture.
3. You find some things that could be improved, e.g. instructions
that the compiler never generates, common instruction sequences that
could be combined into a single, or a shorter sequence of, new instruction(s), etc.
If #1, you haven't wasted anything, as you would have to do the work anyway. If #2, you will have saved yourself a lot of otherwise wasted
time and effort. If #3, you will have improved your product with no
work that you wouldn't have had to do anyway.
I absolutely understand that developing/porting a compiler is a vastly different exercise than designing an ISA. And I also realize that you
seem to prefer rearranging the bits in the ISA to the other tasks. I apologize in advance for saying this, but I am reminded of rearranging
the deck chairs . . . :-( But if you are serious about trying to get something developed, it seems you should "adjust" you efforts.
And I also realize that you
seem to prefer rearranging the bits in the ISA to the other tasks.
So I wanted to create something that combined the advantages of CISC and RISC.
It's not exactly the full IBM System/360 programming experience, but it
comes as close as I can get.
b) CISC architectures have some advantages over RISC. For example,
on the IBM 360, a register-to-register operate instruction takes up
16 bits, while on a typical RISC architecture, it takes up 32 bits.
On Wed, 01 Apr 2026 07:58:24 -0700, Stephen Fuld wrote:
And I also realize that you
seem to prefer rearranging the bits in the ISA to the other tasks.
Aside from it being easier... until now, I've been very dissatisfied with
my attempts at a new, practical ISA. They just weren't really achieving
the goals I had set for myself.
The basic goal grew out of these observations:
a) these days, nearly all architectures are RISC architectures. Existing
CISC architectures are legacy architectures, kept around because a lot of software was written for them. And there are basically just two of them:
x86 and z/Architecture. 680x0 is kept alive by Amiga enthusiasts, but I
don't think that really counts.
b) CISC architectures have some advantages over RISC. For example, on the
IBM 360, a register-to-register operate instruction takes up 16 bits,
while on a typical RISC architecture, it takes up 32 bits.
So I wanted to create something that combined the advantages of CISC and RISC.
On Wed, 01 Apr 2026 07:58:24 -0700, Stephen Fuld wrote:
And I also realize that you
seem to prefer rearranging the bits in the ISA to the other tasks.
Aside from it being easier... until now, I've been very dissatisfied with
my attempts at a new, practical ISA. They just weren't really achieving
the goals I had set for myself.
The basic goal grew out of these observations:
a) these days, nearly all architectures are RISC architectures. Existing CISC architectures are legacy architectures, kept around because a lot of software was written for them. And there are basically just two of them:
x86 and z/Architecture. 680x0 is kept alive by Amiga enthusiasts, but I don't think that really counts.
b) CISC architectures have some advantages over RISC. For example, on the IBM 360, a register-to-register operate instruction takes up 16 bits,
while on a typical RISC architecture, it takes up 32 bits.
So I wanted to create something that combined the advantages of CISC and RISC.
Because I can only squeeze 16 possibilities into four bits, 256 possibilities into eight bits, 65,536 possibilities into sixteen bits, and so on, though, I kept having to compromise one part or another of my
design more severely than I could be content with. It's taken years to get where I am now.
John Savard--- Synchronet 3.21f-Linux NewsLink 1.2
In article <10qnenk$1lc5c$1@dont-email.me>, quadibloc@ca.invalid (quadi) wrote:
b) CISC architectures have some advantages over RISC. For example,
on the IBM 360, a register-to-register operate instruction takes up
16 bits, while on a typical RISC architecture, it takes up 32 bits.
I think you need to analyse the properties of what you're calling RISC
and CISC a bit more carefully.
For example, the core instruction set of the IBM 360 is practical to use
as a load-store architecture, whereas the x86 is not, because it has too
few registers. RISCs are invariably load-store.
Simple register-register operations will fit into 16-bit instructions, provided you have 16 or fewer general-purpose registers, and you'll
settle for two-operand instructions. Is that a good enough reason for limiting yourself to 16 registers? Quite a few designs have decided not,
but some have, such as SuperH, usually because they wanted very compact
code.
You also need to consider what kind of usage you're designing for. You
seem to be going for "general-purpose computing," meaning fast desktops
and servers compatible with them. That's a market where the ISA, at
present, controls what software you have readily available, and how
difficult the implementation is, but doesn't have a drastic effect on performance.
Performance is largely a question of the processor implementation and the cache and memory performance, not the ISA. ISAs can make things slower,
see Itanium, but they don't seem able to make things faster. At present.
You're trying to unify two styles of ISA, but neither style is really well-defined. You keep coming up with concepts that seem extremely complicated, whereas good engineering concepts are usually simple.
However, you are doing fairly well at enumerating the consequences of changes. You can use that as a research process.
To do that, you need to analyse your concepts more carefully and reduce
them to a number of simple requirements. See what comes from that. Then
try discarding some of them, one at a time, to see what changes.
John--- Synchronet 3.21f-Linux NewsLink 1.2
But given today's technology, that advantage of CISC has been overtaken
such that restricting yourself to 16 registers leads to more
instructions to do the work and thus worse performance.
jgd@cix.co.uk (John Dallman) posted:
In article <10qnenk$1lc5c$1@dont-email.me>, quadibloc@ca.invalid
(quadi) wrote:
b) CISC architectures have some advantages over RISC. For example, on
the IBM 360, a register-to-register operate instruction takes up 16
bits, while on a typical RISC architecture, it takes up 32 bits.
I think you need to analyse the properties of what you're calling RISC
and CISC a bit more carefully.
For example, the core instruction set of the IBM 360 is practical to
use as a load-store architecture, whereas the x86 is not, because it
has too few registers. RISCs are invariably load-store.
Simple register-register operations will fit into 16-bit instructions,
provided you have 16 or fewer general-purpose registers, and you'll
settle for two-operand instructions. Is that a good enough reason for
limiting yourself to 16 registers? Quite a few designs have decided
not, but some have, such as SuperH, usually because they wanted very
compact code.
You also need to consider what kind of usage you're designing for. You
seem to be going for "general-purpose computing," meaning fast desktops
and servers compatible with them. That's a market where the ISA, at
present, controls what software you have readily available, and how
difficult the implementation is, but doesn't have a drastic effect on
performance.
Performance is largely a question of the processor implementation and
the cache and memory performance, not the ISA. ISAs can make things
slower, see Itanium, but they don't seem able to make things faster. At
present.
One of the fascinating things I keep running into with My 66000 is that removing instructions does not, in any large way, shorten the critical
path through code--except in the case where LD instructions get
converted into constant operands leaving only a stream of calculation instructions.
You're trying to unify two styles of ISA, but neither style is really
well-defined. You keep coming up with concepts that seem extremely
complicated, whereas good engineering concepts are usually simple.
However, you are doing fairly well at enumerating the consequences of
changes. You can use that as a research process.
To do that, you need to analyse your concepts more carefully and reduce
them to a number of simple requirements. See what comes from that. Then
try discarding some of them, one at a time, to see what changes.
Well stated!
To do that, you need to analyse your concepts more carefully and
reduce them to a number of simple requirements. See what comes
from that. Then try discarding some of them, one at a time, to
see what changes.
Well stated!
This has happened again... I am about to update my web site to include a modification to Concertina II in order to more fully approach my goal of being able to do everything that either CISC or RISC does,
But I've thrown in the instructions the System/360 had that today's microprocessors tend not to have, so there's some database goodess.
I've thrown in vector instructions - not _only_ the common SIMD
type, but also ones similar to the ones of the Cray I. So
no-holds-barred speed-focused scientific computing is an
application area I've attempted to address.
And I have a header format that lets me predicate instructions and explicitly indicate parallelism. On top of that, I have
instructions that use banks of 128 registers instead of 32. That's
a hallmark of a VLIW instruction set, aimed at embedded systems
without enough transistors for OoO.
But your mention of how difficult it is to get into general-purpose computing, since Windows demands x86 and Android demands ARM to get
at each one's respective immense pool of software...
If the market dynamics of software availability promote consolidation
on a single ISA,
then that ISA really ought to... do everything and therefore satisfy everyone.
The ISA admits of different types of implementations. Subset
implementations are possible, and so are implementations that
perform a subset of the instructions efficiently, and throw the
rest to microcode.
The Itanium was definitely overcomplicated. Because of that, assembly-language programming for the Itanium would have been
daunting for most programmers.
But the Itanium design was _intended_ to make things faster. Lots
of registers. Explicit indication of when instructions can execute
in parallel. So one attains part of the advantage of OoO without
OoO and its complexity.
This was very attractive at the time: one of the iterations of the
Itanium was the first microprocessor to have over one billion
transistors. So if it already had an immense number of transistors,
but that wasn't enough for an OoO implementation - getting
performance any way you could makes sense.
I do believe that Ivan Godard, though, explained that the Itanium
did fail in achieving the performance goals it hoped for.
I include banks of 128 registers, and block headers that allow
instructions to be labelled as to whether or not they can be
executed in parallel, so my ISA allows for a non-OoO implementation
which uses those block types to achieve increased performance.
So by combining RISC, CISC, _and_ VLIW, I have produced the first
ISA for an "architecture-agnostic" computer, something it was not
imagined that could possibly exist. I do that, though, by only
making modest additions to an ordinary ISA, instead of having three completely independent instruction sets for a real waste of opcode
space.
Those features did not establish a continuing lineage in ISAs. Modern commodity microprocessors vastly outperform the Cray-1, and modern supercomputers are built out of them.
Is there a market for such processors? If so, what is currently failing
to meet the needs of that market?
That isn't as clear as you seem to think. Android exists for x86, and is
used for a few purposes that don't require running from battery power.
Windows exists for ARM, and is slowly gaining market share. It isn't mainstream yet, but nor has it failed, although Microsoft's early errors
in marketing it have not helped.
The meaningful difference between ARM and x86 in today's market is "how
much battery life do you need, and how large a battery can you fit in
the device?"
You have not, however, done any testing of the design, such as creating
a simulator or a compiler. Without that work, your design is very much conceptual, and of doubtful practicality.
In article <10qoprp$23e9$2@dont-email.me>, quadibloc@ca.invalid (quadi) wrote:
But I've thrown in the instructions the System/360 had that today's microprocessors tend not to have, so there's some database goodess.
You definitely ought to find out how much those instructions are used in today's descendants of System/360. While the 360 was a more carefully designed architecture than its predecessors, it was by no means perfect.
I've thrown in vector instructions - not _only_ the common SIMD
type, but also ones similar to the ones of the Cray I. So
no-holds-barred speed-focused scientific computing is an
application area I've attempted to address.
Those features did not establish a continuing lineage in ISAs. Modern commodity microprocessors vastly outperform the Cray-1, and modern supercomputers are built out of them.
Effective engineering involves _compromises_. By refusing to compromise
in favour of simplicity, you're ignoring decades of practical experience,
And I have a header format that lets me predicate instructions and explicitly indicate parallelism. On top of that, I have
instructions that use banks of 128 registers instead of 32. That's
a hallmark of a VLIW instruction set, aimed at embedded systems
without enough transistors for OoO.
Is there a market for such processors?
If so, what is currently failing
to meet the needs of that market?
But your mention of how difficult it is to get into general-purpose computing, since Windows demands x86 and Android demands ARM to get
at each one's respective immense pool of software...
That isn't as clear as you seem to think. Android exists for x86, and is
used for a few purposes that don't require running from battery power.
Windows exists for ARM, and is slowly gaining market share.
It isn't mainstream yet, but nor has it failed, although Microsoft's early errors
in marketing it have not helped.
The meaningful difference between ARM and x86 in today's market is "how
much battery life do you need, and how large a battery can you fit in the device?"
If the market dynamics of software availability promote consolidation
on a single ISA,
This is unproven. Several companies have tried to do this over history,
but none have succeeded.
then that ISA really ought to... do everything and therefore satisfy everyone.
That is self-contradictory. An ISA that does everything will inevitably
need more transistors to implement than one suited to only some roles.
That means it will cost more, and will be selected against in device
design.
John--- Synchronet 3.21f-Linux NewsLink 1.2
And in the view of some of us; wasting time--but it is your time so do
as you please.
Instead, to the extent I have a _practical_ goal, it would be to
provide an alternative to RISC-V. The mechanism RISC-V uses to
allow instructions longer than 32 bits seems to me to be flawed in
that it doesn't seem to me to be conducive to high code density.
I
apologize in advance for saying this, but I am reminded of rearranging
the deck chairs . . . :-(
RISC-V has a compressed encoding, which is a lot less convoluted. What
is unsatisfactory about that?
On Sat, 04 Apr 2026 13:29:00 +0100, John Dallman wrote:
RISC-V has a compressed encoding, which is a lot less convoluted. What
is unsatisfactory about that?
I can't answer that offhand, but I will look up its compressed encoding.
I suspect it will have a design philosophy vastly different from
anything I am comfortable with, or perhaps even able to comprehend.
without having to
switch into a different mode (like Thumb Mode) for the 16-bit
instructions - which some have claimed, by allowing instructions to be interpreted in an unexpected manner, is a security risk.
In article <10qpjf5$9scf$2@dont-email.me>, quadibloc@ca.invalid (quadi) wrote:
Instead, to the extent I have a _practical_ goal, it would be to
provide an alternative to RISC-V. The mechanism RISC-V uses to
allow instructions longer than 32 bits seems to me to be flawed in
that it doesn't seem to me to be conducive to high code density.
RISC-V has a compressed encoding, which is a lot less convoluted. What is unsatisfactory about that?
John--- Synchronet 3.21f-Linux NewsLink 1.2
a) it eats 3/4 of the OpCode space
jgd@cix.co.uk (John Dallman) posted:
RISC-V has a compressed encoding, which is a lot less convoluted.
What is unsatisfactory about that?
a) it eats 3/4 of the OpCode space
In article <1775318368-5857@newsgrouper.org>, user5857@newsgrouper.org.invalid (MitchAlsup) wrote:
a) it eats 3/4 of the OpCode space
OK, that _is_ unsatisfactory.
In article <1775318368-5857@newsgrouper.org>, user5857@newsgrouper.org.invalid (MitchAlsup) wrote:
jgd@cix.co.uk (John Dallman) posted:
RISC-V has a compressed encoding, which is a lot less convoluted.
What is unsatisfactory about that?
a) it eats 3/4 of the OpCode space
OK, that _is_ unsatisfactory.
In article <1775318368-5857@newsgrouper.org>, >user5857@newsgrouper.org.invalid (MitchAlsup) wrote:
jgd@cix.co.uk (John Dallman) posted:
RISC-V has a compressed encoding, which is a lot less convoluted.
What is unsatisfactory about that?
a) it eats 3/4 of the OpCode space
OK, that _is_ unsatisfactory.
jgd@cix.co.uk (John Dallman) writes:
In article <1775318368-5857@newsgrouper.org>, >user5857@newsgrouper.org.invalid (MitchAlsup) wrote:
jgd@cix.co.uk (John Dallman) posted:
RISC-V has a compressed encoding, which is a lot less
convoluted. What is unsatisfactory about that?
a) it eats 3/4 of the OpCode space
OK, that _is_ unsatisfactory.
Why?
- anton
Why?a) it eats 3/4 of the OpCode spaceOK, that _is_ unsatisfactory.
On Sun, 05 Apr 2026 09:38:43 GMT
anton@mips.complang.tuwien.ac.at (Anton Ertl) wrote:
jgd@cix.co.uk (John Dallman) writes:
In article <1775318368-5857@newsgrouper.org>,
user5857@newsgrouper.org.invalid (MitchAlsup) wrote:
jgd@cix.co.uk (John Dallman) posted:
RISC-V has a compressed encoding, which is a lot less
convoluted. What is unsatisfactory about that?
a) it eats 3/4 of the OpCode space
OK, that _is_ unsatisfactory.
Why?
- anton
Compared to Nios2:
- shorter immediate
- less complete support for comparison + branch
May be, the latter has other reasons, but the former is almost
ceratinly caused by smaller encoding space.
In article <2026Apr5.113843@mips.complang.tuwien.ac.at>, >anton@mips.complang.tuwien.ac.at (Anton Ertl) wrote:
Why?a) it eats 3/4 of the OpCode spaceOK, that _is_ unsatisfactory.
I was making an unconscious assumption, which is probably unwarranted:
that the compressed instruction set was a fairly small subset of the full >one.
My thinking about compressed ISAs is influenced by ARM, where T32 is a >separate mode from the A64 that I've actually used for all the ARM
platforms I've ported software to.
If the compressed instruction set has most of the operations of the >uncompressed one, but is smaller because it addresses subsets of the >registers and has smaller displacements and immediates, there's a
question of if there is a "primary" instruction set, and if so, what it
is?
Michael S <already5chosen@yahoo.com> writes:
On Sun, 05 Apr 2026 09:38:43 GMT
anton@mips.complang.tuwien.ac.at (Anton Ertl) wrote:
jgd@cix.co.uk (John Dallman) writes:
In article <1775318368-5857@newsgrouper.org>,
user5857@newsgrouper.org.invalid (MitchAlsup) wrote:
jgd@cix.co.uk (John Dallman) posted:
RISC-V has a compressed encoding, which is a lot less
convoluted. What is unsatisfactory about that?
a) it eats 3/4 of the OpCode space
OK, that _is_ unsatisfactory.
Why?
- anton
Compared to Nios2:
- shorter immediate
- less complete support for comparison + branch
May be, the latter has other reasons, but the former is almost
ceratinly caused by smaller encoding space.
Nios2 is a 32-bit-only instruction set. RISC-V needs encoding space
for differentiating between 32-bit and 64-bit instructions (and, I
think, 128-bit instructions), e.g., lw and ld, plus not strictly
necessary ones like addw that we have thanks to the wide spread of
I32LP64. My guess is that the lack of 64-bit support was Nios2's
fatal flaw, so Intel/Altera switched to RISC-V-based NiosV.
More importantly, Nios2 does not contain compressed instructions at
all. Do you consider any use of encoding space for compressed
instructions unsatisfactory? If not, how much encoding space would
you spend on them?
Concerning compare-and-branch, the instruction sets have: Nios2 has
Nios2: beq bge bgeu blt bltu bne
RV32I: beq bge bgeu blt bltu bne
The RISC-V manual says:
|Note, BGT, BGTU, BLE, and BLEU can be synthesized by reversing the
|operands to BLT, BLTU, BGE, and BGEU, respectively.
The Nios2 manual mentions, in Table 8-3, the assembler
pseudo-instructions bgt bgtu ble bleu.
I fail to see any difference in support for compar-and-branch
instructions.
- anton
In article <2026Apr5.113843@mips.complang.tuwien.ac.at>, anton@mips.complang.tuwien.ac.at (Anton Ertl) wrote:
Why?a) it eats 3/4 of the OpCode spaceOK, that _is_ unsatisfactory.
I was making an unconscious assumption, which is probably unwarranted:
that the compressed instruction set was a fairly small subset of the full one. If it was, then taking 3/4 of the opcode space would be quite bad.
My thinking about compressed ISAs is influenced by ARM, where T32 is a separate mode from the A64 that I've actually used for all the ARM
platforms I've ported software to.
If the compressed instruction set has most of the operations of the uncompressed one, but is smaller because it addresses subsets of the registers and has smaller displacements and immediates, there's a
question of if there is a "primary" instruction set, and if so, what it
is?
On 4/5/2026 6:43 AM, John Dallman wrote:---------------
In article <2026Apr5.113843@mips.complang.tuwien.ac.at>, anton@mips.complang.tuwien.ac.at (Anton Ertl) wrote:
Some design choices often cited in the design of RISC-V and RV-C appear
to be wrong...
Lots of emphasis on the priorities of leaf functions, when it should
have been the other way around.
Or, most of your code and CPU cycles are not in functions at the bottom
of the call-stack, rather the ones located somewhere in the middle.
Only instructions that need largish immediate values are LI and ADDI,
pretty much everything else could have used Imm3 or Imm4.
Do you need a full Shift-Imm instruction? No.
More effective for encoding space could have been, say:
SLLI Rn4, {1/2/3/4, 8/16/24/32}
SRLI ...
Would have also used 2 bits less encoding space per instruction.
Say, picking the 8 most common shift amounts, vs every shift amount.
Or, stay with Reg3 and save 3 bits.
People may disagree, but, alas...
BGB <cr88192@gmail.com> posted:
On 4/5/2026 6:43 AM, John Dallman wrote:---------------
In article <2026Apr5.113843@mips.complang.tuwien.ac.at>,
anton@mips.complang.tuwien.ac.at (Anton Ertl) wrote:
Some design choices often cited in the design of RISC-V and RV-C appear
to be wrong...
Captain Obvious strikes again.
Lots of emphasis on the priorities of leaf functions, when it should
have been the other way around.
At best, maybe: The code I have access to shows that leaf functions are closer to 50% than 20%--it is high enough that serious effort needs to
go to not needing ANY overhead to leaf functions (Sorry IBM 360 BAL
prologue and epilogue.)
Or, most of your code and CPU cycles are not in functions at the bottom
of the call-stack, rather the ones located somewhere in the middle.
Small loops consume more CPU cycles than calls and returns (too).
--------------
Only instructions that need largish immediate values are LI and ADDI,
pretty much everything else could have used Imm3 or Imm4.
I do not need an LI instruction at all.
Do you need a full Shift-Imm instruction? No.
More effective for encoding space could have been, say:
SLLI Rn4, {1/2/3/4, 8/16/24/32}
SRLI ...
Would have also used 2 bits less encoding space per instruction.
And how do you support j << k ?
Say, picking the 8 most common shift amounts, vs every shift amount. >> Or, stay with Reg3 and save 3 bits.
Heading in wrong direction...
People may disagree, but, alas...
Only the smart ones ...
On 4/6/2026 11:33 AM, MitchAlsup wrote:
--------------
Only instructions that need largish immediate values are LI and ADDI,
pretty much everything else could have used Imm3 or Imm4.
I do not need an LI instruction at all.
For normal RV, ADDI is used for small LI. RV-C has:
C.LI Xd, Imm6 //Xd=Imm6
C.ADDI Xd, Imm6 //Xd=Xd+Imm6
C.LUI Xd. Imm6 //Xd=Imm6<<12
So, composing a 32-bit constant was initially done as (8B):
MOV Imm16hi, Rn
SHORI Imm16lo, Rn
Which was trivially extended to 48 or 64 bit constants.
It is mostly debatable if shift is common enough to justify burning this much encoding space in 16-bit land.
People may disagree, but, alas...
Only the smart ones ...
Granted, but probably no one is going to be redesigning RV-C here, so it
is mostly hypothetical anyways...
In the context of Concertina II, therefore, with the baggage that is
needed for instructions to fit in, a complete 16-bit instruction set
would be a _tour-de-force_ of little or no utility. I think I shall
cosider this an omen, and eschew adding one more header type to
Concertina II in order to support a block type consisting entirely of,
say, 22-bit instructions for maximum code compactness.
BGB <cr88192@gmail.com> posted:
On 4/6/2026 11:33 AM, MitchAlsup wrote:
--------------
Only instructions that need largish immediate values are LI and ADDI,
pretty much everything else could have used Imm3 or Imm4.
I do not need an LI instruction at all.
For normal RV, ADDI is used for small LI. RV-C has:
C.LI Xd, Imm6 //Xd=Imm6
MOV Rd,Immed{16,32,64}
C.ADDI Xd, Imm6 //Xd=Xd+Imm6
ADD Rd,Rd,Immed{16,32,64}
C.LUI Xd. Imm6 //Xd=Imm6<<12
MOV Rd,Immed{16,32,64}
Immediates come in {16,32,64}bit quanta.
---------------
So, composing a 32-bit constant was initially done as (8B):
MOV Imm16hi, Rn
SHORI Imm16lo, Rn
Which was trivially extended to 48 or 64 bit constants.
Composing is for weak ISAs
-----------------
It is mostly debatable if shift is common enough to justify burning this
much encoding space in 16-bit land.
it remains debatable if compression adds more or subtracts more.
People may disagree, but, alas...
Only the smart ones ...
Granted, but probably no one is going to be redesigning RV-C here, so it
is mostly hypothetical anyways...
RISC-V is simply the 2020's version of "mediocracy first wins".
Variety is the spice of life.
7, 25, 46, 64, 85, 103, 124, 142, 163 and 181 bit immediates in the ISA.
I think I got them all.
RISC-V is simply the 2020's version of "mediocracy first wins".
On Mon, 06 Apr 2026 23:31:49 -0400, Robert Finch wrote:
Variety is the spice of life.
7, 25, 46, 64, 85, 103, 124, 142, 163 and 181 bit immediates in the ISA.
I think I got them all.
Oh my. I went to great effort in my Concertina II design to make room available for 8, 16, 32, and 64-bit immediates - and also 48-bit
immediates - ao that I would avoid the need to use an immediate of a
shorter length than the type of quantity I was using it to supply.
I thought that my ISA was the most wretchedly overcomplicated ISA in existence (well, if you don't count x86)... but perhaps you have a good reason for this particular diversity of immediate value lengths.
John Savard
I have ended up reducing the number of immediate lengths over time:
XG1: 3, 4, 5, 8, 9, 10, 16; 17, 33, 64
On Mon, 06 Apr 2026 23:31:49 -0400, Robert Finch wrote:
Variety is the spice of life.
7, 25, 46, 64, 85, 103, 124, 142, 163 and 181 bit immediates in the ISA.
I think I got them all.
Oh my. I went to great effort in my Concertina II design to make room available for 8, 16, 32, and 64-bit immediates - and also 48-bit
immediates - ao that I would avoid the need to use an immediate of a
shorter length than the type of quantity I was using it to supply.
I thought that my ISA was the most wretchedly overcomplicated ISA in existence (well, if you don't count x86)... but perhaps you have a good reason for this particular diversity of immediate value lengths.
John Savard
RISC-V is simply the 2020's version of "mediocracy first wins".
So now I have 80-bit instructions consisting of two 32-bit instructions,
But now that I have had to transmogrify the first member of a pair of
two short instructions in order to squeeze out more opcode space... this gives me the opportunity of...
putting the C bit in, and taking the branch instructions out, of the
first member of a pair of short instructions!
Of course, while conditional branches do come after setting the
condition codes, they're supposed to come longer than immediately after
for the good of the pipeline in the space where this ISA is partially positioned, but it at least gives the appearance of making sense.
It has just dawned on me that if the 15-bit short instructions are in
need of the ability to set the condition codes, *so are the 17-bit short instructions*.
On Tue, 07 Apr 2026 14:50:12 +0000, quadi wrote:
It has just dawned on me that if the 15-bit short instructions are in
need of the ability to set the condition codes, *so are the 17-bit short instructions*.
Given that the 17-bit instructions are used in connection with _variable- width instructions_, which means that there's more flexibility in mixing full-sized 32-bit instructions with short instructions... requiring a 32-
bit operate instruction to set the condition codes is not so bad.
John Savard--- Synchronet 3.21f-Linux NewsLink 1.2
On Tue, 07 Apr 2026 03:12:48 -0500, BGB wrote:
I have ended up reducing the number of immediate lengths over time:
XG1: 3, 4, 5, 8, 9, 10, 16; 17, 33, 64
I suppose the idea of having immediates that are 9, 17, and 33 bits long
is when you want the range of 8, 16, or 32 bit values, but you're feeding
a calculation using integers of a larger size, and so you want the ranges
of both unsigned and signed numbers of those lengths - which a signed
value one bit longer gives you. Like the 9 bit type in Java bytecode.
John Savard
BGB <cr88192@gmail.com> posted:
On 4/6/2026 11:33 AM, MitchAlsup wrote:
--------------
Only instructions that need largish immediate values are LI and ADDI,
pretty much everything else could have used Imm3 or Imm4.
I do not need an LI instruction at all.
For normal RV, ADDI is used for small LI. RV-C has:
C.LI Xd, Imm6 //Xd=Imm6
MOV Rd,Immed{16,32,64}
C.ADDI Xd, Imm6 //Xd=Xd+Imm6
ADD Rd,Rd,Immed{16,32,64}
C.LUI Xd. Imm6 //Xd=Imm6<<12
MOV Rd,Immed{16,32,64}
Immediates come in {16,32,64}bit quanta.
---------------
So, composing a 32-bit constant was initially done as (8B):
MOV Imm16hi, Rn
SHORI Imm16lo, Rn
Which was trivially extended to 48 or 64 bit constants.
Composing is for weak ISAs
It is mostly debatable if shift is common enough to justify burning this
much encoding space in 16-bit land.
it remains debatable if compression adds more or subtracts more.
People may disagree, but, alas...
Only the smart ones ...
Granted, but probably no one is going to be redesigning RV-C here, so it
is mostly hypothetical anyways...
RISC-V is simply the 2020's version of "mediocracy first wins".
On 4/7/2026 5:24 AM, quadi wrote:
On Tue, 07 Apr 2026 03:12:48 -0500, BGB wrote:
I have ended up reducing the number of immediate lengths over time:
XG1: 3, 4, 5, 8, 9, 10, 16; 17, 33, 64
I suppose the idea of having immediates that are 9, 17, and 33 bits long
is when you want the range of 8, 16, or 32 bit values, but you're feeding
a calculation using integers of a larger size, and so you want the ranges of both unsigned and signed numbers of those lengths - which a signed
value one bit longer gives you. Like the 9 bit type in Java bytecode.
For the 17 and 33 bit cases, this was the major point:
-32768 .. 65535: Covers a big chunk of constants;
-2G .. 4G: Covers most of the rest.
Comparably, the set that a full needs 64 bits is small, but "nice to have".
The pattern is weaker for 9s, because while true, it is still in the
domain where the "values near 0" bell-curve still dominates.
Much outside the low 10-12 bits, the main bell-curve drops off, and
leaves the 16/17 bit, and 32/33 bit spikes. Both spikes are followed by
a relative "no man's land" where there is relatively little until
reaching the next power of 2.
This is most notable between 34 and 60 bits, where there is "hardly anything".
BGB <cr88192@gmail.com> posted:
On 4/7/2026 5:24 AM, quadi wrote:
On Tue, 07 Apr 2026 03:12:48 -0500, BGB wrote:
I have ended up reducing the number of immediate lengths over time:
XG1: 3, 4, 5, 8, 9, 10, 16; 17, 33, 64
I suppose the idea of having immediates that are 9, 17, and 33 bits long >>> is when you want the range of 8, 16, or 32 bit values, but you're feeding >>> a calculation using integers of a larger size, and so you want the ranges >>> of both unsigned and signed numbers of those lengths - which a signed
value one bit longer gives you. Like the 9 bit type in Java bytecode.
For the 17 and 33 bit cases, this was the major point:
-32768 .. 65535: Covers a big chunk of constants;
-2G .. 4G: Covers most of the rest.
Comparably, the set that a full needs 64 bits is small, but "nice to have". >>
The pattern is weaker for 9s, because while true, it is still in the
domain where the "values near 0" bell-curve still dominates.
Much outside the low 10-12 bits, the main bell-curve drops off, and
leaves the 16/17 bit, and 32/33 bit spikes. Both spikes are followed by
a relative "no man's land" where there is relatively little until
reaching the next power of 2.
This is most notable between 34 and 60 bits, where there is "hardly
anything".
If you have FP64 constants, there is a lot of data in here.
Then, within the realm of floating point constants, a significant
majority of the common ones can be represented exactly using Binary16.
BGB <cr88192@gmail.com> schrieb:
Then, within the realm of floating point constants, a significant
majority of the common ones can be represented exactly using Binary16.
s/majority/minority/
The word "flailing" comes to mind.
On 4/8/2026 2:50 PM, Thomas Koenig wrote:
BGB <cr88192@gmail.com> schrieb:
Then, within the realm of floating point constants, a significant
majority of the common ones can be represented exactly using Binary16.
s/majority/minority/
?...
The vast majority of the floating point constants in typical code are
things like:
0, 1.0, 2.0, 3.0
1.5, 2.5
0.375, 0.625, ...
...
Mostly all things that can be represented exactly.
Things like 0.1 and (1.0/3.0), M_PI, etc, can't be represented.
But, are comparably less common.
Likewise, most of the sorts of constants that appear in "sin()" are also
non representable, there are comparably few of them.
So, the instruction remains effective.
On Tue, 07 Apr 2026 16:59:09 +0000, MitchAlsup wrote:
The word "flailing" comes to mind.
Sadly, I'm not in a position to disagree.
The set of variable-length instructions with built-in predication and explicit indication of parallelism I've come up with...
would have, as their ideal block header, 0 followed by 15 bits, indicating which 16-bit areas of the block begin a new instruction.
That's half the opcode space!
I could achieve that - the load-store memory reference instructions that begin with 00, 01, and 10 could be squeezed into just 10 if I restricted them to only aligned operands. So I could impose this restriction only on the first 32-bit instruction slot of a block without a header.
But that's totally in opposition to having the instruction set behave like RISC unless I choose to add in a header.
And then I realized: I had _already_ made a rule that, in the absence of a header, the first instruction slot, if it has a pair of 15-bit--- Synchronet 3.21f-Linux NewsLink 1.2
instructions, imposes more restrictions on them to make room for headers.
I am not sure how to react to this discovery at this time.
John Savard
And then I realized: I had _already_ made a rule that, in the absence of
a header, the first instruction slot, if it has a pair of 15-bit instructions, imposes more restrictions on them to make room for
headers.
On 4/8/2026 1:03 PM, BGB wrote:
On 4/8/2026 2:50 PM, Thomas Koenig wrote:
BGB <cr88192@gmail.com> schrieb:
Then, within the realm of floating point constants, a significant
majority of the common ones can be represented exactly using Binary16.
s/majority/minority/
?...
The vast majority of the floating point constants in typical code are
things like:
0, 1.0, 2.0, 3.0
1.5, 2.5
0.375, 0.625, ...
...
Mostly all things that can be represented exactly.
Things like 0.1 and (1.0/3.0), M_PI, etc, can't be represented.
But, are comparably less common.
Likewise, most of the sorts of constants that appear in "sin()" are
also non representable, there are comparably few of them.
So, the instruction remains effective.
I don't want to seem like a nag, but couldn't the difference between
your experience and Thomas' be due to familiarity with different
workloads - Thomas with scientific codes and you with games?
On 4/8/2026 5:15 PM, Stephen Fuld wrote:
On 4/8/2026 1:03 PM, BGB wrote:
On 4/8/2026 2:50 PM, Thomas Koenig wrote:
BGB <cr88192@gmail.com> schrieb:
Then, within the realm of floating point constants, a significants/majority/minority/
majority of the common ones can be represented exactly using Binary16. >>>
?...
The vast majority of the floating point constants in typical code are
things like:
0, 1.0, 2.0, 3.0
1.5, 2.5
0.375, 0.625, ...
...
Mostly all things that can be represented exactly.
Things like 0.1 and (1.0/3.0), M_PI, etc, can't be represented.
But, are comparably less common.
Likewise, most of the sorts of constants that appear in "sin()" are
also non representable, there are comparably few of them.
So, the instruction remains effective.
I don't want to seem like a nag, but couldn't the difference between
your experience and Thomas' be due to familiarity with different
workloads - Thomas with scientific codes and you with games?
Could be.
I guess the thing would be to maybe find some codebases and do more far-reaching stats to figure out the statistical probabilities of the various types of constants.
Though, granted, there is a range of common simple constants, namely
those based around factors of 10, that pose a problem and are not exact:
0.1, 0.2, 0.3, ..., 0.7, 0.8, 0.9
So, if a person types 0.1*x, the 0.1 can't be represented exactly,
whereas if they typed 0.125 it could, but not if they round to 0.13, ...
BGB <cr88192@gmail.com> posted:
On 4/8/2026 5:15 PM, Stephen Fuld wrote:
On 4/8/2026 1:03 PM, BGB wrote:
On 4/8/2026 2:50 PM, Thomas Koenig wrote:
BGB <cr88192@gmail.com> schrieb:
Then, within the realm of floating point constants, a significants/majority/minority/
majority of the common ones can be represented exactly using Binary16. >>>>>
?...
The vast majority of the floating point constants in typical code are
things like:
0, 1.0, 2.0, 3.0
1.5, 2.5
0.375, 0.625, ...
...
Mostly all things that can be represented exactly.
Things like 0.1 and (1.0/3.0), M_PI, etc, can't be represented.
But, are comparably less common.
Likewise, most of the sorts of constants that appear in "sin()" are
also non representable, there are comparably few of them.
So, the instruction remains effective.
I don't want to seem like a nag, but couldn't the difference between
your experience and Thomas' be due to familiarity with different
workloads - Thomas with scientific codes and you with games?
Could be.
I guess the thing would be to maybe find some codebases and do more
far-reaching stats to figure out the statistical probabilities of the
various types of constants.
Though, granted, there is a range of common simple constants, namely
those based around factors of 10, that pose a problem and are not exact:
0.1, 0.2, 0.3, ..., 0.7, 0.8, 0.9
Let's look at these often encountered constants: many times they are used
in simple arithmetic moslty with FP32s and less often FP64. LLVM has a
rule where by it only uses an FP32 constant when it is exact! So, code
that looks like::
f1 = f2*0.1;
is compiled into::
CVTFD Rd,Rf2
FMULD Rd,Rd,#0.1D0
CVTDF RF1,Rd
Which is why My 66000 ISA makes a shorter FP calculation with a larger
FP constant is calculated as a mixed size FP calculation with a single rounding::
FMULF Rf1,Rf2,#0.1D0
Instead of the above.
So, if a person types 0.1*x, the 0.1 can't be represented exactly,
whereas if they typed 0.125 it could, but not if they round to 0.13, ...
Compilers need to obey what is written in source code under the rules of
the source code language.
On 4/9/2026 12:35 PM, MitchAlsup wrote:------------------
Had recently got some minor code density improvements in XG3, have noted:
Was trying to encode "~x" as "XOR Rs, -1, Rd", which needs a 64-bit
encoding on XG3
BGB <cr88192@gmail.com> posted:
On 4/9/2026 12:35 PM, MitchAlsup wrote:------------------
Had recently got some minor code density improvements in XG3, have noted:
Was trying to encode "~x" as "XOR Rs, -1, Rd", which needs a 64-bit
encoding on XG3
XOR Rd,Rs,#-1
Is a 32-bit encoding in My 66000.
But: 15 & ~x is:
AND Rd,~RS,#15
Is a 32-bit encoding, too.
On 4/9/2026 8:11 PM, MitchAlsup wrote:
BGB <cr88192@gmail.com> posted:
On 4/9/2026 12:35 PM, MitchAlsup wrote:------------------
Had recently got some minor code density improvements in XG3, have
noted:
Was trying to encode "~x" as "XOR Rs, -1, Rd", which needs a 64-bit
encoding on XG3
XOR Rd,Rs,#-1
Is a 32-bit encoding in My 66000.
But: 15 & ~x is:
AND Rd,~RS,#15
Is a 32-bit encoding, too.
In XG3, it is a 64-bit encoding because the 32-bit encoding was Imm10u (contrast to XOR being Imm10s), but in the XG1->XG2 transition AND
became signed wheres OR and XOR remained unsigned, because in this case negative immediate values for AND were more common but for OR and XOR
was rare, and XG3 kept the same pattern.
In all of these cases though, a jumbo prefix expands them to 33s.
Does mean though that the trick that RISC-V uses here is less efficient
on XG3; but I did carry over the NOT 2R instruction from before.
Even if, yeah, having a signed immediate would have avoided the need to
keep the NOT instruction around.
Maybe could have made them all 10s though.
Arguably also maybe would have been better to use Imm10s rather than the 10u/10n scheme for ADD and similar (to not burn as much encoding space).
Changing these at this point would break binary compatibility though.
Well, win-some, lose some.
On 2026-04-09 10:09 p.m., BGB wrote:
On 4/9/2026 8:11 PM, MitchAlsup wrote:
BGB <cr88192@gmail.com> posted:
On 4/9/2026 12:35 PM, MitchAlsup wrote:------------------
Had recently got some minor code density improvements in XG3, have
noted:
Was trying to encode "~x" as "XOR Rs, -1, Rd", which needs a 64-bit
encoding on XG3
Although rarely used, could there be an explicit COM instruction? It
needs only one (or two) register field. With a 32-bit encoding there is
22 bits available for the opcode.
These two operations can be done as single 48-bit instructions with Qupls4
XOR Rd,Rs,#-1
Is a 32-bit encoding in My 66000.
But: 15 & ~x is:
AND Rd,~RS,#15
Is a 32-bit encoding, too.
In XG3, it is a 64-bit encoding because the 32-bit encoding was Imm10u
(contrast to XOR being Imm10s), but in the XG1->XG2 transition AND
became signed wheres OR and XOR remained unsigned, because in this
case negative immediate values for AND were more common but for OR and
XOR was rare, and XG3 kept the same pattern.
In all of these cases though, a jumbo prefix expands them to 33s.
Does mean though that the trick that RISC-V uses here is less
efficient on XG3; but I did carry over the NOT 2R instruction from
before.
Even if, yeah, having a signed immediate would have avoided the need
to keep the NOT instruction around.
Maybe could have made them all 10s though.
Arguably also maybe would have been better to use Imm10s rather than
the 10u/10n scheme for ADD and similar (to not burn as much encoding
space).
Changing these at this point would break binary compatibility though.
Well, win-some, lose some.
XOR Rd,Rs1,#-1
XOR_AND Rd,Rs1,#-1,#15
Thinking of dynamic instruction count density versus code density.
Not sure if to add ANDC and ORC instructions to the ISA.
Maybe swap NAND for ANDC as NAND can be synthesized:
AND_XOR Rd,Rs1,Rs2,#-1
Some useless combinations of instructions:
NAND_XOR Rd,Rs1,Rs2,#-1 sames as AND
On 4/11/2026 12:41 AM, Robert Finch wrote:
On 2026-04-09 10:09 p.m., BGB wrote:
On 4/9/2026 8:11 PM, MitchAlsup wrote:
BGB <cr88192@gmail.com> posted:
On 4/9/2026 12:35 PM, MitchAlsup wrote:------------------
Had recently got some minor code density improvements in XG3, have
noted:
Was trying to encode "~x" as "XOR Rs, -1, Rd", which needs a 64-bit
encoding on XG3
Although rarely used, could there be an explicit COM instruction? It
needs only one (or two) register field. With a 32-bit encoding there
is 22 bits available for the opcode.
I thought about it, and looked into it, and the "breaking impact" of changing OR and XOR from 10u to 10s seemed acceptable:
XG1/XG2: No Effect, N/E for XG1, N/A for XG2.
XG3: Only obvious effect of change was a demo desync in Heretic.
So, while it was a breaking change, it wasn't one that breaks enough to
make it a deal-breaker.
Seemingly the only case it came up was in the Gargoyle AI code.
Granted, breaking changes aren't ideal, but can maybe let this one slide.
A had looked into disabling the ADDU.L 3RI case in BGBCC and instead
using either immediate-synthesis or 2-op sequences. Impact is "small enough".
Doing similar for ADDS.L would not go over as well though, as it would
have a roughly 3% adverse impact on code-side. There isn't really a good
way to shrink the 10un encodings to 10s (and trying to change behavior
here would also effect XG1 and XG2).
Issue is that ADDS.L's 3RI form is used roughly 200x more often than ADDU.L's 3RI form; so having a 3RI form of ADDU.L isn't worthwhile.
Though, ADDS.L is used roughly 10x less than ADD's 3RI form (which is
the main option that actually warrants the 10un 3RI encodings).
The main reason to consider reducing or dropping the ADDU.L and ADDS.L encodings would be to try to free up some more of the Imm10 space.
These two operations can be done as single 48-bit instructions with
XOR Rd,Rs,#-1
Is a 32-bit encoding in My 66000.
But: 15 & ~x is:
AND Rd,~RS,#15
Is a 32-bit encoding, too.
In XG3, it is a 64-bit encoding because the 32-bit encoding was
Imm10u (contrast to XOR being Imm10s), but in the XG1->XG2 transition
AND became signed wheres OR and XOR remained unsigned, because in
this case negative immediate values for AND were more common but for
OR and XOR was rare, and XG3 kept the same pattern.
In all of these cases though, a jumbo prefix expands them to 33s.
Does mean though that the trick that RISC-V uses here is less
efficient on XG3; but I did carry over the NOT 2R instruction from
before.
Even if, yeah, having a signed immediate would have avoided the need
to keep the NOT instruction around.
Maybe could have made them all 10s though.
Arguably also maybe would have been better to use Imm10s rather than
the 10u/10n scheme for ADD and similar (to not burn as much encoding
space).
Changing these at this point would break binary compatibility though.
Well, win-some, lose some.
Qupls4
XOR Rd,Rs1,#-1
XOR_AND Rd,Rs1,#-1,#15
Thinking of dynamic instruction count density versus code density.
Not sure if to add ANDC and ORC instructions to the ISA.
Maybe swap NAND for ANDC as NAND can be synthesized:
AND_XOR Rd,Rs1,Rs2,#-1
Some useless combinations of instructions:
NAND_XOR Rd,Rs1,Rs2,#-1 sames as AND
Dunno there...
I am looking into adding some special cases:
FADD/FSUB/FMUL Rm, J_Imm16_fp16, Rn //XG1/2/3
FADD/FSUB/FMUL Rm, J_Imm32_fp64t, Rn //XG3 only
Which would add 64-bit encodings which could add either a Binary16
immediate for FPU ops (potentially encoded in all 3 ISA modes), or an encoding representing a Binary64 value truncated to 32-bits, and
currently only may be encoded in XG3.
It is possible that there could be an Imm64_fp64 encoding, but would
also need to be XG3 only.
Partly this is because XG3 essentially has the biggest jumbo prefixes
(so can pull this off with immediate synthesis).
Could potentially also add an J_Imm16_fp16 case to RV+JX as well (which
also has immediate synthesis).
It just occurred to me, the seven-bit float immediate does not have a
way to represent zero. The exponent is shifted by adding a bias value to
it. With S.E3.M3 the smallest exponent encoded as a zero is -3. All
zeros is 1/8 not zero. So, a special trap for zero needs to be added, in which case 1/8 cannot be represented.
On 2026-04-11 2:45 a.m., BGB wrote:
On 4/11/2026 12:41 AM, Robert Finch wrote:It just occurred to me, the seven-bit float immediate does not have a
On 2026-04-09 10:09 p.m., BGB wrote:
On 4/9/2026 8:11 PM, MitchAlsup wrote:
BGB <cr88192@gmail.com> posted:
On 4/9/2026 12:35 PM, MitchAlsup wrote:------------------
Had recently got some minor code density improvements in XG3, have >>>>>> noted:
Was trying to encode "~x" as "XOR Rs, -1, Rd", which needs a 64-bit >>>>>> encoding on XG3
Although rarely used, could there be an explicit COM instruction? It
needs only one (or two) register field. With a 32-bit encoding there
is 22 bits available for the opcode.
I thought about it, and looked into it, and the "breaking impact" of
changing OR and XOR from 10u to 10s seemed acceptable:
XG1/XG2: No Effect, N/E for XG1, N/A for XG2.
XG3: Only obvious effect of change was a demo desync in Heretic.
So, while it was a breaking change, it wasn't one that breaks enough
to make it a deal-breaker.
Seemingly the only case it came up was in the Gargoyle AI code.
Granted, breaking changes aren't ideal, but can maybe let this one slide.
A had looked into disabling the ADDU.L 3RI case in BGBCC and instead
using either immediate-synthesis or 2-op sequences. Impact is "small
enough".
Doing similar for ADDS.L would not go over as well though, as it would
have a roughly 3% adverse impact on code-side. There isn't really a
good way to shrink the 10un encodings to 10s (and trying to change
behavior here would also effect XG1 and XG2).
Issue is that ADDS.L's 3RI form is used roughly 200x more often than
ADDU.L's 3RI form; so having a 3RI form of ADDU.L isn't worthwhile.
Though, ADDS.L is used roughly 10x less than ADD's 3RI form (which is
the main option that actually warrants the 10un 3RI encodings).
The main reason to consider reducing or dropping the ADDU.L and ADDS.L
encodings would be to try to free up some more of the Imm10 space.
These two operations can be done as single 48-bit instructions with
XOR Rd,Rs,#-1
Is a 32-bit encoding in My 66000.
But: 15 & ~x is:
AND Rd,~RS,#15
Is a 32-bit encoding, too.
In XG3, it is a 64-bit encoding because the 32-bit encoding was
Imm10u (contrast to XOR being Imm10s), but in the XG1->XG2
transition AND became signed wheres OR and XOR remained unsigned,
because in this case negative immediate values for AND were more
common but for OR and XOR was rare, and XG3 kept the same pattern.
In all of these cases though, a jumbo prefix expands them to 33s.
Does mean though that the trick that RISC-V uses here is less
efficient on XG3; but I did carry over the NOT 2R instruction from
before.
Even if, yeah, having a signed immediate would have avoided the need
to keep the NOT instruction around.
Maybe could have made them all 10s though.
Arguably also maybe would have been better to use Imm10s rather than
the 10u/10n scheme for ADD and similar (to not burn as much encoding
space).
Changing these at this point would break binary compatibility though.
Well, win-some, lose some.
Qupls4
XOR Rd,Rs1,#-1
XOR_AND Rd,Rs1,#-1,#15
Thinking of dynamic instruction count density versus code density.
Not sure if to add ANDC and ORC instructions to the ISA.
Maybe swap NAND for ANDC as NAND can be synthesized:
AND_XOR Rd,Rs1,Rs2,#-1
Some useless combinations of instructions:
NAND_XOR Rd,Rs1,Rs2,#-1 sames as AND
Dunno there...
I am looking into adding some special cases:
FADD/FSUB/FMUL Rm, J_Imm16_fp16, Rn //XG1/2/3
FADD/FSUB/FMUL Rm, J_Imm32_fp64t, Rn //XG3 only
Which would add 64-bit encodings which could add either a Binary16
immediate for FPU ops (potentially encoded in all 3 ISA modes), or an
encoding representing a Binary64 value truncated to 32-bits, and
currently only may be encoded in XG3.
It is possible that there could be an Imm64_fp64 encoding, but would
also need to be XG3 only.
Partly this is because XG3 essentially has the biggest jumbo prefixes
(so can pull this off with immediate synthesis).
Could potentially also add an J_Imm16_fp16 case to RV+JX as well
(which also has immediate synthesis).
way to represent zero. The exponent is shifted by adding a bias value to
it. With S.E3.M3 the smallest exponent encoded as a zero is -3. All
zeros is 1/8 not zero. So, a special trap for zero needs to be added, in which case 1/8 cannot be represented.
Special case logic hurts size and performance. Zero is probably used
often enough though. All those extra IF/ELSE adding priority logic.
FMUL is done as FMA (Rs1 * Rs2) + 0
Could add an explicit FMUL instruction with a 16-bit immediate.
Splitting hairs though, probably does not add enough value over FMA with seven-bit immediates.
On 2026-04-11 2:45 a.m., BGB wrote:
On 4/11/2026 12:41 AM, Robert Finch wrote:It just occurred to me, the seven-bit float immediate does not have a
On 2026-04-09 10:09 p.m., BGB wrote:
On 4/9/2026 8:11 PM, MitchAlsup wrote:
BGB <cr88192@gmail.com> posted:
On 4/9/2026 12:35 PM, MitchAlsup wrote:------------------
Had recently got some minor code density improvements in XG3, have >>>>>> noted:
Was trying to encode "~x" as "XOR Rs, -1, Rd", which needs a 64-bit >>>>>> encoding on XG3
Although rarely used, could there be an explicit COM instruction? It
needs only one (or two) register field. With a 32-bit encoding there
is 22 bits available for the opcode.
I thought about it, and looked into it, and the "breaking impact" of
changing OR and XOR from 10u to 10s seemed acceptable:
XG1/XG2: No Effect, N/E for XG1, N/A for XG2.
XG3: Only obvious effect of change was a demo desync in Heretic.
So, while it was a breaking change, it wasn't one that breaks enough
to make it a deal-breaker.
Seemingly the only case it came up was in the Gargoyle AI code.
Granted, breaking changes aren't ideal, but can maybe let this one slide.
A had looked into disabling the ADDU.L 3RI case in BGBCC and instead
using either immediate-synthesis or 2-op sequences. Impact is "small
enough".
Doing similar for ADDS.L would not go over as well though, as it would
have a roughly 3% adverse impact on code-side. There isn't really a
good way to shrink the 10un encodings to 10s (and trying to change
behavior here would also effect XG1 and XG2).
Issue is that ADDS.L's 3RI form is used roughly 200x more often than
ADDU.L's 3RI form; so having a 3RI form of ADDU.L isn't worthwhile.
Though, ADDS.L is used roughly 10x less than ADD's 3RI form (which is
the main option that actually warrants the 10un 3RI encodings).
The main reason to consider reducing or dropping the ADDU.L and ADDS.L
encodings would be to try to free up some more of the Imm10 space.
These two operations can be done as single 48-bit instructions with
XOR Rd,Rs,#-1
Is a 32-bit encoding in My 66000.
But: 15 & ~x is:
AND Rd,~RS,#15
Is a 32-bit encoding, too.
In XG3, it is a 64-bit encoding because the 32-bit encoding was
Imm10u (contrast to XOR being Imm10s), but in the XG1->XG2
transition AND became signed wheres OR and XOR remained unsigned,
because in this case negative immediate values for AND were more
common but for OR and XOR was rare, and XG3 kept the same pattern.
In all of these cases though, a jumbo prefix expands them to 33s.
Does mean though that the trick that RISC-V uses here is less
efficient on XG3; but I did carry over the NOT 2R instruction from
before.
Even if, yeah, having a signed immediate would have avoided the need
to keep the NOT instruction around.
Maybe could have made them all 10s though.
Arguably also maybe would have been better to use Imm10s rather than
the 10u/10n scheme for ADD and similar (to not burn as much encoding
space).
Changing these at this point would break binary compatibility though.
Well, win-some, lose some.
Qupls4
XOR Rd,Rs1,#-1
XOR_AND Rd,Rs1,#-1,#15
Thinking of dynamic instruction count density versus code density.
Not sure if to add ANDC and ORC instructions to the ISA.
Maybe swap NAND for ANDC as NAND can be synthesized:
AND_XOR Rd,Rs1,Rs2,#-1
Some useless combinations of instructions:
NAND_XOR Rd,Rs1,Rs2,#-1 sames as AND
Dunno there...
I am looking into adding some special cases:
FADD/FSUB/FMUL Rm, J_Imm16_fp16, Rn //XG1/2/3
FADD/FSUB/FMUL Rm, J_Imm32_fp64t, Rn //XG3 only
Which would add 64-bit encodings which could add either a Binary16
immediate for FPU ops (potentially encoded in all 3 ISA modes), or an
encoding representing a Binary64 value truncated to 32-bits, and
currently only may be encoded in XG3.
It is possible that there could be an Imm64_fp64 encoding, but would
also need to be XG3 only.
Partly this is because XG3 essentially has the biggest jumbo prefixes
(so can pull this off with immediate synthesis).
Could potentially also add an J_Imm16_fp16 case to RV+JX as well
(which also has immediate synthesis).
way to represent zero. The exponent is shifted by adding a bias value to
it. With S.E3.M3 the smallest exponent encoded as a zero is -3. All
zeros is 1/8 not zero. So, a special trap for zero needs to be added, in which case 1/8 cannot be represented.
Special case logic hurts size and performance. Zero is probably used
often enough though. All those extra IF/ELSE adding priority logic.
FMUL is done as FMA (Rs1 * Rs2) + 0
Could add an explicit FMUL instruction with a 16-bit immediate.
Splitting hairs though, probably does not add enough value over FMA with seven-bit immediates.
On 2026-04-09 10:09 p.m., BGB wrote:-------------------------------
On 4/9/2026 8:11 PM, MitchAlsup wrote:
Thinking of dynamic instruction count density versus code density.
Not sure if to add ANDC and ORC instructions to the ISA.
Maybe swap NAND for ANDC as NAND can be synthesized:
AND_XOR Rd,Rs1,Rs2,#-1
Some useless combinations of instructions:
NAND_XOR Rd,Rs1,Rs2,#-1 sames as AND
On 4/11/2026 4:32 AM, Robert Finch wrote:
On 2026-04-11 2:45 a.m., BGB wrote:
On 4/11/2026 12:41 AM, Robert Finch wrote:It just occurred to me, the seven-bit float immediate does not have a
On 2026-04-09 10:09 p.m., BGB wrote:
On 4/9/2026 8:11 PM, MitchAlsup wrote:
BGB <cr88192@gmail.com> posted:
On 4/9/2026 12:35 PM, MitchAlsup wrote:------------------
Had recently got some minor code density improvements in XG3,
have noted:
Was trying to encode "~x" as "XOR Rs, -1, Rd", which needs a 64-bit >>>>>>> encoding on XG3
Although rarely used, could there be an explicit COM instruction? It
needs only one (or two) register field. With a 32-bit encoding there
is 22 bits available for the opcode.
I thought about it, and looked into it, and the "breaking impact" of
changing OR and XOR from 10u to 10s seemed acceptable:
XG1/XG2: No Effect, N/E for XG1, N/A for XG2.
XG3: Only obvious effect of change was a demo desync in Heretic.
So, while it was a breaking change, it wasn't one that breaks enough
to make it a deal-breaker.
Seemingly the only case it came up was in the Gargoyle AI code.
Granted, breaking changes aren't ideal, but can maybe let this one
slide.
A had looked into disabling the ADDU.L 3RI case in BGBCC and instead
using either immediate-synthesis or 2-op sequences. Impact is "small
enough".
Doing similar for ADDS.L would not go over as well though, as it
would have a roughly 3% adverse impact on code-side. There isn't
really a good way to shrink the 10un encodings to 10s (and trying to
change behavior here would also effect XG1 and XG2).
Issue is that ADDS.L's 3RI form is used roughly 200x more often than
ADDU.L's 3RI form; so having a 3RI form of ADDU.L isn't worthwhile.
Though, ADDS.L is used roughly 10x less than ADD's 3RI form (which is
the main option that actually warrants the 10un 3RI encodings).
The main reason to consider reducing or dropping the ADDU.L and
ADDS.L encodings would be to try to free up some more of the Imm10
space.
These two operations can be done as single 48-bit instructions with
XOR Rd,Rs,#-1
Is a 32-bit encoding in My 66000.
But: 15 & ~x is:
AND Rd,~RS,#15
Is a 32-bit encoding, too.
In XG3, it is a 64-bit encoding because the 32-bit encoding was
Imm10u (contrast to XOR being Imm10s), but in the XG1->XG2
transition AND became signed wheres OR and XOR remained unsigned,
because in this case negative immediate values for AND were more
common but for OR and XOR was rare, and XG3 kept the same pattern.
In all of these cases though, a jumbo prefix expands them to 33s.
Does mean though that the trick that RISC-V uses here is less
efficient on XG3; but I did carry over the NOT 2R instruction from
before.
Even if, yeah, having a signed immediate would have avoided the
need to keep the NOT instruction around.
Maybe could have made them all 10s though.
Arguably also maybe would have been better to use Imm10s rather
than the 10u/10n scheme for ADD and similar (to not burn as much
encoding space).
Changing these at this point would break binary compatibility though. >>>>>
Well, win-some, lose some.
Qupls4
XOR Rd,Rs1,#-1
XOR_AND Rd,Rs1,#-1,#15
Thinking of dynamic instruction count density versus code density.
Not sure if to add ANDC and ORC instructions to the ISA.
Maybe swap NAND for ANDC as NAND can be synthesized:
AND_XOR Rd,Rs1,Rs2,#-1
Some useless combinations of instructions:
NAND_XOR Rd,Rs1,Rs2,#-1 sames as AND
Dunno there...
I am looking into adding some special cases:
FADD/FSUB/FMUL Rm, J_Imm16_fp16, Rn //XG1/2/3
FADD/FSUB/FMUL Rm, J_Imm32_fp64t, Rn //XG3 only
Which would add 64-bit encodings which could add either a Binary16
immediate for FPU ops (potentially encoded in all 3 ISA modes), or an
encoding representing a Binary64 value truncated to 32-bits, and
currently only may be encoded in XG3.
It is possible that there could be an Imm64_fp64 encoding, but would
also need to be XG3 only.
Partly this is because XG3 essentially has the biggest jumbo prefixes
(so can pull this off with immediate synthesis).
Could potentially also add an J_Imm16_fp16 case to RV+JX as well
(which also has immediate synthesis).
way to represent zero. The exponent is shifted by adding a bias value
to it. With S.E3.M3 the smallest exponent encoded as a zero is -3. All
zeros is 1/8 not zero. So, a special trap for zero needs to be added,
in which case 1/8 cannot be represented.
Special case logic hurts size and performance. Zero is probably used
often enough though. All those extra IF/ELSE adding priority logic.
FMUL is done as FMA (Rs1 * Rs2) + 0
Could add an explicit FMUL instruction with a 16-bit immediate.
Splitting hairs though, probably does not add enough value over FMA
with seven-bit immediates.
I repeat a suggestion I made some time ago. Why not make the 7 bits an index into a ROM that holds the 128 most used constants, whatever their values? That should allow a net reduction in instruction size (fewer longer immediates required), at minimal increased resource usage.
Robert Finch <robfi680@gmail.com> schrieb:
It just occurred to me, the seven-bit float immediate does not have a
way to represent zero. The exponent is shifted by adding a bias value to
it. With S.E3.M3 the smallest exponent encoded as a zero is -3. All
zeros is 1/8 not zero. So, a special trap for zero needs to be added, in
which case 1/8 cannot be represented.
Why not use the IEEE-like encoding, with hidden bit and special
handling of zero exponents for zeros and denorms? You can skip the
maximum exponent special handling, probably, unless you want a short
encoding for NaN.
On 4/11/2026 4:32 AM, Robert Finch wrote:
On 2026-04-11 2:45 a.m., BGB wrote:
On 4/11/2026 12:41 AM, Robert Finch wrote:It just occurred to me, the seven-bit float immediate does not have a
On 2026-04-09 10:09 p.m., BGB wrote:
On 4/9/2026 8:11 PM, MitchAlsup wrote:
BGB <cr88192@gmail.com> posted:
On 4/9/2026 12:35 PM, MitchAlsup wrote:------------------
Had recently got some minor code density improvements in XG3,
have noted:
Was trying to encode "~x" as "XOR Rs, -1, Rd", which needs a 64-bit >>>>>>> encoding on XG3
Although rarely used, could there be an explicit COM instruction? It
needs only one (or two) register field. With a 32-bit encoding there
is 22 bits available for the opcode.
I thought about it, and looked into it, and the "breaking impact" of
changing OR and XOR from 10u to 10s seemed acceptable:
XG1/XG2: No Effect, N/E for XG1, N/A for XG2.
XG3: Only obvious effect of change was a demo desync in Heretic.
So, while it was a breaking change, it wasn't one that breaks enough
to make it a deal-breaker.
Seemingly the only case it came up was in the Gargoyle AI code.
Granted, breaking changes aren't ideal, but can maybe let this one
slide.
A had looked into disabling the ADDU.L 3RI case in BGBCC and instead
using either immediate-synthesis or 2-op sequences. Impact is "small
enough".
Doing similar for ADDS.L would not go over as well though, as it
would have a roughly 3% adverse impact on code-side. There isn't
really a good way to shrink the 10un encodings to 10s (and trying to
change behavior here would also effect XG1 and XG2).
Issue is that ADDS.L's 3RI form is used roughly 200x more often than
ADDU.L's 3RI form; so having a 3RI form of ADDU.L isn't worthwhile.
Though, ADDS.L is used roughly 10x less than ADD's 3RI form (which is
the main option that actually warrants the 10un 3RI encodings).
The main reason to consider reducing or dropping the ADDU.L and
ADDS.L encodings would be to try to free up some more of the Imm10
space.
These two operations can be done as single 48-bit instructions with
XOR Rd,Rs,#-1
Is a 32-bit encoding in My 66000.
But: 15 & ~x is:
AND Rd,~RS,#15
Is a 32-bit encoding, too.
In XG3, it is a 64-bit encoding because the 32-bit encoding was
Imm10u (contrast to XOR being Imm10s), but in the XG1->XG2
transition AND became signed wheres OR and XOR remained unsigned,
because in this case negative immediate values for AND were more
common but for OR and XOR was rare, and XG3 kept the same pattern.
In all of these cases though, a jumbo prefix expands them to 33s.
Does mean though that the trick that RISC-V uses here is less
efficient on XG3; but I did carry over the NOT 2R instruction from
before.
Even if, yeah, having a signed immediate would have avoided the
need to keep the NOT instruction around.
Maybe could have made them all 10s though.
Arguably also maybe would have been better to use Imm10s rather
than the 10u/10n scheme for ADD and similar (to not burn as much
encoding space).
Changing these at this point would break binary compatibility though. >>>>>
Well, win-some, lose some.
Qupls4
XOR Rd,Rs1,#-1
XOR_AND Rd,Rs1,#-1,#15
Thinking of dynamic instruction count density versus code density.
Not sure if to add ANDC and ORC instructions to the ISA.
Maybe swap NAND for ANDC as NAND can be synthesized:
AND_XOR Rd,Rs1,Rs2,#-1
Some useless combinations of instructions:
NAND_XOR Rd,Rs1,Rs2,#-1 sames as AND
Dunno there...
I am looking into adding some special cases:
FADD/FSUB/FMUL Rm, J_Imm16_fp16, Rn //XG1/2/3
FADD/FSUB/FMUL Rm, J_Imm32_fp64t, Rn //XG3 only
Which would add 64-bit encodings which could add either a Binary16
immediate for FPU ops (potentially encoded in all 3 ISA modes), or an
encoding representing a Binary64 value truncated to 32-bits, and
currently only may be encoded in XG3.
It is possible that there could be an Imm64_fp64 encoding, but would
also need to be XG3 only.
Partly this is because XG3 essentially has the biggest jumbo prefixes
(so can pull this off with immediate synthesis).
Could potentially also add an J_Imm16_fp16 case to RV+JX as well
(which also has immediate synthesis).
way to represent zero. The exponent is shifted by adding a bias value
to it. With S.E3.M3 the smallest exponent encoded as a zero is -3. All
zeros is 1/8 not zero. So, a special trap for zero needs to be added,
in which case 1/8 cannot be represented.
Special case logic hurts size and performance. Zero is probably used
often enough though. All those extra IF/ELSE adding priority logic.
FMUL is done as FMA (Rs1 * Rs2) + 0
Could add an explicit FMUL instruction with a 16-bit immediate.
Splitting hairs though, probably does not add enough value over FMA
with seven-bit immediates.
I repeat a suggestion I made some time ago. Why not make the 7 bits an index into a ROM that holds the 128 most used constants, whatever their values? That should allow a net reduction in instruction size (fewer longer immediates required), at minimal increased resource usage.
Robert Finch <robfi680@gmail.com> posted:There was sign control in the ISA at one point, but I removed it in
On 2026-04-09 10:09 p.m., BGB wrote:-------------------------------
On 4/9/2026 8:11 PM, MitchAlsup wrote:
Thinking of dynamic instruction count density versus code density.
Not sure if to add ANDC and ORC instructions to the ISA.
Add Operand sign control:: {- or ~} both use the same encoding bits;
if the operand passes to a unit with integer adder it gets negated,
if the operand passes to a unit without int adder it gets inverted.
Negate x = ~x+1
Invert x = ~x
so both paths get inverted and int adder paths get a carry in; this
is done at forwarding in LBIO machines, and at RS capture in GBOoO
machines.
Maybe swap NAND for ANDC as NAND can be synthesized:
AND_XOR Rd,Rs1,Rs2,#-1
deMorganize them using operand sign control::
NAND:
OR Rd,~Rs1,~Rs2
NOR:
AND Rd,~Rs1,~Rs1
This gives a very rich set of boolean-like calculations.
Some useless combinations of instructions:
NAND_XOR Rd,Rs1,Rs2,#-1 sames as AND
On 2026-04-11 10:28 a.m., Stephen Fuld wrote:
On 4/11/2026 4:32 AM, Robert Finch wrote:Yes, it is a good idea. I considered it but have not implemented it
On 2026-04-11 2:45 a.m., BGB wrote:
On 4/11/2026 12:41 AM, Robert Finch wrote:It just occurred to me, the seven-bit float immediate does not have a
On 2026-04-09 10:09 p.m., BGB wrote:
On 4/9/2026 8:11 PM, MitchAlsup wrote:
BGB <cr88192@gmail.com> posted:
On 4/9/2026 12:35 PM, MitchAlsup wrote:------------------
Had recently got some minor code density improvements in XG3, >>>>>>>> have noted:
Was trying to encode "~x" as "XOR Rs, -1, Rd", which needs a 64-bit >>>>>>>> encoding on XG3
Although rarely used, could there be an explicit COM instruction?
It needs only one (or two) register field. With a 32-bit encoding
there is 22 bits available for the opcode.
I thought about it, and looked into it, and the "breaking impact" of
changing OR and XOR from 10u to 10s seemed acceptable:
XG1/XG2: No Effect, N/E for XG1, N/A for XG2.
XG3: Only obvious effect of change was a demo desync in Heretic.
So, while it was a breaking change, it wasn't one that breaks enough
to make it a deal-breaker.
Seemingly the only case it came up was in the Gargoyle AI code.
Granted, breaking changes aren't ideal, but can maybe let this one
slide.
A had looked into disabling the ADDU.L 3RI case in BGBCC and instead
using either immediate-synthesis or 2-op sequences. Impact is "small
enough".
Doing similar for ADDS.L would not go over as well though, as it
would have a roughly 3% adverse impact on code-side. There isn't
really a good way to shrink the 10un encodings to 10s (and trying to
change behavior here would also effect XG1 and XG2).
Issue is that ADDS.L's 3RI form is used roughly 200x more often than
ADDU.L's 3RI form; so having a 3RI form of ADDU.L isn't worthwhile.
Though, ADDS.L is used roughly 10x less than ADD's 3RI form (which
is the main option that actually warrants the 10un 3RI encodings).
The main reason to consider reducing or dropping the ADDU.L and
ADDS.L encodings would be to try to free up some more of the Imm10
space.
These two operations can be done as single 48-bit instructions with >>>>> Qupls4
XOR Rd,Rs,#-1
Is a 32-bit encoding in My 66000.
But: 15 & ~x is:
AND Rd,~RS,#15
Is a 32-bit encoding, too.
In XG3, it is a 64-bit encoding because the 32-bit encoding was
Imm10u (contrast to XOR being Imm10s), but in the XG1->XG2
transition AND became signed wheres OR and XOR remained unsigned, >>>>>> because in this case negative immediate values for AND were more
common but for OR and XOR was rare, and XG3 kept the same pattern. >>>>>>
In all of these cases though, a jumbo prefix expands them to 33s.
Does mean though that the trick that RISC-V uses here is less
efficient on XG3; but I did carry over the NOT 2R instruction from >>>>>> before.
Even if, yeah, having a signed immediate would have avoided the
need to keep the NOT instruction around.
Maybe could have made them all 10s though.
Arguably also maybe would have been better to use Imm10s rather
than the 10u/10n scheme for ADD and similar (to not burn as much
encoding space).
Changing these at this point would break binary compatibility though. >>>>>>
Well, win-some, lose some.
XOR Rd,Rs1,#-1
XOR_AND Rd,Rs1,#-1,#15
Thinking of dynamic instruction count density versus code density.
Not sure if to add ANDC and ORC instructions to the ISA.
Maybe swap NAND for ANDC as NAND can be synthesized:
AND_XOR Rd,Rs1,Rs2,#-1
Some useless combinations of instructions:
NAND_XOR Rd,Rs1,Rs2,#-1 sames as AND
Dunno there...
I am looking into adding some special cases:
FADD/FSUB/FMUL Rm, J_Imm16_fp16, Rn //XG1/2/3
FADD/FSUB/FMUL Rm, J_Imm32_fp64t, Rn //XG3 only
Which would add 64-bit encodings which could add either a Binary16
immediate for FPU ops (potentially encoded in all 3 ISA modes), or
an encoding representing a Binary64 value truncated to 32-bits, and
currently only may be encoded in XG3.
It is possible that there could be an Imm64_fp64 encoding, but would
also need to be XG3 only.
Partly this is because XG3 essentially has the biggest jumbo
prefixes (so can pull this off with immediate synthesis).
Could potentially also add an J_Imm16_fp16 case to RV+JX as well
(which also has immediate synthesis).
way to represent zero. The exponent is shifted by adding a bias value
to it. With S.E3.M3 the smallest exponent encoded as a zero is -3.
All zeros is 1/8 not zero. So, a special trap for zero needs to be
added, in which case 1/8 cannot be represented.
Special case logic hurts size and performance. Zero is probably used
often enough though. All those extra IF/ELSE adding priority logic.
FMUL is done as FMA (Rs1 * Rs2) + 0
Could add an explicit FMUL instruction with a 16-bit immediate.
Splitting hairs though, probably does not add enough value over FMA
with seven-bit immediates.
I repeat a suggestion I made some time ago. Why not make the 7 bits
an index into a ROM that holds the 128 most used constants, whatever
their values? That should allow a net reduction in instruction size
(fewer longer immediates required), at minimal increased resource usage.
(yet). An issue is the ROM would need to be present for different
precisions and for multiple operands (potentially four). So, 16 copies
of ROMs. Not sure which uses fewer resources, ROM lookups or a small
format number.
I tried to think of values to store in a ROM, but could not come up with many. There is another instruction to load from a constant ROM. Had look
at some of the FP functions, and they may have too many values for a
lookup. Then there needs to be a map somewhere in the assembler. And how does one specify a value? Does the assembler look it up? What if it is specified a bit or two off? How does one identify polynomial
coefficients by ROM entry number?
Plus I am being a bit lazy. Not wanting to convert all the number in the
FP functions into binary for multiple precisions by hand.
On 2026-04-11 9:41 a.m., Thomas Koenig wrote:
Robert Finch <robfi680@gmail.com> schrieb:It is like an IEEE format. The exponent is just shifted with a bias
It just occurred to me, the seven-bit float immediate does not have a
way to represent zero. The exponent is shifted by adding a bias value to >>> it. With S.E3.M3 the smallest exponent encoded as a zero is -3. All
zeros is 1/8 not zero. So, a special trap for zero needs to be added, in >>> which case 1/8 cannot be represented.
Why not use the IEEE-like encoding, with hidden bit and special
handling of zero exponents for zeros and denorms? You can skip the
maximum exponent special handling, probably, unless you want a short
encoding for NaN.
value. Other than that the hidden bit is still there. The seven bit
value gets converted to IEEE half, single, or double depending on the precision of the operation. It is just an add to the exponent to convert
it. But it does not allow specifying numbers outside the range +/- 1/8
to +/- 16.
The operation is performed handling the usual IEEE stuff, denorms etc.
Robert Finch <robfi680@gmail.com> schrieb:
It is like an IEEE format. The exponent is just shifted with a bias
value. Other than that the hidden bit is still there. The seven bit
value gets converted to IEEE half, single, or double depending on the
precision of the operation. It is just an add to the exponent to convert
it. But it does not allow specifying numbers outside the range +/- 1/8
to +/- 16.
The operation is performed handling the usual IEEE stuff, denorms etc.
I don't understand.
With denorm bits, I get (with 3+3 bits, positive sign
only)
Thomas Koenig <tkoenig@netcologne.de> schrieb:
Robert Finch <robfi680@gmail.com> schrieb:
It is like an IEEE format. The exponent is just shifted with a bias
value. Other than that the hidden bit is still there. The seven bit
value gets converted to IEEE half, single, or double depending on the
precision of the operation. It is just an add to the exponent to convert >>> it. But it does not allow specifying numbers outside the range +/- 1/8
to +/- 16.
The operation is performed handling the usual IEEE stuff, denorms etc.
I don't understand.
With denorm bits, I get (with 3+3 bits, positive sign
only)
[...]
Ah, wait. Did you maybe overlook that, in IEEE, the hidden bit
is only set for exponent != 0? This also makes the representation
of zero as all zero bits natural.
On 2026-04-12 3:24 a.m., Thomas Koenig wrote:
Thomas Koenig <tkoenig@netcologne.de> schrieb:Yes, that is an issue with the representation I am using. The exponent cannot be zero.
Robert Finch <robfi680@gmail.com> schrieb:
It is like an IEEE format. The exponent is just shifted with a bias
value. Other than that the hidden bit is still there. The seven bit
value gets converted to IEEE half, single, or double depending on the
precision of the operation. It is just an add to the exponent to convert >>>> it. But it does not allow specifying numbers outside the range +/- 1/8 >>>> to +/- 16.
The operation is performed handling the usual IEEE stuff, denorms etc.
I don't understand.
With denorm bits, I get (with 3+3 bits, positive sign
only)
[...]
Ah, wait. Did you maybe overlook that, in IEEE, the hidden bit
is only set for exponent != 0? This also makes the representation
of zero as all zero bits natural.
Well, I was bored, so I copied all the constants from the standard C
library to a constant ROM. It just fit into 128 constants with few empty spots.
But, there are some functions that evaluate polynomials and expect a
table of constants. So, they reference the constants indirectly through
a pointer, calling _Poly(). The need for indirect constant access was revealed by studying the C library code.
I setup the constants in the constant ROM so that the tables are in
order as they are in the library code. To reference the constants indirectly, say the number of the first constant is passed in a
register, then the register can be incremented to access the next
constant. There is an unused bit available in most float instructions
that could indicate indirect constant references, but it would need to
apply to the whole instruction, forcing all constants in the instruction
to be referenced indirectly.
Code might look something like (for indirect access):
FMA Rd, fconst[Rs1], Rs2, Rs3
OR maybe
FMA Rd, #[Rs1], Rs2, Rs3
OR
FMA Rd,#1.0,Rs2,Rs3 ; for direct access
Robert Finch <robfi680@gmail.com> schrieb:
On 2026-04-12 3:24 a.m., Thomas Koenig wrote:
Thomas Koenig <tkoenig@netcologne.de> schrieb:Yes, that is an issue with the representation I am using. The exponent
Robert Finch <robfi680@gmail.com> schrieb:
It is like an IEEE format. The exponent is just shifted with a biasI don't understand.
value. Other than that the hidden bit is still there. The seven bit
value gets converted to IEEE half, single, or double depending on the >>>>> precision of the operation. It is just an add to the exponent to convert >>>>> it. But it does not allow specifying numbers outside the range +/- 1/8 >>>>> to +/- 16.
The operation is performed handling the usual IEEE stuff, denorms etc. >>>>
With denorm bits, I get (with 3+3 bits, positive sign
only)
[...]
Ah, wait. Did you maybe overlook that, in IEEE, the hidden bit
is only set for exponent != 0? This also makes the representation
of zero as all zero bits natural.
cannot be zero.
That explains things (although why you did it is unclear to me :-)
You can still special-case another exponent, though.
Well, I was bored, so I copied all the constants from the standard C
library to a constant ROM. It just fit into 128 constants with few empty
spots.
Which implementation of the C library? Could you post a list of your constants?
But, there are some functions that evaluate polynomials and expect a
table of constants. So, they reference the constants indirectly through
a pointer, calling _Poly(). The need for indirect constant access was
revealed by studying the C library code.
I setup the constants in the constant ROM so that the tables are in
order as they are in the library code. To reference the constants
indirectly, say the number of the first constant is passed in a
register, then the register can be incremented to access the next
constant. There is an unused bit available in most float instructions
that could indicate indirect constant references, but it would need to
apply to the whole instruction, forcing all constants in the instruction
to be referenced indirectly.
Code might look something like (for indirect access):
FMA Rd, fconst[Rs1], Rs2, Rs3
OR maybe
FMA Rd, #[Rs1], Rs2, Rs3
OR
FMA Rd,#1.0,Rs2,Rs3 ; for direct access
It may be better to unroll the loops, unless you are cramped for
code size.
Thomas Koenig <tkoenig@netcologne.de> schrieb:
Robert Finch <robfi680@gmail.com> schrieb:
It is like an IEEE format. The exponent is just shifted with a bias
value. Other than that the hidden bit is still there. The seven bit
value gets converted to IEEE half, single, or double depending on the
precision of the operation. It is just an add to the exponent to convert >>> it. But it does not allow specifying numbers outside the range +/- 1/8
to +/- 16.
The operation is performed handling the usual IEEE stuff, denorms etc.
I don't understand.
With denorm bits, I get (with 3+3 bits, positive sign
only)
[...]
Ah, wait. Did you maybe overlook that, in IEEE, the hidden bit
is only set for exponent != 0? This also makes the representation
of zero as all zero bits natural.
On 4/12/2026 2:24 AM, Thomas Koenig wrote:
Ah, wait. Did you maybe overlook that, in IEEE, the hidden bit
is only set for exponent != 0? This also makes the representation
of zero as all zero bits natural.
My recommendation for these sort of very-small (sub 8 bit) FP formats is
to have normal range only.
So, typically neither a zero exponent nor an Inf/NaN range.
If zero exists at all, it is a magic value (all bits zero) replacing
what otherwise would exist as the smallest value, but could argue that
for small FPU immediate values, don't likely need it at all.
On 4/11/2026 9:28 AM, Stephen Fuld wrote:
On 4/11/2026 4:32 AM, Robert Finch wrote:
On 2026-04-11 2:45 a.m., BGB wrote:
On 4/11/2026 12:41 AM, Robert Finch wrote:It just occurred to me, the seven-bit float immediate does not have a
On 2026-04-09 10:09 p.m., BGB wrote:
On 4/9/2026 8:11 PM, MitchAlsup wrote:
BGB <cr88192@gmail.com> posted:
On 4/9/2026 12:35 PM, MitchAlsup wrote:------------------
Had recently got some minor code density improvements in XG3, >>>>>>>> have noted:
Was trying to encode "~x" as "XOR Rs, -1, Rd", which needs a 64-bit >>>>>>>> encoding on XG3
Although rarely used, could there be an explicit COM instruction?
It needs only one (or two) register field. With a 32-bit encoding
there is 22 bits available for the opcode.
I thought about it, and looked into it, and the "breaking impact" of
changing OR and XOR from 10u to 10s seemed acceptable:
XG1/XG2: No Effect, N/E for XG1, N/A for XG2.
XG3: Only obvious effect of change was a demo desync in Heretic.
So, while it was a breaking change, it wasn't one that breaks enough
to make it a deal-breaker.
Seemingly the only case it came up was in the Gargoyle AI code.
Granted, breaking changes aren't ideal, but can maybe let this one
slide.
A had looked into disabling the ADDU.L 3RI case in BGBCC and instead
using either immediate-synthesis or 2-op sequences. Impact is "small
enough".
Doing similar for ADDS.L would not go over as well though, as it
would have a roughly 3% adverse impact on code-side. There isn't
really a good way to shrink the 10un encodings to 10s (and trying to
change behavior here would also effect XG1 and XG2).
Issue is that ADDS.L's 3RI form is used roughly 200x more often than
ADDU.L's 3RI form; so having a 3RI form of ADDU.L isn't worthwhile.
Though, ADDS.L is used roughly 10x less than ADD's 3RI form (which
is the main option that actually warrants the 10un 3RI encodings).
The main reason to consider reducing or dropping the ADDU.L and
ADDS.L encodings would be to try to free up some more of the Imm10
space.
These two operations can be done as single 48-bit instructions with >>>>> Qupls4
XOR Rd,Rs,#-1
Is a 32-bit encoding in My 66000.
But: 15 & ~x is:
AND Rd,~RS,#15
Is a 32-bit encoding, too.
In XG3, it is a 64-bit encoding because the 32-bit encoding was
Imm10u (contrast to XOR being Imm10s), but in the XG1->XG2
transition AND became signed wheres OR and XOR remained unsigned, >>>>>> because in this case negative immediate values for AND were more
common but for OR and XOR was rare, and XG3 kept the same pattern. >>>>>>
In all of these cases though, a jumbo prefix expands them to 33s.
Does mean though that the trick that RISC-V uses here is less
efficient on XG3; but I did carry over the NOT 2R instruction from >>>>>> before.
Even if, yeah, having a signed immediate would have avoided the
need to keep the NOT instruction around.
Maybe could have made them all 10s though.
Arguably also maybe would have been better to use Imm10s rather
than the 10u/10n scheme for ADD and similar (to not burn as much
encoding space).
Changing these at this point would break binary compatibility though. >>>>>>
Well, win-some, lose some.
XOR Rd,Rs1,#-1
XOR_AND Rd,Rs1,#-1,#15
Thinking of dynamic instruction count density versus code density.
Not sure if to add ANDC and ORC instructions to the ISA.
Maybe swap NAND for ANDC as NAND can be synthesized:
AND_XOR Rd,Rs1,Rs2,#-1
Some useless combinations of instructions:
NAND_XOR Rd,Rs1,Rs2,#-1 sames as AND
Dunno there...
I am looking into adding some special cases:
FADD/FSUB/FMUL Rm, J_Imm16_fp16, Rn //XG1/2/3
FADD/FSUB/FMUL Rm, J_Imm32_fp64t, Rn //XG3 only
Which would add 64-bit encodings which could add either a Binary16
immediate for FPU ops (potentially encoded in all 3 ISA modes), or
an encoding representing a Binary64 value truncated to 32-bits, and
currently only may be encoded in XG3.
It is possible that there could be an Imm64_fp64 encoding, but would
also need to be XG3 only.
Partly this is because XG3 essentially has the biggest jumbo
prefixes (so can pull this off with immediate synthesis).
Could potentially also add an J_Imm16_fp16 case to RV+JX as well
(which also has immediate synthesis).
way to represent zero. The exponent is shifted by adding a bias value
to it. With S.E3.M3 the smallest exponent encoded as a zero is -3.
All zeros is 1/8 not zero. So, a special trap for zero needs to be
added, in which case 1/8 cannot be represented.
Special case logic hurts size and performance. Zero is probably used
often enough though. All those extra IF/ELSE adding priority logic.
FMUL is done as FMA (Rs1 * Rs2) + 0
Could add an explicit FMUL instruction with a 16-bit immediate.
Splitting hairs though, probably does not add enough value over FMA
with seven-bit immediates.
I repeat a suggestion I made some time ago. Why not make the 7 bits
an index into a ROM that holds the 128 most used constants, whatever
their values? That should allow a net reduction in instruction size
(fewer longer immediates required), at minimal increased resource usage.
Ironically, when I tested it out before, E3.M2 vs special lookup tables,
vs ...
E3.M2 was able to get the best average hit-rate and was also cheap.
IIRC, options tested were stuff like:
E3.M2
Imm5 (1..32)
Imm5*0.1 (0.1..3.2)
...
Had noted elsewhere that is seems like the most common floating point literals fall into categories:
Integer numbers;
Int1/(2^Int2)
Int1*(10^Int2)
1.0/Int
On 2026-04-11 10:28 a.m., Stephen Fuld wrote:
On 4/11/2026 4:32 AM, Robert Finch wrote:Yes, it is a good idea. I considered it but have not implemented it
On 2026-04-11 2:45 a.m., BGB wrote:
On 4/11/2026 12:41 AM, Robert Finch wrote:It just occurred to me, the seven-bit float immediate does not have a
On 2026-04-09 10:09 p.m., BGB wrote:
On 4/9/2026 8:11 PM, MitchAlsup wrote:
BGB <cr88192@gmail.com> posted:
On 4/9/2026 12:35 PM, MitchAlsup wrote:------------------
Had recently got some minor code density improvements in XG3, >>>>>>>> have noted:
Was trying to encode "~x" as "XOR Rs, -1, Rd", which needs a 64-bit >>>>>>>> encoding on XG3
Although rarely used, could there be an explicit COM instruction?
It needs only one (or two) register field. With a 32-bit encoding
there is 22 bits available for the opcode.
I thought about it, and looked into it, and the "breaking impact" of
changing OR and XOR from 10u to 10s seemed acceptable:
XG1/XG2: No Effect, N/E for XG1, N/A for XG2.
XG3: Only obvious effect of change was a demo desync in Heretic.
So, while it was a breaking change, it wasn't one that breaks enough
to make it a deal-breaker.
Seemingly the only case it came up was in the Gargoyle AI code.
Granted, breaking changes aren't ideal, but can maybe let this one
slide.
A had looked into disabling the ADDU.L 3RI case in BGBCC and instead
using either immediate-synthesis or 2-op sequences. Impact is "small
enough".
Doing similar for ADDS.L would not go over as well though, as it
would have a roughly 3% adverse impact on code-side. There isn't
really a good way to shrink the 10un encodings to 10s (and trying to
change behavior here would also effect XG1 and XG2).
Issue is that ADDS.L's 3RI form is used roughly 200x more often than
ADDU.L's 3RI form; so having a 3RI form of ADDU.L isn't worthwhile.
Though, ADDS.L is used roughly 10x less than ADD's 3RI form (which
is the main option that actually warrants the 10un 3RI encodings).
The main reason to consider reducing or dropping the ADDU.L and
ADDS.L encodings would be to try to free up some more of the Imm10
space.
These two operations can be done as single 48-bit instructions with >>>>> Qupls4
XOR Rd,Rs,#-1
Is a 32-bit encoding in My 66000.
But: 15 & ~x is:
AND Rd,~RS,#15
Is a 32-bit encoding, too.
In XG3, it is a 64-bit encoding because the 32-bit encoding was
Imm10u (contrast to XOR being Imm10s), but in the XG1->XG2
transition AND became signed wheres OR and XOR remained unsigned, >>>>>> because in this case negative immediate values for AND were more
common but for OR and XOR was rare, and XG3 kept the same pattern. >>>>>>
In all of these cases though, a jumbo prefix expands them to 33s.
Does mean though that the trick that RISC-V uses here is less
efficient on XG3; but I did carry over the NOT 2R instruction from >>>>>> before.
Even if, yeah, having a signed immediate would have avoided the
need to keep the NOT instruction around.
Maybe could have made them all 10s though.
Arguably also maybe would have been better to use Imm10s rather
than the 10u/10n scheme for ADD and similar (to not burn as much
encoding space).
Changing these at this point would break binary compatibility though. >>>>>>
Well, win-some, lose some.
XOR Rd,Rs1,#-1
XOR_AND Rd,Rs1,#-1,#15
Thinking of dynamic instruction count density versus code density.
Not sure if to add ANDC and ORC instructions to the ISA.
Maybe swap NAND for ANDC as NAND can be synthesized:
AND_XOR Rd,Rs1,Rs2,#-1
Some useless combinations of instructions:
NAND_XOR Rd,Rs1,Rs2,#-1 sames as AND
Dunno there...
I am looking into adding some special cases:
FADD/FSUB/FMUL Rm, J_Imm16_fp16, Rn //XG1/2/3
FADD/FSUB/FMUL Rm, J_Imm32_fp64t, Rn //XG3 only
Which would add 64-bit encodings which could add either a Binary16
immediate for FPU ops (potentially encoded in all 3 ISA modes), or
an encoding representing a Binary64 value truncated to 32-bits, and
currently only may be encoded in XG3.
It is possible that there could be an Imm64_fp64 encoding, but would
also need to be XG3 only.
Partly this is because XG3 essentially has the biggest jumbo
prefixes (so can pull this off with immediate synthesis).
Could potentially also add an J_Imm16_fp16 case to RV+JX as well
(which also has immediate synthesis).
way to represent zero. The exponent is shifted by adding a bias value
to it. With S.E3.M3 the smallest exponent encoded as a zero is -3.
All zeros is 1/8 not zero. So, a special trap for zero needs to be
added, in which case 1/8 cannot be represented.
Special case logic hurts size and performance. Zero is probably used
often enough though. All those extra IF/ELSE adding priority logic.
FMUL is done as FMA (Rs1 * Rs2) + 0
Could add an explicit FMUL instruction with a 16-bit immediate.
Splitting hairs though, probably does not add enough value over FMA
with seven-bit immediates.
I repeat a suggestion I made some time ago. Why not make the 7 bits
an index into a ROM that holds the 128 most used constants, whatever
their values? That should allow a net reduction in instruction size
(fewer longer immediates required), at minimal increased resource usage.
(yet). An issue is the ROM would need to be present for different
precisions and for multiple operands (potentially four). So, 16 copies
of ROMs. Not sure which uses fewer resources, ROM lookups or a small
format number.
I tried to think of values to store in a ROM, but could not come up with many.
Thomas Koenig <tkoenig@netcologne.de> schrieb:
Robert Finch <robfi680@gmail.com> schrieb:
It is like an IEEE format. The exponent is just shifted with a bias
value. Other than that the hidden bit is still there. The seven bit
value gets converted to IEEE half, single, or double depending on the
precision of the operation. It is just an add to the exponent to convert >> it. But it does not allow specifying numbers outside the range +/- 1/8
to +/- 16.
The operation is performed handling the usual IEEE stuff, denorms etc.
I don't understand.
With denorm bits, I get (with 3+3 bits, positive sign
only)
[...]
Ah, wait. Did you maybe overlook that, in IEEE, the hidden bit
is only set for exponent != 0? This also makes the representation
of zero as all zero bits natural.
Hopefully, this will finally be the compromise I can live with.
On 4/5/2026 6:43 AM, John Dallman wrote:
In article <2026Apr5.113843@mips.complang.tuwien.ac.at>,
anton@mips.complang.tuwien.ac.at (Anton Ertl) wrote:
Why?a) it eats 3/4 of the OpCode spaceOK, that _is_ unsatisfactory.
I was making an unconscious assumption, which is probably unwarranted:
that the compressed instruction set was a fairly small subset of the full
one. If it was, then taking 3/4 of the opcode space would be quite bad.
My thinking about compressed ISAs is influenced by ARM, where T32 is a
separate mode from the A64 that I've actually used for all the ARM
platforms I've ported software to.
If the compressed instruction set has most of the operations of the
uncompressed one, but is smaller because it addresses subsets of the
registers and has smaller displacements and immediates, there's a
question of if there is a "primary" instruction set, and if so, what it
is?
Can RV-C be used standalone? No.
Is RV-C even particularly effective? No.
BGB <cr88192@gmail.com> wrote:
On 4/5/2026 6:43 AM, John Dallman wrote:
In article <2026Apr5.113843@mips.complang.tuwien.ac.at>,
anton@mips.complang.tuwien.ac.at (Anton Ertl) wrote:
Why?a) it eats 3/4 of the OpCode spaceOK, that _is_ unsatisfactory.
I was making an unconscious assumption, which is probably unwarranted:
that the compressed instruction set was a fairly small subset of the full >>> one. If it was, then taking 3/4 of the opcode space would be quite bad.
My thinking about compressed ISAs is influenced by ARM, where T32 is a
separate mode from the A64 that I've actually used for all the ARM
platforms I've ported software to.
If the compressed instruction set has most of the operations of the
uncompressed one, but is smaller because it addresses subsets of the
registers and has smaller displacements and immediates, there's a
question of if there is a "primary" instruction set, and if so, what it
is?
Can RV-C be used standalone? No.
I am not sure what you mean above. There is rv32ec subset which
can be used "standalone", that is IIUC CPU has no other instructions.
Is RV-C even particularly effective? No.
Well, GCC output on many examples shows small size. I would call
this effective.
But headers have been criticized. Maybe with a full 25% of the opcode
space cleanly freed up, I could think of a better option.
On 4/11/2026 11:01 AM, BGB wrote:
On 4/11/2026 9:28 AM, Stephen Fuld wrote:
On 4/11/2026 4:32 AM, Robert Finch wrote:
On 2026-04-11 2:45 a.m., BGB wrote:
On 4/11/2026 12:41 AM, Robert Finch wrote:It just occurred to me, the seven-bit float immediate does not have
On 2026-04-09 10:09 p.m., BGB wrote:
On 4/9/2026 8:11 PM, MitchAlsup wrote:
BGB <cr88192@gmail.com> posted:
On 4/9/2026 12:35 PM, MitchAlsup wrote:------------------
Had recently got some minor code density improvements in XG3, >>>>>>>>> have noted:
Was trying to encode "~x" as "XOR Rs, -1, Rd", which needs a >>>>>>>>> 64-bit
encoding on XG3
Although rarely used, could there be an explicit COM instruction? >>>>>> It needs only one (or two) register field. With a 32-bit encoding >>>>>> there is 22 bits available for the opcode.
I thought about it, and looked into it, and the "breaking impact"
of changing OR and XOR from 10u to 10s seemed acceptable:
XG1/XG2: No Effect, N/E for XG1, N/A for XG2.
XG3: Only obvious effect of change was a demo desync in Heretic. >>>>>
So, while it was a breaking change, it wasn't one that breaks
enough to make it a deal-breaker.
Seemingly the only case it came up was in the Gargoyle AI code.
Granted, breaking changes aren't ideal, but can maybe let this one
slide.
A had looked into disabling the ADDU.L 3RI case in BGBCC and
instead using either immediate-synthesis or 2-op sequences. Impact
is "small enough".
Doing similar for ADDS.L would not go over as well though, as it
would have a roughly 3% adverse impact on code-side. There isn't
really a good way to shrink the 10un encodings to 10s (and trying
to change behavior here would also effect XG1 and XG2).
Issue is that ADDS.L's 3RI form is used roughly 200x more often
than ADDU.L's 3RI form; so having a 3RI form of ADDU.L isn't
worthwhile.
Though, ADDS.L is used roughly 10x less than ADD's 3RI form (which
is the main option that actually warrants the 10un 3RI encodings).
The main reason to consider reducing or dropping the ADDU.L and
ADDS.L encodings would be to try to free up some more of the Imm10
space.
These two operations can be done as single 48-bit instructions
XOR Rd,Rs,#-1
Is a 32-bit encoding in My 66000.
But: 15 & ~x is:
AND Rd,~RS,#15
Is a 32-bit encoding, too.
In XG3, it is a 64-bit encoding because the 32-bit encoding was >>>>>>> Imm10u (contrast to XOR being Imm10s), but in the XG1->XG2
transition AND became signed wheres OR and XOR remained unsigned, >>>>>>> because in this case negative immediate values for AND were more >>>>>>> common but for OR and XOR was rare, and XG3 kept the same pattern. >>>>>>>
In all of these cases though, a jumbo prefix expands them to 33s. >>>>>>>
Does mean though that the trick that RISC-V uses here is less
efficient on XG3; but I did carry over the NOT 2R instruction
from before.
Even if, yeah, having a signed immediate would have avoided the >>>>>>> need to keep the NOT instruction around.
Maybe could have made them all 10s though.
Arguably also maybe would have been better to use Imm10s rather >>>>>>> than the 10u/10n scheme for ADD and similar (to not burn as much >>>>>>> encoding space).
Changing these at this point would break binary compatibility
though.
Well, win-some, lose some.
with Qupls4
XOR Rd,Rs1,#-1
XOR_AND Rd,Rs1,#-1,#15
Thinking of dynamic instruction count density versus code density. >>>>>>
Not sure if to add ANDC and ORC instructions to the ISA.
Maybe swap NAND for ANDC as NAND can be synthesized:
AND_XOR Rd,Rs1,Rs2,#-1
Some useless combinations of instructions:
NAND_XOR Rd,Rs1,Rs2,#-1 sames as AND
Dunno there...
I am looking into adding some special cases:
FADD/FSUB/FMUL Rm, J_Imm16_fp16, Rn //XG1/2/3
FADD/FSUB/FMUL Rm, J_Imm32_fp64t, Rn //XG3 only
Which would add 64-bit encodings which could add either a Binary16
immediate for FPU ops (potentially encoded in all 3 ISA modes), or
an encoding representing a Binary64 value truncated to 32-bits, and >>>>> currently only may be encoded in XG3.
It is possible that there could be an Imm64_fp64 encoding, but
would also need to be XG3 only.
Partly this is because XG3 essentially has the biggest jumbo
prefixes (so can pull this off with immediate synthesis).
Could potentially also add an J_Imm16_fp16 case to RV+JX as well
(which also has immediate synthesis).
a way to represent zero. The exponent is shifted by adding a bias
value to it. With S.E3.M3 the smallest exponent encoded as a zero is
-3. All zeros is 1/8 not zero. So, a special trap for zero needs to
be added, in which case 1/8 cannot be represented.
Special case logic hurts size and performance. Zero is probably used
often enough though. All those extra IF/ELSE adding priority logic.
FMUL is done as FMA (Rs1 * Rs2) + 0
Could add an explicit FMUL instruction with a 16-bit immediate.
Splitting hairs though, probably does not add enough value over FMA
with seven-bit immediates.
I repeat a suggestion I made some time ago. Why not make the 7 bits
an index into a ROM that holds the 128 most used constants, whatever
their values? That should allow a net reduction in instruction size
(fewer longer immediates required), at minimal increased resource usage. >>>
Ironically, when I tested it out before, E3.M2 vs special lookup
tables, vs ...
E3.M2 was able to get the best average hit-rate and was also cheap.
I presume E3.M2 gets "expanded" internally to, if it say FP added to
some FP32 bit value in a register, a 32 bit internal value. If that is true, if one picked the same 128 bit values for the internal ROM as you
get with E3.M2, you should get the same hit rate, right? Then, if there
is some value not in that list that is used more than the least used
value in the list (hard to believe there isn't such a value), you should
get get a higher "hit rate". What am I missing?
IIRC, options tested were stuff like:
E3.M2
Imm5 (1..32)
Imm5*0.1 (0.1..3.2)
...
Had noted elsewhere that is seems like the most common floating point
literals fall into categories:
Integer numbers;
Int1/(2^Int2)
Int1*(10^Int2)
1.0/Int
Nothing related to pi, e.g. pi, 1/pi, pi/2, etc.? Or perhaps e? To me that is surprising.
On 4/12/2026 12:12 PM, Stephen Fuld wrote:
Had noted elsewhere that is seems like the most common floating point
literals fall into categories:
Integer numbers;
Int1/(2^Int2)
Int1*(10^Int2)
1.0/Int
Nothing related to pi, e.g. pi, 1/pi, pi/2, etc.? Or perhaps e? To me >> that is surprising.
One might expect these, but statistically, they seem uncommon.
Seemingly one is more likely to encounter constants like 5/8 or 3/16, or
a "ye olde" integer, than they are to encounter something like M_PI or M_E.
Granted, could need to analyze a lot more code to get a more general consensus here.
As for why it seems like "socket wrench" style sizes are more common
than, say things like "0.1" and similar, I don't know.
But I still need to do one more thing. In order to make it even worth continuing, after deleting the two code formats that I've found to be superfluous, I need to bring in something better that includes what I've tried to add with one of those code formats in a better way.
BGB <cr88192@gmail.com> schrieb:
On 4/12/2026 12:12 PM, Stephen Fuld wrote:
Had noted elsewhere that is seems like the most common floating point
literals fall into categories:
Integer numbers;
Int1/(2^Int2)
Int1*(10^Int2)
1.0/Int
Nothing related to pi, e.g. pi, 1/pi, pi/2, etc.? Or perhaps e? To me >>> that is surprising.
One might expect these, but statistically, they seem uncommon.
This is *very* much a function of the programs you are looking at.
Is anything related to scientific or engineering calculation in
your sample?
Seemingly one is more likely to encounter constants like 5/8 or 3/16, or
a "ye olde" integer, than they are to encounter something like M_PI or M_E. >>
Granted, could need to analyze a lot more code to get a more general
consensus here.
Very much so. Regarding floating point, there is no such thing as a "typical" application. People who have access to SPEC might have a
better overview.
As for why it seems like "socket wrench" style sizes are more common
than, say things like "0.1" and similar, I don't know.
Socket wrench?
BGB <cr88192@gmail.com> schrieb:
On 4/12/2026 12:12 PM, Stephen Fuld wrote:
Had noted elsewhere that is seems like the most common floating point
literals fall into categories:
Integer numbers;
Int1/(2^Int2)
Int1*(10^Int2)
1.0/Int
Nothing related to pi, e.g. pi, 1/pi, pi/2, etc.? Or perhaps e? To me >>> that is surprising.
One might expect these, but statistically, they seem uncommon.
This is *very* much a function of the programs you are looking at.
Is anything related to scientific or engineering calculation in
your sample?
Seemingly one is more likely to encounter constants like 5/8 or 3/16, or
a "ye olde" integer, than they are to encounter something like M_PI or M_E. >>
Granted, could need to analyze a lot more code to get a more general
consensus here.
Very much so. Regarding floating point, there is no such thing as a "typical" application. People who have access to SPEC might have a
better overview.
As for why it seems like "socket wrench" style sizes are more common
than, say things like "0.1" and similar, I don't know.
Socket wrench?
On 2026-04-13 5:11 p.m., Thomas Koenig wrote:---------------
BGB <cr88192@gmail.com> schrieb:
Socket wrench?
Socket wrenches come in weird sizes like 1/2, 1/4 inch, but metric is
used nowadays.
It could be that what might seem to be common constants are simply well known and not used that often. Constants like PI and PI by two may be
used implementing trig functions, but they are only used a few times in
the math library. Their dynamic usage may be very high, but how often do they appear statically in code? While some app may use the sin()
function very often, the constants associated with it are specified only once inside the function.
Putting together the constant ROM I could not see how some of the
constants would be very useful outside of specific functions. But IDK.
Other constants like 1.0, 2.0, 0.5 are used many times.
It may be important enough to support some rarely used constants with a constant table to reduce errors. Getting a value like PI, e, or LN2
wrong could be bad.
*****
For q+ having a constant ROM available for every source operand resulted
in a design that would not route. Too much congestion. So, the first
source operand no longer has the constant ROM available. It would not
have been very useful anyway. Most of the time one wants to perform an
op of a variable with a constant.
*****
Thinking of adding a POLY instruction to the ISA. I note the VAX POLY() loads the coefficients from memory. But there are a lot of register available for Q+. A load multiple registers followed by the POLY() would
do the same thing. The other thing is a limited number of co-efficients.
VAX allows 31, but Q+ would be limited to 15.
POLY Rd, Rs1, Rs2, #n
Rs1 contains 'X'
Rs2 identifies the first register of a table of registers containing coefficients. OR
The Rs2 field identifies the first coefficient in the constant ROM
lookup table.
#n is the degree
It would be able to evaluate POLYs with up to 15 co-efficients using Homer’s method.
Robert Finch <robfi680@gmail.com> posted:
On 2026-04-13 5:11 p.m., Thomas Koenig wrote:---------------
BGB <cr88192@gmail.com> schrieb:
Socket wrenches come in weird sizes like 1/2, 1/4 inch, but metric is
Socket wrench?
used nowadays.
Socket wrenches go as small as step sizes of 1/64 and 0.25mm
Smaller than step sizes of 1/32 are rare, with 1/16 quite common.
It could be that what might seem to be common constants are simply well
known and not used that often. Constants like PI and PI by two may be
used implementing trig functions, but they are only used a few times in
the math library. Their dynamic usage may be very high, but how often do
they appear statically in code? While some app may use the sin()
function very often, the constants associated with it are specified only
once inside the function.
Putting together the constant ROM I could not see how some of the
constants would be very useful outside of specific functions. But IDK.
Other constants like 1.0, 2.0, 0.5 are used many times.
It may be important enough to support some rarely used constants with a
constant table to reduce errors. Getting a value like PI, e, or LN2
wrong could be bad.
*****
For q+ having a constant ROM available for every source operand resulted
in a design that would not route. Too much congestion. So, the first
source operand no longer has the constant ROM available. It would not
have been very useful anyway. Most of the time one wants to perform an
op of a variable with a constant.
*****
Thinking of adding a POLY instruction to the ISA. I note the VAX POLY()
loads the coefficients from memory. But there are a lot of register
available for Q+. A load multiple registers followed by the POLY() would
do the same thing. The other thing is a limited number of co-efficients.
VAX allows 31, but Q+ would be limited to 15.
POLY Rd, Rs1, Rs2, #n
Rs1 contains 'X'
Rs2 identifies the first register of a table of registers containing
coefficients. OR
The Rs2 field identifies the first coefficient in the constant ROM
lookup table.
#n is the degree
It would be able to evaluate POLYs with up to 15 co-efficients using
Homer’s method.
This depends::
When constants are in some kind of ROM associated with the polynomial evaluation unit, lookup time is free, and the bits of precision does
not have to match IEEE register sizes. By using as little as 3 more
bits of precision, one can often save a) an evaluation iteration or
b) special step after polynomial and before rounding.
Secondarily: Horner's method, while numerically stable, you often end
up performing at 1/2 FMAC capabilities because you have to wait for
the previous multiply to fall out the bottom of the multiplier. If,
instead, you use simple power-series, you can perform the x^n in odd
cycles, and (x^(n-1))×C in even cycles, nearly doubling perf. You can shorten the higher order terms in the ROM without losing precision.
Thirdly, do yourself a favor and use Chebyshev polynomials or Remes improvements on Chebyshev polynomial coefficients.
Forth, by stretching out the Chebyshev interval, you can minimize
the error at the endpoints of intervals, and avoid special cases.
I, personally, would not add a POLY instruction, but have added most
of the elementary transcendental functions to ISA. It is a delicate
balance.
Also note: if you look at the coefficients of SIN() and COS(), you will
find the coefficients you need for EXP() in the range [1..2)
I will have to think more about how to implement power series -
factoring out the X. Is it possible to modify Horner's method so that
there are two terms evaluated? Factoring out x^2 instead of x?
Thirdly, do yourself a favor and use Chebyshev polynomials or Remes
improvements on Chebyshev polynomial coefficients.
Forth, by stretching out the Chebyshev interval, you can minimize
the error at the endpoints of intervals, and avoid special cases.
Robert Finch <robfi680@gmail.com> posted:
On 2026-04-13 5:11 p.m., Thomas Koenig wrote:---------------
BGB <cr88192@gmail.com> schrieb:
Socket wrenches come in weird sizes like 1/2, 1/4 inch, but metric is
Socket wrench?
used nowadays.
Socket wrenches go as small as step sizes of 1/64 and 0.25mm
Smaller than step sizes of 1/32 are rare, with 1/16 quite common.
It could be that what might seem to be common constants are simply well
known and not used that often. Constants like PI and PI by two may be
used implementing trig functions, but they are only used a few times in
the math library. Their dynamic usage may be very high, but how often do
they appear statically in code? While some app may use the sin()
function very often, the constants associated with it are specified only
once inside the function.
Putting together the constant ROM I could not see how some of the
constants would be very useful outside of specific functions. But IDK.
Other constants like 1.0, 2.0, 0.5 are used many times.
It may be important enough to support some rarely used constants with a
constant table to reduce errors. Getting a value like PI, e, or LN2
wrong could be bad.
*****
For q+ having a constant ROM available for every source operand resulted
in a design that would not route. Too much congestion. So, the first
source operand no longer has the constant ROM available. It would not
have been very useful anyway. Most of the time one wants to perform an
op of a variable with a constant.
*****
Thinking of adding a POLY instruction to the ISA. I note the VAX POLY()
loads the coefficients from memory. But there are a lot of register
available for Q+. A load multiple registers followed by the POLY() would
do the same thing. The other thing is a limited number of co-efficients.
VAX allows 31, but Q+ would be limited to 15.
POLY Rd, Rs1, Rs2, #n
Rs1 contains 'X'
Rs2 identifies the first register of a table of registers containing
coefficients. OR
The Rs2 field identifies the first coefficient in the constant ROM
lookup table.
#n is the degree
It would be able to evaluate POLYs with up to 15 co-efficients using
Homer’s method.
This depends::
When constants are in some kind of ROM associated with the polynomial evaluation unit, lookup time is free, and the bits of precision does
not have to match IEEE register sizes. By using as little as 3 more
bits of precision, one can often save a) an evaluation iteration or
b) special step after polynomial and before rounding.
Secondarily: Horner's method, while numerically stable, you often end
up performing at 1/2 FMAC capabilities because you have to wait for
the previous multiply to fall out the bottom of the multiplier. If,
instead, you use simple power-series, you can perform the x^n in odd
cycles, and (x^(n-1))×C in even cycles, nearly doubling perf. You can shorten the higher order terms in the ROM without losing precision.
Thirdly, do yourself a favor and use Chebyshev polynomials or Remes improvements on Chebyshev polynomial coefficients.
Forth, by stretching out the Chebyshev interval, you can minimize
the error at the endpoints of intervals, and avoid special cases.
I, personally, would not add a POLY instruction, but have added most
of the elementary transcendental functions to ISA. It is a delicate
balance.
Also note: if you look at the coefficients of SIN() and COS(), you will
find the coefficients you need for EXP() in the range [1..2)
On 4/13/2026 8:19 PM, MitchAlsup wrote:
Robert Finch <robfi680@gmail.com> posted:
On 2026-04-13 5:11 p.m., Thomas Koenig wrote:---------------
BGB <cr88192@gmail.com> schrieb:
Socket wrenches come in weird sizes like 1/2, 1/4 inch, but metric is
Socket wrench?
used nowadays.
Socket wrenches go as small as step sizes of 1/64 and 0.25mm
Smaller than step sizes of 1/32 are rare, with 1/16 quite common.
Yeah, somehow I would have thought pretty much everyone would be
familiar with them and with the system of fractions for defining sizes
for things...
But, can't make too many assumptions it seems.
It is possible other parts of the world use other technologies, but at
least in the US and similar, have usually encountered these.
For most uses, things are defined in units of 1/16 or 1/32 with the
fraction then reduced to lowest terms, so, say:
1/16, 1/8, 3/16, 1/4, 5/16, 3/8, 7/16, 1/2, 9/16, 5/8, 11/16, 3/4,
13/16, 7/8, 15/16
BGB <cr88192@gmail.com> schrieb:
On 4/13/2026 8:19 PM, MitchAlsup wrote:
Robert Finch <robfi680@gmail.com> posted:
On 2026-04-13 5:11 p.m., Thomas Koenig wrote:---------------
BGB <cr88192@gmail.com> schrieb:
Socket wrenches come in weird sizes like 1/2, 1/4 inch, but metric is
Socket wrench?
used nowadays.
Socket wrenches go as small as step sizes of 1/64 and 0.25mm
Smaller than step sizes of 1/32 are rare, with 1/16 quite common.
Yeah, somehow I would have thought pretty much everyone would be
familiar with them and with the system of fractions for defining sizes
for things...
Look at my e-mail address and consider which countries use
which measuring system. For your amusement, you can also watch https://www.youtube.com/watch?v=JYqfVE-fykk :-)
But, can't make too many assumptions it seems.
I was thrown off by the measurements in inches.
[...]
It is possible other parts of the world use other technologies, but at
least in the US and similar, have usually encountered these.
For most uses, things are defined in units of 1/16 or 1/32 with the
fraction then reduced to lowest terms, so, say:
1/16, 1/8, 3/16, 1/4, 5/16, 3/8, 7/16, 1/2, 9/16, 5/8, 11/16, 3/4,
13/16, 7/8, 15/16
Most people outside the US just use mm. The UK is sort of
fluctuating, they still have their distances in miles.
But of course, the UK (or Imperial) gallon is different from
the US gallon.
On 4/14/2026 1:00 AM, Thomas Koenig wrote:
BGB <cr88192@gmail.com> schrieb:
On 4/13/2026 8:19 PM, MitchAlsup wrote:
Robert Finch <robfi680@gmail.com> posted:
On 2026-04-13 5:11 p.m., Thomas Koenig wrote:---------------
BGB <cr88192@gmail.com> schrieb:
Socket wrenches come in weird sizes like 1/2, 1/4 inch, but metric is >>>>> used nowadays.
Socket wrench?
Socket wrenches go as small as step sizes of 1/64 and 0.25mm
Smaller than step sizes of 1/32 are rare, with 1/16 quite common.
Yeah, somehow I would have thought pretty much everyone would be
familiar with them and with the system of fractions for defining sizes
for things...
Look at my e-mail address and consider which countries use
which measuring system. For your amusement, you can also watch
https://www.youtube.com/watch?v=JYqfVE-fykk :-)
So Germany doesn't also use SAE for screws and bolts?...
Or, have the same thing of building machines where half the screws are
SAE and half are Metric.
If not, are hex-head bolts still dominant, or is it like places where in
the US one would use a hex-head bolt or Allen-key screw they use Torx or similar?...
Then again, I guess if anything I would expect things like machines to
be similar, as most of the machines are presumably still made in China,
and it would be weird to expect China to make different stuff based on
what country they intend to sell it in.
But, then again, I have heard there are sometimes issues, like a lot of Chinese-made machines use copper-clad-aluminum wire, which is apparently illegal in places like Australia, ...
Well, and I guess in the US, there are a lot of people who don't approve
of aluminum and CCA wiring, but generally still allowed (though CCA is
kinda annoying to solder as it can often foul up the tip on the
soldering iron and/or form an amalgam with the solder which can't really
be re-melted when if forms).
But, yeah, I guess it is also sort of like in video games the units are
more ad-hoc, just whatever is most convenient at the time.
Though, in a lot of my 3D engines, this has been to use the meter as the base unit, but then define an "inch" as 1/32 of a meter; then just be
like "whatever, close enough". Apparently fairly close to the old French Inch though.
In some cases, can make sense to have a cubit as 1/2 "meter", or "foot"
as 1/3.
But, can't make too many assumptions it seems.
I was thrown off by the measurements in inches.
OK.
We have mm stuff as well, but it is less commonly used than inch stuff.
Tools and CNC machines pretty much exclusively use inches though.
[...]
It is possible other parts of the world use other technologies, but at
least in the US and similar, have usually encountered these.
For most uses, things are defined in units of 1/16 or 1/32 with the
fraction then reduced to lowest terms, so, say:
1/16, 1/8, 3/16, 1/4, 5/16, 3/8, 7/16, 1/2, 9/16, 5/8, 11/16, 3/4,
13/16, 7/8, 15/16
Most people outside the US just use mm. The UK is sort of
fluctuating, they still have their distances in miles.
AFAIK, UK also measures things in chains/rods/furlongs/hands/etc,
weights in stone, ?... It is weird hearing UK people give measurements
as they often use neither the common US units nor metric.
Vs Us being like inch/foot/mile/etc, and weight in pounds, ...
Well, and yards, for things like fabric and sports fields, except on TV shows where they use the football fields as a unit of length, and
swimming pools as a unit of volume, ...
But of course, the UK (or Imperial) gallon is different from
the US gallon.
Most places I have lived have been at least US adjacent.
So, yeah, liter vs gallon depends on what you are measuring.
ounce is usually limited to drink sizes;
pint is usually limited to things like milk cartons.
Where in US, milk comes either in cardboard cartons or gallon jugs.
I guess elsewhere in the world, they sell it in plastic bags.
Likewise for temperatures in F vs C, ...
F for weather and cooking and similar;
C for other uses (CPU temp, 3D printing, ...).
The Type III header
was modified so that the unrestricted memory-reference operate
instructions could be 35 bits long instead of 34 bits long.
Robert Finch <robfi680@gmail.com> schrieb:
I will have to think more about how to implement power series -
factoring out the X. Is it possible to modify Horner's method so that
there are two terms evaluated? Factoring out x^2 instead of x?
See https://en.wikipedia.org/wiki/Polynomial_evaluation for a
few methods.
[Mitch had written]
Thirdly, do yourself a favor and use Chebyshev polynomials or Remes
improvements on Chebyshev polynomial coefficients.
Yes.
Forth, by stretching out the Chebyshev interval, you can minimize
the error at the endpoints of intervals, and avoid special cases.
Again, yes.
On 4/13/2026 8:19 PM, MitchAlsup wrote:
Robertson screws:
Like Allen except square rather than hexagon;
Rarely used.
On 4/14/2026 1:00 AM, Thomas Koenig wrote:..
BGB <cr88192@gmail.com> schrieb:
Look at my e-mail address and consider which countries use
which measuring system. For your amusement, you can also watch
https://www.youtube.com/watch?v=JYqfVE-fykk :-)
So Germany doesn't also use SAE for screws and bolts?...
On 2026-04-14 4:09 a.m., BGB wrote:
I was in the doughnut store the other day and asked for a dozen
doughnuts. The cashier seriously asked me what a dozen was. So, I asked
for 10 doughnuts instead, rather than try and explain.
But, yeah, for a lot of things, they are held together by large screws
that we call bolts,
If not, are hex-head bolts still dominant, or is it like places where in
the US one would use a hex-head bolt or Allen-key screw they use Torx or similar?...
Actually, they're the most commonly used screws in my household.
On 4/14/2026 1:00 AM, Thomas Koenig wrote:
BGB <cr88192@gmail.com> schrieb:
On 4/13/2026 8:19 PM, MitchAlsup wrote:
Robert Finch <robfi680@gmail.com> posted:
On 2026-04-13 5:11 p.m., Thomas Koenig wrote:---------------
BGB <cr88192@gmail.com> schrieb:
Socket wrenches come in weird sizes like 1/2, 1/4 inch, but metric is >>>>> used nowadays.
Socket wrench?
Socket wrenches go as small as step sizes of 1/64 and 0.25mm
Smaller than step sizes of 1/32 are rare, with 1/16 quite common.
Yeah, somehow I would have thought pretty much everyone would be
familiar with them and with the system of fractions for defining sizes
for things...
Look at my e-mail address and consider which countries use
which measuring system. For your amusement, you can also watch
https://www.youtube.com/watch?v=JYqfVE-fykk :-)
So Germany doesn't also use SAE for screws and bolts?...
Or, have the same thing of building machines where half the screws are
SAE and half are Metric.
If not, are hex-head bolts still dominant, or is it like places where in
the US one would use a hex-head bolt or Allen-key screw they use Torx or similar?...
Then again, I guess if anything I would expect things like machines to
be similar, as most of the machines are presumably still made in China,
and it would be weird to expect China to make different stuff based on
what country they intend to sell it in.
But, then again, I have heard there are sometimes issues, like a lot of Chinese-made machines use copper-clad-aluminum wire, which is apparently illegal in places like Australia, ...
Well, and I guess in the US, there are a lot of people who don't approve
of aluminum and CCA wiring, but generally still allowed (though CCA is
kinda annoying to solder as it can often foul up the tip on the
soldering iron and/or form an amalgam with the solder which can't really
be re-melted when if forms).
But, yeah, I guess it is also sort of like in video games the units are
more ad-hoc, just whatever is most convenient at the time.
Though, in a lot of my 3D engines, this has been to use the meter as the base unit, but then define an "inch" as 1/32 of a meter; then just be
like "whatever, close enough". Apparently fairly close to the old French Inch though.
In some cases, can make sense to have a cubit as 1/2 "meter", or "foot"
as 1/3.
But, can't make too many assumptions it seems.
I was thrown off by the measurements in inches.
OK.
We have mm stuff as well, but it is less commonly used than inch stuff.
Tools and CNC machines pretty much exclusively use inches though.
On Tue, 14 Apr 2026 14:30:30 +0000, Scott Lurndal wrote:
Actually, they're the most commonly used screws in my household.
I take it you're also a Canadian.
Their very existence is unknown to the average American.
On 4/13/2026 8:19 PM, MitchAlsup wrote:Point of Order
Robert Finch <robfi680@gmail.com> posted:
On 2026-04-13 5:11 p.m., Thomas Koenig wrote:---------------
BGB <cr88192@gmail.com> schrieb:
But, yeah, for a lot of things, they are held together by large screws
that we call bolts, which either screw into a threaded hole, or are held
in place by a "nut" that threads on the other end.
BGB <cr88192@gmail.com> schrieb:---------------------
On 4/13/2026 8:19 PM, MitchAlsup wrote:
1/16, 1/8, 3/16, 1/4, 5/16, 3/8, 7/16, 1/2, 9/16, 5/8, 11/16, 3/4,
13/16, 7/8, 15/16
Most people outside the US just use mm. The UK is sort of
fluctuating, they still have their distances in miles.
But of course, the UK (or Imperial) gallon is different from--- Synchronet 3.21f-Linux NewsLink 1.2
the US gallon.
Thomas Koenig <tkoenig@netcologne.de> posted:
BGB <cr88192@gmail.com> schrieb:---------------------
On 4/13/2026 8:19 PM, MitchAlsup wrote:
1/16, 1/8, 3/16, 1/4, 5/16, 3/8, 7/16, 1/2, 9/16, 5/8, 11/16, 3/4,
13/16, 7/8, 15/16
Most people outside the US just use mm. The UK is sort of
fluctuating, they still have their distances in miles.
Why is it that people using the metric system will drive a thousand kilometers instead of one megameter ??
You can't have it both ways !!
On 4/14/2026 1:00 AM, Thomas Koenig wrote:-----------------------------
BGB <cr88192@gmail.com> schrieb:
On 4/13/2026 8:19 PM, MitchAlsup wrote:
Look at my e-mail address and consider which countries use
which measuring system. For your amusement, you can also watch https://www.youtube.com/watch?v=JYqfVE-fykk :-)
So Germany doesn't also use SAE for screws and bolts?...
Or, have the same thing of building machines where half the screws are
SAE and half are Metric.
If not, are hex-head bolts still dominant, or is it like places where in
the US one would use a hex-head bolt or Allen-key screw they use Torx or similar?...
Then again, I guess if anything I would expect things like machines to
be similar, as most of the machines are presumably still made in China,
and it would be weird to expect China to make different stuff based on
what country they intend to sell it in.
But, then again, I have heard there are sometimes issues, like a lot of Chinese-made machines use copper-clad-aluminum wire, which is apparently illegal in places like Australia, ...
On 2026-04-14 4:09 a.m., BGB wrote:-------------------
On 4/14/2026 1:00 AM, Thomas Koenig wrote:
BGB <cr88192@gmail.com> schrieb:
On 4/13/2026 8:19 PM, MitchAlsup wrote:
We were just converting to the metric system when I was in public
school, so I had to learn two systems. I am pretty fluent in both, but I have forgotten some of the US measurements. I still like to see the temperature in Fahrenheit.
I was in the doughnut store the other day and asked for a dozen
doughnuts. The cashier seriously asked me what a dozen was. So, I asked
for 10 doughnuts instead, rather than try and explain.
On Mon, 13 Apr 2026 21:37:14 +0000, quadi wrote:
The Type III header
was modified so that the unrestricted memory-reference operate
instructions could be 35 bits long instead of 34 bits long.
Either the serendipity - or the operation of Parkinson's Law - continues.
The same mechanism used to expand the 34-bit instructions to 35 bits, so that they can have a condition code bit and no addressing mode--- Synchronet 3.21f-Linux NewsLink 1.2
restrictions, is now also used to provide a full alternate 32-bit instruction set.
This allows putting improved versions of the multiple-register load/store instructions, and the supplemental load/store instructions for additional data types, in a 32-bit slot instead of needing to use 48-bit instructions for the purpose.
Of course, completing the 32-bit instruction set in this manner still requires the overhead of a 48-bit block header. So it might well be asked
if there is "really" a savings. But the 48-bit instructions also require a header that is at least 32 bits long.
John Savard
On 2026-04-14 1:31 a.m., Thomas Koenig wrote:
Robert Finch <robfi680@gmail.com> schrieb:
I will have to think more about how to implement power series -
factoring out the X. Is it possible to modify Horner's method so that
there are two terms evaluated? Factoring out x^2 instead of x?
See https://en.wikipedia.org/wiki/Polynomial_evaluation for a
few methods.
[Mitch had written]
I hit upon Estrin's scheme myself writing things out. I did not quite
follow Mitch's suggestion though.
Thirdly, do yourself a favor and use Chebyshev polynomials or Remes
improvements on Chebyshev polynomial coefficients.
Yes.
Forth, by stretching out the Chebyshev interval, you can minimize
the error at the endpoints of intervals, and avoid special cases.
Again, yes.
Okay.
On Tue, 14 Apr 2026 03:09:55 -0500, BGB wrote:
If not, are hex-head bolts still dominant, or is it like places where in the US one would use a hex-head bolt or Allen-key screw they use Torx or similar?...
When Torx came out, people where I live were scratching their heads why people would use an expensive proprietary kind of screwdriver, when Robertson was available to do exactly the same job.
But apparently in the United States, the Robertson screwdriver is practically unknown.--- Synchronet 3.21f-Linux NewsLink 1.2
Robertson uses a screwdriver with a square tip.
John Savard
On Tue, 14 Apr 2026 14:30:30 +0000, Scott Lurndal wrote:
Actually, they're the most commonly used screws in my household.
I take it you're also a Canadian. Their very existence is unknown to the average American.
John Savard
Robert Finch <robfi680@gmail.com> posted:
On 2026-04-14 4:09 a.m., BGB wrote:-------------------
On 4/14/2026 1:00 AM, Thomas Koenig wrote:
BGB <cr88192@gmail.com> schrieb:
On 4/13/2026 8:19 PM, MitchAlsup wrote:
We were just converting to the metric system when I was in public
school, so I had to learn two systems. I am pretty fluent in both, but I
have forgotten some of the US measurements. I still like to see the
temperature in Fahrenheit.
Multiply or Divide by 25.4 or 39.36 for units of length
quadi <quadibloc@ca.invalid> posted:
On Tue, 14 Apr 2026 03:09:55 -0500, BGB wrote:
If not, are hex-head bolts still dominant, or is it like places where in >> > the US one would use a hex-head bolt or Allen-key screw they use Torx or >> > similar?...
When Torx came out, people where I live were scratching their heads why
people would use an expensive proprietary kind of screwdriver, when
Robertson was available to do exactly the same job.
Originally, Torx was used in situations where malicious actors were
present {restrooms} and they wanted a driver that was not in general
use {already}
MitchAlsup <user5857@newsgrouper.org.invalid> writes:
quadi <quadibloc@ca.invalid> posted:
On Tue, 14 Apr 2026 03:09:55 -0500, BGB wrote:
If not, are hex-head bolts still dominant, or is it like places where in >> > the US one would use a hex-head bolt or Allen-key screw they use Torx or >> > similar?...
When Torx came out, people where I live were scratching their heads why >> people would use an expensive proprietary kind of screwdriver, when
Robertson was available to do exactly the same job.
Originally, Torx was used in situations where malicious actors were
present {restrooms} and they wanted a driver that was not in general
use {already}
There two torx head patterns. The security version has a pin
in the middle of the head, which requires a matching socket on
the driver.
That said, driver bits for security torx are widely available.
On Tue, 14 Apr 2026 00:51:56 -0500, BGB wrote:
But, yeah, for a lot of things, they are held together by large screws
that we call bolts,
Of course, wood screws differ from bolts, in that they are pointy so that they can go where there are no holes.
But what most people call bolts are indeed another kind of screw; I've
seen them also referred to as "machine screws". Presumably that's their official or correct name among professionals.
John Savard
quadi <quadibloc@ca.invalid> posted:
On Tue, 14 Apr 2026 14:30:30 +0000, Scott Lurndal wrote:
Actually, they're the most commonly used screws in my household.
I take it you're also a Canadian. Their very existence is unknown to the
average American.
Can you name the 7-types of thread without using a manual ??
BGB <cr88192@gmail.com> schrieb:
On 4/14/2026 1:00 AM, Thomas Koenig wrote:
BGB <cr88192@gmail.com> schrieb:
On 4/13/2026 8:19 PM, MitchAlsup wrote:
Robert Finch <robfi680@gmail.com> posted:
On 2026-04-13 5:11 p.m., Thomas Koenig wrote:---------------
BGB <cr88192@gmail.com> schrieb:
Socket wrenches come in weird sizes like 1/2, 1/4 inch, but metric is >>>>>> used nowadays.
Socket wrench?
Socket wrenches go as small as step sizes of 1/64 and 0.25mm
Smaller than step sizes of 1/32 are rare, with 1/16 quite common.
Yeah, somehow I would have thought pretty much everyone would be
familiar with them and with the system of fractions for defining sizes >>>> for things...
Look at my e-mail address and consider which countries use
which measuring system. For your amusement, you can also watch
https://www.youtube.com/watch?v=JYqfVE-fykk :-)
So Germany doesn't also use SAE for screws and bolts?...
Not sure what SAE prescribes. Is that Imperial? Germany (like
almost everybody else) use ISO, which is metric. An M6 screw,
for example, has a nominal outer diameter of 6 mm. Screw heads
are also ISO.
Or, have the same thing of building machines where half the screws are
SAE and half are Metric.
You will be hard pressed to find inch-based screws and bolts in
the EU, this is entirely metric. The only exception is Withworth
threads, which are still used for piping in houses. Of course,
these only bear a passing resemblance to their nominal diameter
because of $REASONS.
If not, are hex-head bolts still dominant, or is it like places where in
the US one would use a hex-head bolt or Allen-key screw they use Torx or
similar?...
Really depends on the application. Screws come in a variety of heads.
For bolts, hexagonal is dominant.
Then again, I guess if anything I would expect things like machines to
be similar, as most of the machines are presumably still made in China,
and it would be weird to expect China to make different stuff based on
what country they intend to sell it in.
I believe China looked around for their standards a few decades ago,
and decided to base theirs on DIN (the German one).
But, then again, I have heard there are sometimes issues, like a lot of
Chinese-made machines use copper-clad-aluminum wire, which is apparently
illegal in places like Australia, ...
Well, and I guess in the US, there are a lot of people who don't approve
of aluminum and CCA wiring, but generally still allowed (though CCA is
kinda annoying to solder as it can often foul up the tip on the
soldering iron and/or form an amalgam with the solder which can't really
be re-melted when if forms).
I don't think aluminium wiring is allowed in Germany. I have certainly
never seen it, also not in old houses.
But, yeah, I guess it is also sort of like in video games the units are
more ad-hoc, just whatever is most convenient at the time.
Though, in a lot of my 3D engines, this has been to use the meter as the
base unit, but then define an "inch" as 1/32 of a meter; then just be
like "whatever, close enough". Apparently fairly close to the old French
Inch though.
An inch is 25.4 mm, 1m/32 is 31.25 mm, that is a rather big
deviation. But then again, pi equals 3 for small values of pi
and large values of 3...
In some cases, can make sense to have a cubit as 1/2 "meter", or "foot"
as 1/3.
But, can't make too many assumptions it seems.
I was thrown off by the measurements in inches.
OK.
We have mm stuff as well, but it is less commonly used than inch stuff.
Tools and CNC machines pretty much exclusively use inches though.
Not so long ago, I was standing in a workshop in the US and asking
for a caliper in mm. They had one, but it took them some time to
find it :-)
[...]
quadi <quadibloc@ca.invalid> posted:[on]
Either the serendipity - or the operation of Parkinson's Law -
continues.
I am betting
Parkinson's...
MitchAlsup <user5857@newsgrouper.org.invalid> schrieb:
quadi <quadibloc@ca.invalid> posted:
On Tue, 14 Apr 2026 14:30:30 +0000, Scott Lurndal wrote:
Actually, they're the most commonly used screws in my household.
I take it you're also a Canadian. Their very existence is unknown to the >> average American.
Can you name the 7-types of thread without using a manual ??
M2 M3 M4 M5 M6 M8 M10
:-)
Sometimes, people have guns that are full auto. These are not usually
legal to have,
BGB <cr88192@gmail.com> posted:
----------------------
Sometimes, people have guns that are full auto. These are not usually
legal to have,
If you fill out the right forms, fill in the right paperwork, pay the
tax stamp cost, and wait through Sheriff interviews, and wait the ~18
months, you can legally own a fully automatic firearm.
One should also note: in the history of this system (~late 1930s)
to present: only 2 properly registered FA guns have been used in
any crimes. {Anyone with a brain would say this is a pretty good
record}
If you fill out the right forms, fill in the right paperwork, pay the
tax stamp cost, and wait through Sheriff interviews, and wait the ~18
months, you can legally own a fully automatic firearm.
One should also note: in the history of this system (~late 1930s)
to present: only 2 properly registered FA guns have been used in
any crimes. {Anyone with a brain would say this is a pretty good
record}
quadi <quadibloc@ca.invalid> posted:
On Mon, 13 Apr 2026 21:37:14 +0000, quadi wrote:
The Type III header
was modified so that the unrestricted memory-reference operate
instructions could be 35 bits long instead of 34 bits long.
Either the serendipity - or the operation of Parkinson's Law - continues.
I am betting of Parkinson's...
The same mechanism used to expand the 34-bit instructions to 35 bits, so
that they can have a condition code bit and no addressing mode
restrictions, is now also used to provide a full alternate 32-bit
instruction set.
This allows putting improved versions of the multiple-register load/store
instructions, and the supplemental load/store instructions for additional
data types, in a 32-bit slot instead of needing to use 48-bit instructions >> for the purpose.
Of course, completing the 32-bit instruction set in this manner still
requires the overhead of a 48-bit block header. So it might well be asked
if there is "really" a savings. But the 48-bit instructions also require a >> header that is at least 32 bits long.
John Savard
scott@slp53.sl.home (Scott Lurndal) posted:
MitchAlsup <user5857@newsgrouper.org.invalid> writes:New bolt heads designed for security are viable for <generally> less
quadi <quadibloc@ca.invalid> posted:
On Tue, 14 Apr 2026 03:09:55 -0500, BGB wrote:
If not, are hex-head bolts still dominant, or is it like places where in >>>>> the US one would use a hex-head bolt or Allen-key screw they use Torx or >>>>> similar?...
When Torx came out, people where I live were scratching their heads why >>>> people would use an expensive proprietary kind of screwdriver, when
Robertson was available to do exactly the same job.
Originally, Torx was used in situations where malicious actors were
present {restrooms} and they wanted a driver that was not in general
use {already}
There two torx head patterns. The security version has a pin
in the middle of the head, which requires a matching socket on
the driver.
That said, driver bits for security torx are widely available.
than 2 years.
Thomas Koenig <tkoenig@netcologne.de> posted:
BGB <cr88192@gmail.com> schrieb:---------------------
On 4/13/2026 8:19 PM, MitchAlsup wrote:
1/16, 1/8, 3/16, 1/4, 5/16, 3/8, 7/16, 1/2, 9/16, 5/8, 11/16, 3/4,
13/16, 7/8, 15/16
Most people outside the US just use mm. The UK is sort of
fluctuating, they still have their distances in miles.
Why is it that people using the metric system will drive a thousand kilometers instead of one megameter ??
You can't have it both ways !!
But of course, the UK (or Imperial) gallon is different from
the US gallon.
On 15/04/2026 01:44, MitchAlsup wrote:
If you fill out the right forms, fill in the right paperwork, pay the
tax stamp cost, and wait through Sheriff interviews, and wait the ~18
months, you can legally own a fully automatic firearm.
One should also note: in the history of this system (~late 1930s)
to present: only 2 properly registered FA guns have been used in
any crimes. {Anyone with a brain would say this is a pretty good
record}
Anyone with a non-USAn brain would say this is utterly insane.
In article <n48bl0Fdbm4U1@mid.individual.net>,
moi <findlaybill@blueyonder.co.uk> wrote:
On 15/04/2026 01:44, MitchAlsup wrote:
If you fill out the right forms, fill in the right paperwork, pay the
tax stamp cost, and wait through Sheriff interviews, and wait the ~18
months, you can legally own a fully automatic firearm.
One should also note: in the history of this system (~late 1930s)
to present: only 2 properly registered FA guns have been used in
any crimes. {Anyone with a brain would say this is a pretty good
record}
Anyone with a non-USAn brain would say this is utterly insane.
As someone who has used, maintained, and fired a number of fully
automatic weapons in the military, I wonder why anyone would
want one.
Broadly speaking, they're a pain, and pretty much only useful as
either a suppression weapon or for guarding avenues of approach
to fixed defensive positions.
On 15/04/2026 13:30, Dan Cross wrote:
In article <n48bl0Fdbm4U1@mid.individual.net>,
moi <findlaybill@blueyonder.co.uk> wrote:
On 15/04/2026 01:44, MitchAlsup wrote:
If you fill out the right forms, fill in the right paperwork, pay the
tax stamp cost, and wait through Sheriff interviews, and wait the ~18
months, you can legally own a fully automatic firearm.
One should also note: in the history of this system (~late 1930s)
to present: only 2 properly registered FA guns have been used in
any crimes. {Anyone with a brain would say this is a pretty good
record}
Anyone with a non-USAn brain would say this is utterly insane.
As someone who has used, maintained, and fired a number of fully
automatic weapons in the military, I wonder why anyone would
want one.
Broadly speaking, they're a pain, and pretty much only useful as
either a suppression weapon or for guarding avenues of approach
to fixed defensive positions.
Clearly there are military applications of a wide range of weapons. But >outside that, I can only think of a couple of reasons to want a fully >automatic weapon :
1. You are seriously paranoid or otherwise disconnected from reality,
and think you need it because "they" are out to get you, or because you
are convinced you need it for "protection". (This "protection" myth
seems to be a major reason for all sorts of weapons in the USA. You or
your family are far more likely to be accidentally harmed by a gun
bought for "protection" than by an intruder's gun.)
2. You think it will be fun to shoot, or looks cool on TV (and you can't >distinguish between television and reality). I can appreciate the fun >appeal of shooting big guns, but it would make far more sense in very >controlled circumstances in specialised shooting ranges than for private >citizens ever having such weapons.
3. You are a criminal and are using it for armed robbery and the like.
The other two main uses of firearms - sport and hunting - don't apply to >fully automatic weapons.
On 15/04/2026 13:30, Dan Cross wrote:
In article <n48bl0Fdbm4U1@mid.individual.net>,
moi <findlaybill@blueyonder.co.uk> wrote:
On 15/04/2026 01:44, MitchAlsup wrote:
Broadly speaking, they're a pain, and pretty much only useful as
either a suppression weapon or for guarding avenues of approach
to fixed defensive positions.
On 15/04/2026 01:44, MitchAlsup wrote:
One should also note: in the history of this system (~late 1930s)
to present: only 2 properly registered FA guns have been used in any
crimes. {Anyone with a brain would say this is a pretty good record}
Anyone with a non-USAn brain would say this is utterly insane.
David Brown <david.brown@hesbynett.no> writes:
On 15/04/2026 13:30, Dan Cross wrote:
In article <n48bl0Fdbm4U1@mid.individual.net>,
moi <findlaybill@blueyonder.co.uk> wrote:
On 15/04/2026 01:44, MitchAlsup wrote:
<snip>
Broadly speaking, they're a pain, and pretty much only useful as
either a suppression weapon or for guarding avenues of approach
to fixed defensive positions.
They're also extremely expensive to use and maintain. at $2.00 or
more _per round_, the cost rises rapidly.
Mythbusters shot a minigun on a couple episodes and the ammo cost
(more than a decade ago) was huge.
Utterly insane would be if the same procedure applied to thermonuclear >warheads.
Of course, much about the consequences of the Second Amendment indeed does >appear insane. The sensible thing to do would be to repeal it, rather than >pretend it doesn't exist, or it doesn't mean what it says, and hope the >Supreme Court will look the other way.
...
but they often don't realize that the kickback makes them
difficult to control. Even the 3-round burst on the M4/M16
pattern weapons will kick you off target almost instantly
Thomas Koenig <tkoenig@netcologne.de> posted:
MitchAlsup <user5857@newsgrouper.org.invalid> schrieb:Not even a good try.
quadi <quadibloc@ca.invalid> posted:
On Tue, 14 Apr 2026 14:30:30 +0000, Scott Lurndal wrote:
Actually, they're the most commonly used screws in my household.
I take it you're also a Canadian. Their very existence is unknown to the >> >> average American.
Can you name the 7-types of thread without using a manual ??
M2 M3 M4 M5 M6 M8 M10
:-)
I don't know why anyone would want a full-auto weapon as
anything other than a museum piece or a novelty. I strongly
suspect that such people have never heard a shot fired in anger
before.
- Dan C.
According to quadi <quadibloc@ca.invalid>:
Utterly insane would be if the same procedure applied to thermonuclear >warheads.
Of course, much about the consequences of the Second Amendment indeed does >appear insane. The sensible thing to do would be to repeal it, rather than >pretend it doesn't exist, or it doesn't mean what it says, and hope the >Supreme Court will look the other way.
The first clause of the second amendment says "A well regulated
Militia, being necessary to the security of a free State." For a
century and a half, its meaning was invariably understood to be that individual states could raise militias which we now call the National
Guard. Then in the 1960s some well organizaed revisionists ignored
what it says, pretended it meant an individual right to have guns
everywhere, and managed to find a majority of right wing supreme court justices willing to sign on.
This interesting paper argues that the real motivation for the 2nd was
that the slave states used their militias to put down slave rebellions
and feared that the more populous free states would disarm them.
https://papers.ssrn.com/sol3/papers.cfm?abstract_id=1465114
Can we get back to arguing about gate delays, please?
Then in the
1960s some well organizaed revisionists ignored what it says, pretended
it meant an individual right to have guns everywhere, and managed to
find a majority of right wing supreme court justices willing to sign on.
cross@spitfire.i.gajendra.net (Dan Cross) posted:
-------------------------
I don't know why anyone would want a full-auto weapon as
anything other than a museum piece or a novelty. I strongly
suspect that such people have never heard a shot fired in anger
before.
Same argument can be made about cars that can go faster than speed limits.
And we now have cars that can go faster than 250 MPH and require $30K
tire sets at replacement.
MitchAlsup <user5857@newsgrouper.org.invalid> schrieb:
Thomas Koenig <tkoenig@netcologne.de> posted:
MitchAlsup <user5857@newsgrouper.org.invalid> schrieb:Not even a good try.
quadi <quadibloc@ca.invalid> posted:
On Tue, 14 Apr 2026 14:30:30 +0000, Scott Lurndal wrote:
Actually, they're the most commonly used screws in my household.
I take it you're also a Canadian. Their very existence is unknown to the
average American.
Can you name the 7-types of thread without using a manual ??
M2 M3 M4 M5 M6 M8 M10
:-)
Why? (Just for rhyme's sake).
Are you saying that M2 is the same thread as M3?
On Tue, 14 Apr 2026 03:09:55 -0500, BGB wrote:
If not, are hex-head bolts still dominant, or is it like places where in
the US one would use a hex-head bolt or Allen-key screw they use Torx or
similar?...
When Torx came out, people where I live were scratching their heads why people would use an expensive proprietary kind of screwdriver, when
Robertson was available to do exactly the same job.
But apparently in the United States, the Robertson screwdriver is
practically unknown.
Robertson uses a screwdriver with a square tip.
Thomas Koenig <tkoenig@netcologne.de> posted:
BGB <cr88192@gmail.com> schrieb:---------------------
On 4/13/2026 8:19 PM, MitchAlsup wrote:
1/16, 1/8, 3/16, 1/4, 5/16, 3/8, 7/16, 1/2, 9/16, 5/8, 11/16, 3/4,
13/16, 7/8, 15/16
Most people outside the US just use mm. The UK is sort of
fluctuating, they still have their distances in miles.
Why is it that people using the metric system will drive a thousand kilometers instead of one megameter ??
You can't have it both ways !!
quadi <quadibloc@ca.invalid> posted:
On Tue, 14 Apr 2026 03:09:55 -0500, BGB wrote:
If not, are hex-head bolts still dominant, or is it like places where in >>> the US one would use a hex-head bolt or Allen-key screw they use Torx or >>> similar?...
When Torx came out, people where I live were scratching their heads why
people would use an expensive proprietary kind of screwdriver, when
Robertson was available to do exactly the same job.
Originally, Torx was used in situations where malicious actors were
present {restrooms} and they wanted a driver that was not in general
use {already}
David Brown <david.brown@hesbynett.no> writes:
On 15/04/2026 13:30, Dan Cross wrote:
In article <n48bl0Fdbm4U1@mid.individual.net>,
moi <findlaybill@blueyonder.co.uk> wrote:
On 15/04/2026 01:44, MitchAlsup wrote:
<snip>
Broadly speaking, they're a pain, and pretty much only useful as
either a suppression weapon or for guarding avenues of approach
to fixed defensive positions.
They're also extremely expensive to use and maintain. at $2.00 or
more _per round_, the cost rises rapidly.
Mythbusters shot a minigun on a couple episodes and the ammo cost
(more than a decade ago) was huge.
On 15/04/2026 01:44, MitchAlsup wrote:
If you fill out the right forms, fill in the right paperwork, pay the
tax stamp cost, and wait through Sheriff interviews, and wait the ~18
months, you can legally own a fully automatic firearm.
One should also note: in the history of this system (~late 1930s)
to present: only 2 properly registered FA guns have been used in
any crimes. {Anyone with a brain would say this is a pretty good
record}
Anyone with a non-USAn brain would say this is utterly insane.
In article <n48bl0Fdbm4U1@mid.individual.net>,
moi <findlaybill@blueyonder.co.uk> wrote:
On 15/04/2026 01:44, MitchAlsup wrote:
If you fill out the right forms, fill in the right paperwork, pay the
tax stamp cost, and wait through Sheriff interviews, and wait the ~18
months, you can legally own a fully automatic firearm.
One should also note: in the history of this system (~late 1930s)
to present: only 2 properly registered FA guns have been used in
any crimes. {Anyone with a brain would say this is a pretty good
record}
Anyone with a non-USAn brain would say this is utterly insane.
As someone who has used, maintained, and fired a number of fully
automatic weapons in the military, I wonder why anyone would
want one.
Broadly speaking, they're a pain, and pretty much only useful as
either a suppression weapon or for guarding avenues of approach
to fixed defensive positions.
On Wed, 15 Apr 2026 03:32:00 +0100, moi wrote:
On 15/04/2026 01:44, MitchAlsup wrote:
One should also note: in the history of this system (~late 1930s)
to present: only 2 properly registered FA guns have been used in any
crimes. {Anyone with a brain would say this is a pretty good record}
Anyone with a non-USAn brain would say this is utterly insane.
Utterly insane would be if the same procedure applied to thermonuclear warheads.
Of course, much about the consequences of the Second Amendment indeed does appear insane. The sensible thing to do would be to repeal it, rather than pretend it doesn't exist, or it doesn't mean what it says, and hope the Supreme Court will look the other way.
Letting trustworthy people have fully-automatic weapons is a small
problem; it's letting just anyone have semi-automatic weapons that has contributed significantly to school shootings and the like.
John Savard
scott@slp53.sl.home (Scott Lurndal) posted:
David Brown <david.brown@hesbynett.no> writes:
On 15/04/2026 13:30, Dan Cross wrote:
In article <n48bl0Fdbm4U1@mid.individual.net>,
moi <findlaybill@blueyonder.co.uk> wrote:
On 15/04/2026 01:44, MitchAlsup wrote:
<snip>
Broadly speaking, they're a pain, and pretty much only useful as
either a suppression weapon or for guarding avenues of approach
to fixed defensive positions.
They're also extremely expensive to use and maintain. at $2.00 or
more _per round_, the cost rises rapidly.
I reload 308W for $0.36 and 223 for $0.23 with match grade components.
{But, then again, I bought my components a long time ago}
moi wrote:
On 15/04/2026 01:44, MitchAlsup wrote:Anyone from (current) Switzerland or pre-1992 Norway would say that this
If you fill out the right forms, fill in the right paperwork, pay the
tax stamp cost, and wait through Sheriff interviews, and wait the ~18
months, you can legally own a fully automatic firearm.
One should also note: in the history of this system (~late 1930s)
to present: only 2 properly registered FA guns have been used in
any crimes. {Anyone with a brain would say this is a pretty good
record}
Anyone with a non-USAn brain would say this is utterly insane.
is perfectly normal:
Every single home guard (think National Guard) member and every reserve office, from NCOs up to general, had their AG3 (HK G3) in 7.62 NATO,
with at least 150 rounds of ammo, at home. This was somewhere around 300
000 guns in a country of less than 5M people, so one in every three or
four households.
The only security requirement was that you had to take out the firing
pin and store it apart from the gun.
Zero such guns were ever used in a crime, or stolen from a home, but
after a couple of armory breakins where boxes of AG3s got stolen, they (Laber party government at the time) used that as a pretext to withdraw
all those guns.
The Swiss still have all their full auto/military guns, they just keep strict control of the ammunition: You bring your empty gun to the range
and get your allotment, any unspent rounds have to be returned before
you leave.
Terje
In article <n48bl0Fdbm4U1@mid.individual.net>,
moi <findlaybill@blueyonder.co.uk> wrote:
On 15/04/2026 01:44, MitchAlsup wrote:
If you fill out the right forms, fill in the right paperwork, pay the
tax stamp cost, and wait through Sheriff interviews, and wait the ~18
months, you can legally own a fully automatic firearm.
One should also note: in the history of this system (~late 1930s)
to present: only 2 properly registered FA guns have been used in
any crimes. {Anyone with a brain would say this is a pretty good
record}
Anyone with a non-USAn brain would say this is utterly insane.
As someone who has used, maintained, and fired a number of fully
automatic weapons in the military, I wonder why anyone would
want one.
Broadly speaking, they're a pain, and pretty much only useful as
either a suppression weapon or for guarding avenues of approach
to fixed defensive positions.
- Dan C.
On 4/15/2026 4:30 AM, Dan Cross wrote:
In article <n48bl0Fdbm4U1@mid.individual.net>,
moi <findlaybill@blueyonder.co.uk> wrote:
On 15/04/2026 01:44, MitchAlsup wrote:
If you fill out the right forms, fill in the right paperwork, pay the
tax stamp cost, and wait through Sheriff interviews, and wait the ~18
months, you can legally own a fully automatic firearm.
One should also note: in the history of this system (~late 1930s)
to present: only 2 properly registered FA guns have been used in
any crimes. {Anyone with a brain would say this is a pretty good
record}
Anyone with a non-USAn brain would say this is utterly insane.
As someone who has used, maintained, and fired a number of fully
automatic weapons in the military, I wonder why anyone would
want one.
Broadly speaking, they're a pain, and pretty much only useful as
either a suppression weapon or for guarding avenues of approach
to fixed defensive positions.
- Dan C.
Say target on single fire mode. Missed! Turn to auto and give a burst.
Or don't for what about 3 round burst? They are moving now. No single
sniper mode. A suppress fully auto can make the target think there might
be more than one person out there. Reminds me of the following scene:
(Terminator 2: Judgment Day [4K] Sarah Connor tries to kill Dyson)
https://youtu.be/j8TIMy_eyK0
Also, full auto, beware! Blows your ammo!
On 15/04/2026 21:33, Terje Mathisen wrote:
moi wrote:
On 15/04/2026 01:44, MitchAlsup wrote:Anyone from (current) Switzerland or pre-1992 Norway would say that
If you fill out the right forms, fill in the right paperwork, pay the
tax stamp cost, and wait through Sheriff interviews, and wait the ~18
months, you can legally own a fully automatic firearm.
One should also note: in the history of this system (~late 1930s)
to present: only 2 properly registered FA guns have been used in
any crimes. {Anyone with a brain would say this is a pretty good
record}
Anyone with a non-USAn brain would say this is utterly insane.
this is perfectly normal:
Every single home guard (think National Guard) member and every
reserve office, from NCOs up to general, had their AG3 (HK G3) in 7.62
NATO, with at least 150 rounds of ammo, at home. This was somewhere
around 300 000 guns in a country of less than 5M people, so one in
every three or four households.
The only security requirement was that you had to take out the firing
pin and store it apart from the gun.
These are not civilian guns. No one considers their National Guard gun
as "their" gun - they have it for use in National Guard exercises or call-outs. The gun are always stored safely - kids can't show off Dad's gun to their friends and accidentally kill them.
And the members of the
National Guard are already vetted for being sensible, intelligent,
honest and reliable people. (No such vetting is perfect, but it's
pretty good.)
Zero such guns were ever used in a crime, or stolen from a home, but
after a couple of armory breakins where boxes of AG3s got stolen, they
(Laber party government at the time) used that as a pretext to
withdraw all those guns.
The Swiss still have all their full auto/military guns, they just keep
strict control of the ammunition: You bring your empty gun to the
range and get your allotment, any unspent rounds have to be returned
before you leave.
Terje
moi wrote:
On 15/04/2026 01:44, MitchAlsup wrote:
If you fill out the right forms, fill in the right paperwork, pay the
tax stamp cost, and wait through Sheriff interviews, and wait the ~18
months, you can legally own a fully automatic firearm.
One should also note: in the history of this system (~late 1930s)
to present: only 2 properly registered FA guns have been used in
any crimes. {Anyone with a brain would say this is a pretty good
record}
Anyone with a non-USAn brain would say this is utterly insane.
Anyone from (current) Switzerland or pre-1992 Norway would say that this
is perfectly normal:
Every single home guard (think National Guard) member and every reserve >office, from NCOs up to general, had their AG3 (HK G3) in 7.62 NATO,
with at least 150 rounds of ammo, at home. This was somewhere around 300
000 guns in a country of less than 5M people, so one in every three or
four households.
The only security requirement was that you had to take out the firing
pin and store it apart from the gun.
Zero such guns were ever used in a crime, or stolen from a home, but
after a couple of armory breakins where boxes of AG3s got stolen, they >(Laber party government at the time) used that as a pretext to withdraw
all those guns.
The Swiss still have all their full auto/military guns, they just keep >strict control of the ammunition: You bring your empty gun to the range
and get your allotment, any unspent rounds have to be returned before
you leave.
Thomas Koenig <tkoenig@netcologne.de> posted:
MitchAlsup <user5857@newsgrouper.org.invalid> schrieb:
Thomas Koenig <tkoenig@netcologne.de> posted:
MitchAlsup <user5857@newsgrouper.org.invalid> schrieb:Not even a good try.
quadi <quadibloc@ca.invalid> posted:
On Tue, 14 Apr 2026 14:30:30 +0000, Scott Lurndal wrote:
Actually, they're the most commonly used screws in my household.
I take it you're also a Canadian. Their very existence is unknown to the
average American.
Can you name the 7-types of thread without using a manual ??
M2 M3 M4 M5 M6 M8 M10
:-)
Why? (Just for rhyme's sake).
Are you saying that M2 is the same thread as M3?
Both have the same "scaled" Geometry.
Say target on single fire mode. Missed! Turn to auto and give a burst.
Or don't for what about 3 round burst? They are moving now. No single
sniper mode. A suppress fully auto can make the target think there might
be more than one person out there. Reminds me of the following scene:
On 15/04/2026 21:33, Terje Mathisen wrote:
moi wrote:
On 15/04/2026 01:44, MitchAlsup wrote:Anyone from (current) Switzerland or pre-1992 Norway would say that this
If you fill out the right forms, fill in the right paperwork, pay the
tax stamp cost, and wait through Sheriff interviews, and wait the ~18
months, you can legally own a fully automatic firearm.
One should also note: in the history of this system (~late 1930s)
to present: only 2 properly registered FA guns have been used in
any crimes. {Anyone with a brain would say this is a pretty good
record}
Anyone with a non-USAn brain would say this is utterly insane.
is perfectly normal:
Every single home guard (think National Guard) member and every reserve
office, from NCOs up to general, had their AG3 (HK G3) in 7.62 NATO,
with at least 150 rounds of ammo, at home. This was somewhere around 300
000 guns in a country of less than 5M people, so one in every three or
four households.
The only security requirement was that you had to take out the firing
pin and store it apart from the gun.
These are not civilian guns. No one considers their National Guard gun
as "their" gun - they have it for use in National Guard exercises or >call-outs. The gun are always stored safely - kids can't show off Dad's
gun to their friends and accidentally kill them. And the members of the >National Guard are already vetted for being sensible, intelligent,
honest and reliable people. (No such vetting is perfect, but it's
pretty good.)
Zero such guns were ever used in a crime, or stolen from a home, but
after a couple of armory breakins where boxes of AG3s got stolen, they
(Laber party government at the time) used that as a pretext to withdraw
all those guns.
The Swiss still have all their full auto/military guns, they just keep
strict control of the ammunition: You bring your empty gun to the range
and get your allotment, any unspent rounds have to be returned before
you leave.
On Wed, 15 Apr 2026 16:44:04 +0000, John Levine wrote:
Then in the
1960s some well organizaed revisionists ignored what it says, pretended
it meant an individual right to have guns everywhere, and managed to
find a majority of right wing supreme court justices willing to sign on.
I'm afraid that I can't agree with you on this. ...
Of course, it's possible subordinate clauses were used differently back in >the eighteenth century, but I'd need evidence to buy into that theory.
On 15/04/2026 17:36, quadi wrote:That is the bit they really can't fathom.
On Wed, 15 Apr 2026 03:32:00 +0100, moi wrote:
On 15/04/2026 01:44, MitchAlsup wrote:
One should also note: in the history of this system (~late 1930s)
to present: only 2 properly registered FA guns have been used in any crimes. {Anyone with a brain would say this is a pretty good record}
Anyone with a non-USAn brain would say this is utterly insane.
Utterly insane would be if the same procedure applied to thermonuclear warheads.
Of course, much about the consequences of the Second Amendment indeed does appear insane. The sensible thing to do would be to repeal it, rather than pretend it doesn't exist, or it doesn't mean what it says, and hope the Supreme Court will look the other way.
[wise words omitted]
That's just my two cents - coming from someone in a country ...
where we have far more real-world freedoms than the USA.
Chris M. Thomasson <chris.m.thomasson.1@gmail.com> schrieb:
Say target on single fire mode. Missed! Turn to auto and give a burst.
Or don't for what about 3 round burst? They are moving now. No single
sniper mode. A suppress fully auto can make the target think there might
be more than one person out there. Reminds me of the following scene:
Firing suppressive fire in full auto is not what assault guns are for.
That's what real machine guns are for.
There was some criticism of the G36 assault rifle in Germany because
the aim point appeared to wander at auto-fire in high temperatures.
Well, see above.
On 4/14/2026 11:35 AM, Thomas Koenig wrote:
BGB <cr88192@gmail.com> schrieb:
On 4/14/2026 1:00 AM, Thomas Koenig wrote:
BGB <cr88192@gmail.com> schrieb:
On 4/13/2026 8:19 PM, MitchAlsup wrote:
Robert Finch <robfi680@gmail.com> posted:
On 2026-04-13 5:11 p.m., Thomas Koenig wrote:---------------
BGB <cr88192@gmail.com> schrieb:
Socket wrenches come in weird sizes like 1/2, 1/4 inch, but
Socket wrench?
metric is
used nowadays.
Socket wrenches go as small as step sizes of 1/64 and 0.25mm
Smaller than step sizes of 1/32 are rare, with 1/16 quite common.
Yeah, somehow I would have thought pretty much everyone would be
familiar with them and with the system of fractions for defining sizes >>>>> for things...
Look at my e-mail address and consider which countries use
which measuring system. For your amusement, you can also watch
https://www.youtube.com/watch?v=JYqfVE-fykk :-)
So Germany doesn't also use SAE for screws and bolts?...
Not sure what SAE prescribes. Is that Imperial? Germany (like
almost everybody else) use ISO, which is metric. An M6 screw,
for example, has a nominal outer diameter of 6 mm. Screw heads
are also ISO.
Mostly it defines everything in inch-based units.
An M6 is roughly around the size of what we would call 1/4-20, for 1/4
inch at 20 turns per inch.
Or, have the same thing of building machines where half the screws are
SAE and half are Metric.
You will be hard pressed to find inch-based screws and bolts in
the EU, this is entirely metric. The only exception is Withworth
threads, which are still used for piping in houses. Of course,
these only bear a passing resemblance to their nominal diameter
because of $REASONS.
US has NPT, which has tapered threads, and differs from its stated size
by a factor of 2 because apparently they describe its size in radius or something.
If not, are hex-head bolts still dominant, or is it like places where in >>> the US one would use a hex-head bolt or Allen-key screw they use Torx or >>> similar?...
Really depends on the application. Screws come in a variety of heads.
For bolts, hexagonal is dominant.
OK.
In US it is mostly hex-heads for bolts, and Philips for small screws (followed by Allen keys).
Then again, I guess if anything I would expect things like machines to
be similar, as most of the machines are presumably still made in China,
and it would be weird to expect China to make different stuff based on
what country they intend to sell it in.
I believe China looked around for their standards a few decades ago,
and decided to base theirs on DIN (the German one).
OK.
Still seems like a lot of the stuff they sell to the US uses US sizes,
so maybe it is market dependent.
But, then again, I have heard there are sometimes issues, like a lot of
Chinese-made machines use copper-clad-aluminum wire, which is apparently >>> illegal in places like Australia, ...
Well, and I guess in the US, there are a lot of people who don't approve >>> of aluminum and CCA wiring, but generally still allowed (though CCA is
kinda annoying to solder as it can often foul up the tip on the
soldering iron and/or form an amalgam with the solder which can't really >>> be re-melted when if forms).
I don't think aluminium wiring is allowed in Germany. I have certainly
never seen it, also not in old houses.
Here, it is one of those "allowed but some people get pissy about it"
things when used for house wiring.
Frequently used in consumer electronics but no one notices.
I once encountered a wire that when voltage caused a spark to form, the
wire went off like a "4th of July" sparkler (basically, a metal stick
used for a US holiday, when the end is lit of fire, it burns and shoots white-hot sparks out the end, *1).
At first I thought it was CCA, but apparently it was CCAM (Copper Clad Aluminum-Magnesium). The CCAM wiring is probably the main stuff people actually need to worry about.
Though, AFAIK, pretty much no use uses magnesium for house wiring though.
*1: Where, the US has a holiday where the main traditional way of celebrating the holiday is to let kids play around with low grade
explosives and incendiaries. People have still been injured or killed as
a result of this, particularly when doing "something stupid".
Like, by themselves, their explosive powers aren't much of a problem,
but when contained in something like a beer bottle, or inserted into someone's rectum or similar, the danger goes up significantly.
Apparently this sort of thing is a recurring problem.
Well, and then there are people that celebrate by firing guns into the
air, but falling bullets can also pose a safety risk.
Sometimes, people have guns that are full auto. These are not usually
legal to have, but if one hears full-auto / rapid fire going off, then
it is an indication that someone nearby has one (and gunfire and machine guns can be heard over a fair distance). Well, also people firing
shotguns and similar into the air is also popular.
This sort of thing is also popular on New Years Eve, but almost
exclusively gunfire in this case (fireworks are mostly a "4th of July" thing). Depends a lot on the holiday though (say, would be rather out of place on Christmas or Easter).
Maybe this isn't as much of a thing elsewhere though...
But, yeah, I guess it is also sort of like in video games the units are
more ad-hoc, just whatever is most convenient at the time.
Though, in a lot of my 3D engines, this has been to use the meter as the >>> base unit, but then define an "inch" as 1/32 of a meter; then just be
like "whatever, close enough". Apparently fairly close to the old French >>> Inch though.
An inch is 25.4 mm, 1m/32 is 31.25 mm, that is a rather big
deviation. But then again, pi equals 3 for small values of pi
and large values of 3...
Yes.
In 3D gaming stuff, accuracy doesn't really matter, so long as things
are "in the right general area".
If using meters as a base unit, can put eye level at around 1.6 or 1.7
off the ground, as this is "about right" (1.8 is too tall and 1.4 is too short), ...
In some cases, can make sense to have a cubit as 1/2 "meter", or "foot"
as 1/3.
But, can't make too many assumptions it seems.
I was thrown off by the measurements in inches.
OK.
We have mm stuff as well, but it is less commonly used than inch stuff.
Tools and CNC machines pretty much exclusively use inches though.
Not so long ago, I was standing in a workshop in the US and asking
for a caliper in mm. They had one, but it took them some time to
find it :-)
Yeah, makes sense.
Most of them are inch based.
[...]
On 4/15/2026 1:28 PM, Thomas Koenig wrote:
Chris M. Thomasson <chris.m.thomasson.1@gmail.com> schrieb:
Say target on single fire mode. Missed! Turn to auto and give a burst.
Or don't for what about 3 round burst? They are moving now. No single
sniper mode. A suppress fully auto can make the target think there might >>> be more than one person out there. Reminds me of the following scene:
Firing suppressive fire in full auto is not what assault guns are for.
That's what real machine guns are for.
Tu. But, they can scare the shit out of the target. They know round are going down range toward them. Therefore, they are in peril? But, the
ammo issue, ugg.
Chris M. Thomasson <chris.m.thomasson.1@gmail.com> schrieb:
On 4/15/2026 1:28 PM, Thomas Koenig wrote:
Chris M. Thomasson <chris.m.thomasson.1@gmail.com> schrieb:
Say target on single fire mode. Missed! Turn to auto and give a burst. >>>> Or don't for what about 3 round burst? They are moving now. No single
sniper mode. A suppress fully auto can make the target think there might >>>> be more than one person out there. Reminds me of the following scene:
Firing suppressive fire in full auto is not what assault guns are for.
That's what real machine guns are for.
Tu. But, they can scare the shit out of the target. They know round are
going down range toward them. Therefore, they are in peril? But, the
ammo issue, ugg.
I first used the G3 at the Bundeswehr. 600 rounds per minute, 20
rounds per magazine. Firing that weapon at full auto will empty
it in a tid less than two seconds (note fencepost error here :-)
Firing short bursts or single shots will keep any enemy down for
a far longer time than that.
But a squad at the time had a MG3 (1200 rounds per minute) with it.
But firing that continously is also not a good idea because
a) ammunition: 24 grams per round means that you run through 0.48
kg (a bit more than a pound :-) per second of ammunition, which
somebody has to carry
b) you have to exchange barrels and locks after a certain number
of rounds to prevent overheating.
In article <10roqpe$16j1j$2@dont-email.me>,
David Brown <david.brown@hesbynett.no> wrote:
On 15/04/2026 21:33, Terje Mathisen wrote:
moi wrote:
On 15/04/2026 01:44, MitchAlsup wrote:Anyone from (current) Switzerland or pre-1992 Norway would say that this >>> is perfectly normal:
If you fill out the right forms, fill in the right paperwork, pay the >>>>> tax stamp cost, and wait through Sheriff interviews, and wait the ~18 >>>>> months, you can legally own a fully automatic firearm.
One should also note: in the history of this system (~late 1930s)
to present: only 2 properly registered FA guns have been used in
any crimes. {Anyone with a brain would say this is a pretty good
record}
Anyone with a non-USAn brain would say this is utterly insane.
Every single home guard (think National Guard) member and every reserve
office, from NCOs up to general, had their AG3 (HK G3) in 7.62 NATO,
with at least 150 rounds of ammo, at home. This was somewhere around 300 >>> 000 guns in a country of less than 5M people, so one in every three or
four households.
The only security requirement was that you had to take out the firing
pin and store it apart from the gun.
These are not civilian guns. No one considers their National Guard gun
as "their" gun - they have it for use in National Guard exercises or
call-outs. The gun are always stored safely - kids can't show off Dad's
gun to their friends and accidentally kill them. And the members of the
National Guard are already vetted for being sensible, intelligent,
honest and reliable people. (No such vetting is perfect, but it's
pretty good.)
If you're referring to the United States,
then those guns almost
never go home with those service members. Rather, they are
almost certainly kept in an armory on site at the NG facility.
The requirements for securing access to a US military armory are
non-trivial; when they're staffed, the service members doing so
are themselves armed and acting under shoot-to-kill orders.
But generally speaking, most military members are unarmed most
of the time. This is one reason why the Fort Hood shooter was
able to kill so people many before being subdued.
There is some leeway for officers and staff NCOs to transport
weapons to and from a range exercise in their POVs (Personally
Owned Vehicles), but the expectation is that they are returned
to the armory after use.
Oh, and you have to clean it before turning it back in, too, and
you have to do so to the satisfaction of a Marine Corps armoror
(well, you do if you're a Marine). That said, a little birdie
once told me that if you do a first pass and put a $20 bill in
the breach of the weapon when you turn it back in, they will do
it for you. But I wouldn't know anything about that.
Zero such guns were ever used in a crime, or stolen from a home, but
after a couple of armory breakins where boxes of AG3s got stolen, they
(Laber party government at the time) used that as a pretext to withdraw
all those guns.
The Swiss still have all their full auto/military guns, they just keep
strict control of the ammunition: You bring your empty gun to the range
and get your allotment, any unspent rounds have to be returned before
you leave.
The same is true in the US military; there is a process of
"lining out" (at least, that's what we called it in the Marine
Corps; I can't speak to other services, though I assume the Navy
is similar) whereby you are physically searched and patted down
to ensure that you're not holding any rounds, intentional or
otherwise.
On 15/04/2026 22:35, Dan Cross wrote:
In article <10roqpe$16j1j$2@dont-email.me>,
David Brown <david.brown@hesbynett.no> wrote:
On 15/04/2026 21:33, Terje Mathisen wrote:
moi wrote:
On 15/04/2026 01:44, MitchAlsup wrote:Anyone from (current) Switzerland or pre-1992 Norway would say that this >>>> is perfectly normal:
If you fill out the right forms, fill in the right paperwork, pay the >>>>>> tax stamp cost, and wait through Sheriff interviews, and wait the ~18 >>>>>> months, you can legally own a fully automatic firearm.
One should also note: in the history of this system (~late 1930s)
to present: only 2 properly registered FA guns have been used in
any crimes. {Anyone with a brain would say this is a pretty good
record}
Anyone with a non-USAn brain would say this is utterly insane.
Every single home guard (think National Guard) member and every reserve >>>> office, from NCOs up to general, had their AG3 (HK G3) in 7.62 NATO,
with at least 150 rounds of ammo, at home. This was somewhere around 300 >>>> 000 guns in a country of less than 5M people, so one in every three or >>>> four households.
The only security requirement was that you had to take out the firing
pin and store it apart from the gun.
These are not civilian guns. No one considers their National Guard gun
as "their" gun - they have it for use in National Guard exercises or
call-outs. The gun are always stored safely - kids can't show off Dad's >>> gun to their friends and accidentally kill them. And the members of the >>> National Guard are already vetted for being sensible, intelligent,
honest and reliable people. (No such vetting is perfect, but it's
pretty good.)
If you're referring to the United States,
No, I am referring to Norway. But it would have been helpful if I'd >mentioned that! (I expect similar rules and attitudes apply in >Switzerland.)
then those guns almost
never go home with those service members. Rather, they are
almost certainly kept in an armory on site at the NG facility.
The requirements for securing access to a US military armory are
non-trivial; when they're staffed, the service members doing so
are themselves armed and acting under shoot-to-kill orders.
The current practice in Norway is that National Guard members have their >guns at home, but no ammunition and no firing pin. This makes things >practical for exercises, as the leaders for the exercises don't need to >transport much - just a box of firing pins and as much ammunition as is >appropriate.
(The service members have all their other equipment at
home too - they store their own uniforms and other stuff, and are >responsible for washing and repairs or ordering replacements after the >exercises.)
It also means that there are less guns stored in
concentrated places as potential targets for robberies. And in the
event of a real invasion, it's a lot easier to smugle around and
distribute firing pins to service members than to pass around guns from
a central armoury.
We also don't really go in for shoot-to-kill in Norway.
But generally speaking, most military members are unarmed most
of the time. This is one reason why the Fort Hood shooter was
able to kill so people many before being subdued.
There is some leeway for officers and staff NCOs to transport
weapons to and from a range exercise in their POVs (Personally
Owned Vehicles), but the expectation is that they are returned
to the armory after use.
I don't know the details of any of that here.
Oh, and you have to clean it before turning it back in, too, and
you have to do so to the satisfaction of a Marine Corps armoror
(well, you do if you're a Marine). That said, a little birdie
once told me that if you do a first pass and put a $20 bill in
the breach of the weapon when you turn it back in, they will do
it for you. But I wouldn't know anything about that.
We don't really go in for bribery either in Norway - at least, not at
that level. (In fact, not much at any level - we are not perfect, but
are one of the least corrupt countries.)
Zero such guns were ever used in a crime, or stolen from a home, but
after a couple of armory breakins where boxes of AG3s got stolen, they >>>> (Laber party government at the time) used that as a pretext to withdraw >>>> all those guns.
The Swiss still have all their full auto/military guns, they just keep >>>> strict control of the ammunition: You bring your empty gun to the range >>>> and get your allotment, any unspent rounds have to be returned before
you leave.
The same is true in the US military; there is a process of
"lining out" (at least, that's what we called it in the Marine
Corps; I can't speak to other services, though I assume the Navy
is similar) whereby you are physically searched and patted down
to ensure that you're not holding any rounds, intentional or
otherwise.
If you want trustworthy military personell, you need to trust them.
As
a teenager in the UK, I was in the "cadets" at school - once a week we'd >have a few hours in military uniforms, learning marching, gun safety,
and a bit of fun stuff like camouflage, abseiling, and stuff. It also >included shooting at a barracks gun range - serious sized rounds with
long outdated rifles. We were just fifteen year-old "toy soldiers", and
we were /asked/ to check our pockets for extra rounds or empty casings.
In article <10rqag7$1in0h$1@dont-email.me>,
David Brown <david.brown@hesbynett.no> wrote:
On 15/04/2026 22:35, Dan Cross wrote:
In article <10roqpe$16j1j$2@dont-email.me>,
David Brown <david.brown@hesbynett.no> wrote:
On 15/04/2026 21:33, Terje Mathisen wrote:
moi wrote:
On 15/04/2026 01:44, MitchAlsup wrote:Anyone from (current) Switzerland or pre-1992 Norway would say that this >>>>> is perfectly normal:
If you fill out the right forms, fill in the right paperwork, pay the >>>>>>> tax stamp cost, and wait through Sheriff interviews, and wait the ~18 >>>>>>> months, you can legally own a fully automatic firearm.
One should also note: in the history of this system (~late 1930s) >>>>>>> to present: only 2 properly registered FA guns have been used in >>>>>>> any crimes. {Anyone with a brain would say this is a pretty good >>>>>>> record}
Anyone with a non-USAn brain would say this is utterly insane.
Every single home guard (think National Guard) member and every reserve >>>>> office, from NCOs up to general, had their AG3 (HK G3) in 7.62 NATO, >>>>> with at least 150 rounds of ammo, at home. This was somewhere around 300 >>>>> 000 guns in a country of less than 5M people, so one in every three or >>>>> four households.
The only security requirement was that you had to take out the firing >>>>> pin and store it apart from the gun.
These are not civilian guns. No one considers their National Guard gun >>>> as "their" gun - they have it for use in National Guard exercises or
call-outs. The gun are always stored safely - kids can't show off Dad's >>>> gun to their friends and accidentally kill them. And the members of the >>>> National Guard are already vetted for being sensible, intelligent,
honest and reliable people. (No such vetting is perfect, but it's
pretty good.)
If you're referring to the United States,
No, I am referring to Norway. But it would have been helpful if I'd
mentioned that! (I expect similar rules and attitudes apply in
Switzerland.)
Ah, ok.
then those guns almost
never go home with those service members. Rather, they are
almost certainly kept in an armory on site at the NG facility.
The requirements for securing access to a US military armory are
non-trivial; when they're staffed, the service members doing so
are themselves armed and acting under shoot-to-kill orders.
The current practice in Norway is that National Guard members have their
guns at home, but no ammunition and no firing pin. This makes things
practical for exercises, as the leaders for the exercises don't need to
transport much - just a box of firing pins and as much ammunition as is
appropriate.
This is sensible, though of course a firing pin is much easier
to source than an entire rifle. In the US military, ammunition
is stored separtely from weapons, as well. The armorers have
some smallish number of security rounds, but beyond that, for
safety reasons ammunition is kept seperate, often underground.
(Ammunition is, by definition, volatile. A fire or something at
an ammo supply point is inherently dangerous.)
(The service members have all their other equipment at
home too - they store their own uniforms and other stuff, and are
responsible for washing and repairs or ordering replacements after the
exercises.)
The same is true in the US military. I always found it annoying
that I had to make space for my issued equipment at home, but
c'est la vie.
It also means that there are less guns stored in
concentrated places as potential targets for robberies. And in the
event of a real invasion, it's a lot easier to smugle around and
distribute firing pins to service members than to pass around guns from
a central armoury.
There are tradeoffs, however: it is also easier for a bad actor
to source a weapon by breaking into a private home.
We also don't really go in for shoot-to-kill in Norway.
Note that I'm talking about the use of deadly force to prevent a
bad actor from forcibly taking military-grade arms. That is
exactly the sort of thing that deadly force arguably _should_ be
authorized for.
But more broadly, from a military perspective, this doesn't make
a lot of sense to me, because it ignores the human factors at
play in the fog of war.
Due to the sympathetic physiological reaction to stress, one
tends to lose one's fine motor skills in a combat-type situation
and it can be difficult to remember even the most basic bodily
functions: lose of urinary and sphincter control are common,
for example (hence the expression, "scared shitless"). Moreover
long experience in human history shows that it is impossible to
know a priori how one will react: some people are ridiculously
calm in combat, others are not.
For that reason, most people are taught to shoot center-of-mass;
I was in the military when we still used iron sights out to 500
yards (roughly 500 meters). It's one thing to accurately shoot
at that distance when you're on a known-distance range on a
relatively calm day. It's an entirely different matter when
someone is shooting back at you. Anyone who thinks, "I'll just
shoot to wound them!" is deluding themselves.
But generally speaking, most military members are unarmed most
of the time. This is one reason why the Fort Hood shooter was
able to kill so people many before being subdued.
There is some leeway for officers and staff NCOs to transport
weapons to and from a range exercise in their POVs (Personally
Owned Vehicles), but the expectation is that they are returned
to the armory after use.
I don't know the details of any of that here.
It's not important. It was just an aside.
Oh, and you have to clean it before turning it back in, too, and
you have to do so to the satisfaction of a Marine Corps armoror
(well, you do if you're a Marine). That said, a little birdie
once told me that if you do a first pass and put a $20 bill in
the breach of the weapon when you turn it back in, they will do
it for you. But I wouldn't know anything about that.
We don't really go in for bribery either in Norway - at least, not at
that level. (In fact, not much at any level - we are not perfect, but
are one of the least corrupt countries.)
Lol, that's not bribery.
Zero such guns were ever used in a crime, or stolen from a home, but >>>>> after a couple of armory breakins where boxes of AG3s got stolen, they >>>>> (Laber party government at the time) used that as a pretext to withdraw >>>>> all those guns.
The Swiss still have all their full auto/military guns, they just keep >>>>> strict control of the ammunition: You bring your empty gun to the range >>>>> and get your allotment, any unspent rounds have to be returned before >>>>> you leave.
The same is true in the US military; there is a process of
"lining out" (at least, that's what we called it in the Marine
Corps; I can't speak to other services, though I assume the Navy
is similar) whereby you are physically searched and patted down
to ensure that you're not holding any rounds, intentional or
otherwise.
If you want trustworthy military personell, you need to trust them.
I can't imagine that any other professional military does it
much differently than I described.
This isn't about trust so much as accountability; the two are of
course related, but different. In particular, it's about
building a warrior culture that emphasizes safety and respect
for the inherent danger of weapons and puts inculcates practices
designed to emphasize and reinforce those traits. Ammunition is
inherently dangerous; it should be treated as such. The
expectation is that service members treat it with respect and
the attention that it inherently deserves. You build that by
enforcing accountability and then pushing that down through the
ranks to the lowest levels: a junior Marine is lined out by
their fireteam leader; the team leaders by their squad leader;
the squad leaders by the Platoon Sergeant, and so on. Junior
Marines see that this is taken seriously and so learn to take it
seriously.
In other words, you build trust that you just described by
emphasizing safety practices, and validate they are followed by
rigorous inspection, thoughout the mundate and ordinary aspects
of training. Hence lineouts, weapons inspections, and "clearing
barrels" that are all designed to habituate safe(r) weapons
handling practices.
Note that this is one of the things I find so troubling about
the "2A" gun culture in the United States. It fetishizes
weapons and deemphasiizes safety practices so that its adherents
can be "ready" at all times (for what?). These people aren't
just deluded about the relative risks of owning and carrying
weapons, they're actively dangerous because they have no idea
what they are doing.
As
a teenager in the UK, I was in the "cadets" at school - once a week we'd
have a few hours in military uniforms, learning marching, gun safety,
and a bit of fun stuff like camouflage, abseiling, and stuff. It also
included shooting at a barracks gun range - serious sized rounds with
long outdated rifles. We were just fifteen year-old "toy soldiers", and
we were /asked/ to check our pockets for extra rounds or empty casings.
That's disturbing.
Sounds like the people who ran your "cadets" program did you a
disservice by failing to emphasize proper weapons and ammo
handling practices.
Having worked with actual British forces in Afghanistan, I know
that they take weapons safety as seriously as we do. Perhaps
don't extrapolate from that to what an actual military does.
On 16/04/2026 13:59, Dan Cross wrote:
In article <10rqag7$1in0h$1@dont-email.me>,
David Brown <david.brown@hesbynett.no> wrote:
[snip]
(The service members have all their other equipment at
home too - they store their own uniforms and other stuff, and are
responsible for washing and repairs or ordering replacements after the
exercises.)
The same is true in the US military. I always found it annoying
that I had to make space for my issued equipment at home, but
c'est la vie.
Personally, I have no military experience at all (not counting school >cadets). But one of my sons joined the National Guard after his
military service. He has a neat solution to problem of space for his >equipment - he keeps it in his old bedroom in our house, not in his own
flat :-)
It also means that there are less guns stored in
concentrated places as potential targets for robberies. And in the
event of a real invasion, it's a lot easier to smugle around and
distribute firing pins to service members than to pass around guns from
a central armoury.
There are tradeoffs, however: it is also easier for a bad actor
to source a weapon by breaking into a private home.
It is plausible, but AFAIK it is extremely rare here. The solid
majority of criminals here don't want guns, and would probably not take
one if they found one in a house they were robbing. As a house burglar,
you can't easily sell a gun, you don't need one for defence, you don't
need one to threaten anyone - it just increases your chance of being
shot yourself, and increases your punishment if you get got. There are
guns in the more serious narcotics gangs, but those are handguns - they
have no use for military weapons.
We also don't really go in for shoot-to-kill in Norway.
Note that I'm talking about the use of deadly force to prevent a
bad actor from forcibly taking military-grade arms. That is
exactly the sort of thing that deadly force arguably _should_ be
authorized for.
There is a distinction (which I did not make, but should have) between >authorising deadly force, and encouraging it. As a last resort, it
makes sense in situations like this. But it should be very much the
last resort. Real-life criminals are not like in the movies - if
military guards point guns at them, they will put their hands in the air
and no one needs to be shot. (It's a different matter for criminals
high on drugs and unable to think rationally, but they don't try to raid >military armouries.)
If shots need to be fired, the primary aim should
be to persuade the bad guys to surrender, not to kill them.
But more broadly, from a military perspective, this doesn't make
a lot of sense to me, because it ignores the human factors at
play in the fog of war.
Due to the sympathetic physiological reaction to stress, one
tends to lose one's fine motor skills in a combat-type situation
and it can be difficult to remember even the most basic bodily
functions: lose of urinary and sphincter control are common,
for example (hence the expression, "scared shitless"). Moreover
long experience in human history shows that it is impossible to
know a priori how one will react: some people are ridiculously
calm in combat, others are not.
While I have (as I said) no military experience, I have a fair bit of >martial art experience - and what you describe is entirely correct.
That is why training is vital - lots of training, simulating real
conditions as accurately as possible. You never get 100% simulation, of >course.
And you train for different tasks. Guards should /not/ be trained to
shoot to kill as a priority - they should be trained for identification
of the threat, de-escalation, and containing and controlling the
situation. The gun is primarily a threat - firing it at all is way down >your list of tactics. A successful outcome is capturing the intruders, >preferably uninjured - killing them is a failure (though not the worst >failure outcome). After all, most people the guard encounters will not
be trying to kill them or infiltrate a building. Other types of assault >groups /will/ be trained for killing or disabling enemies as fast as >possible, keeping the element of surprise - but that's a different job.
For that reason, most people are taught to shoot center-of-mass;
I was in the military when we still used iron sights out to 500
yards (roughly 500 meters). It's one thing to accurately shoot
at that distance when you're on a known-distance range on a
relatively calm day. It's an entirely different matter when
someone is shooting back at you. Anyone who thinks, "I'll just
shoot to wound them!" is deluding themselves.
You don't shoot to wound at 500 yards. At that distance, you are either
a sniper, or shooting to scare the enemy.
There's no point in trying to
aim through sights unless you have the time to do so without the risk of >being killed in the process.
[snip]
Oh, and you have to clean it before turning it back in, too, and
you have to do so to the satisfaction of a Marine Corps armoror
(well, you do if you're a Marine). That said, a little birdie
once told me that if you do a first pass and put a $20 bill in
the breach of the weapon when you turn it back in, they will do
it for you. But I wouldn't know anything about that.
We don't really go in for bribery either in Norway - at least, not at
that level. (In fact, not much at any level - we are not perfect, but
are one of the least corrupt countries.)
Lol, that's not bribery.
You are giving someone cash in hand, outside the regulations, to
overlook your failure to do your job.
Doesn't that count as bribery?
It is very different from having an official policy of fining people for
not cleaning their weapons, or providing cleaning as a paid service.
Zero such guns were ever used in a crime, or stolen from a home, but >>>>>> after a couple of armory breakins where boxes of AG3s got stolen, they >>>>>> (Laber party government at the time) used that as a pretext to withdraw >>>>>> all those guns.
The Swiss still have all their full auto/military guns, they just keep >>>>>> strict control of the ammunition: You bring your empty gun to the range >>>>>> and get your allotment, any unspent rounds have to be returned before >>>>>> you leave.
The same is true in the US military; there is a process of
"lining out" (at least, that's what we called it in the Marine
Corps; I can't speak to other services, though I assume the Navy
is similar) whereby you are physically searched and patted down
to ensure that you're not holding any rounds, intentional or
otherwise.
If you want trustworthy military personell, you need to trust them.
I can't imagine that any other professional military does it
much differently than I described.
Maybe Terje can comment here, since he actually knows how it is done (or
was done) in Norway.
This isn't about trust so much as accountability; the two are of
course related, but different. In particular, it's about
building a warrior culture that emphasizes safety and respect
for the inherent danger of weapons and puts inculcates practices
designed to emphasize and reinforce those traits. Ammunition is
inherently dangerous; it should be treated as such. The
expectation is that service members treat it with respect and
the attention that it inherently deserves. You build that by
enforcing accountability and then pushing that down through the
ranks to the lowest levels: a junior Marine is lined out by
their fireteam leader; the team leaders by their squad leader;
the squad leaders by the Platoon Sergeant, and so on. Junior
Marines see that this is taken seriously and so learn to take it
seriously.
In other words, you build trust that you just described by
emphasizing safety practices, and validate they are followed by
rigorous inspection, thoughout the mundate and ordinary aspects
of training. Hence lineouts, weapons inspections, and "clearing
barrels" that are all designed to habituate safe(r) weapons
handling practices.
It still all sounds a bit lacking in trust to me, and not giving the >responsibility in the right way. Having a pat-down is telling the
soldier that you do not believe he/she is responsible enough to be
around ammunition - you are saying that you think they are either
dishonest and actively taking ammunition, or thoughtless and
irresponsible enough to do so by accident. And you are telling them
that /they/ don't have to worry about safety - you'll take care of it
for them.
On the other hand, telling them to check all their pockets before
leaving is encouraging a checklist mentality - teaching them to do this
as a specific automatic task every time they leave the range, without >exception. It's the same as other gun-safety checks, like confirming
the safety on a gun you are handed even if you have just watched the
other person do the same check.
Note that this is one of the things I find so troubling about
the "2A" gun culture in the United States. It fetishizes
weapons and deemphasiizes safety practices so that its adherents
can be "ready" at all times (for what?). These people aren't
just deluded about the relative risks of owning and carrying
weapons, they're actively dangerous because they have no idea
what they are doing.
Agreed.
As
a teenager in the UK, I was in the "cadets" at school - once a week we'd >>> have a few hours in military uniforms, learning marching, gun safety,
and a bit of fun stuff like camouflage, abseiling, and stuff. It also
included shooting at a barracks gun range - serious sized rounds with
long outdated rifles. We were just fifteen year-old "toy soldiers", and >>> we were /asked/ to check our pockets for extra rounds or empty casings.
That's disturbing.
Sounds like the people who ran your "cadets" program did you a
disservice by failing to emphasize proper weapons and ammo
handling practices.
I disagree entirely. I think it /does/ emphasise the safety - and it >emphasises that each person is personally responsible for the safety,
not just the trainers (who were real soldiers).
Having worked with actual British forces in Afghanistan, I know
that they take weapons safety as seriously as we do. Perhaps
don't extrapolate from that to what an actual military does.
Taking weapons safety just as seriously does not mean doing things in >exactly the same way.
But I don't have any related experience to say how things are actually done.
MitchAlsup <user5857@newsgrouper.org.invalid> writes:
scott@slp53.sl.home (Scott Lurndal) posted:
David Brown <david.brown@hesbynett.no> writes:
On 15/04/2026 13:30, Dan Cross wrote:
In article <n48bl0Fdbm4U1@mid.individual.net>,
moi <findlaybill@blueyonder.co.uk> wrote:
On 15/04/2026 01:44, MitchAlsup wrote:
<snip>
Broadly speaking, they're a pain, and pretty much only useful as
either a suppression weapon or for guarding avenues of approach
to fixed defensive positions.
They're also extremely expensive to use and maintain. at $2.00 or
more _per round_, the cost rises rapidly.
I reload 308W for $0.36 and 223 for $0.23 with match grade components. >{But, then again, I bought my components a long time ago}
How long does it take you to reload 500 rounds?
On 4/15/2026 1:00 PM, David Brown wrote:
On 15/04/2026 21:33, Terje Mathisen wrote:
moi wrote:
On 15/04/2026 01:44, MitchAlsup wrote:Anyone from (current) Switzerland or pre-1992 Norway would say that
If you fill out the right forms, fill in the right paperwork, pay the >>>> tax stamp cost, and wait through Sheriff interviews, and wait the ~18 >>>> months, you can legally own a fully automatic firearm.
One should also note: in the history of this system (~late 1930s)
to present: only 2 properly registered FA guns have been used in
any crimes. {Anyone with a brain would say this is a pretty good
record}
Anyone with a non-USAn brain would say this is utterly insane.
this is perfectly normal:
Every single home guard (think National Guard) member and every
reserve office, from NCOs up to general, had their AG3 (HK G3) in 7.62
NATO, with at least 150 rounds of ammo, at home. This was somewhere
around 300 000 guns in a country of less than 5M people, so one in
every three or four households.
The only security requirement was that you had to take out the firing
pin and store it apart from the gun.
These are not civilian guns. No one considers their National Guard gun as "their" gun - they have it for use in National Guard exercises or call-outs. The gun are always stored safely - kids can't show off Dad's gun to their friends and accidentally kill them.
Right! Hey look at this. Self dead, and friends dead/injured. Actually,
I was at a friend of a friends house. A big house in Discovery Bay California. His parent was gone, Dad divorced... He pulled out a big revolver, might have been a 45 caliber. Holes galore. said he was able
to find it from his Dad. I instantly asked him to show it to me. I
looked and found that there were two rounds of ammo in the chamber. God,
I could have died that day! I said all guns are loaded, that's the mindset... He said he thought it was empty. Oh my!
I was a kiddo at the time. But, my Dad made me take hunters safety
courses. I got A's! I will never forget how to proper cross a fence with
a gun.
And the members of the
National Guard are already vetted for being sensible, intelligent,
honest and reliable people. (No such vetting is perfect, but it's
pretty good.)
Zero such guns were ever used in a crime, or stolen from a home, but
after a couple of armory breakins where boxes of AG3s got stolen, they
(Laber party government at the time) used that as a pretext to
withdraw all those guns.
The Swiss still have all their full auto/military guns, they just keep
strict control of the ammunition: You bring your empty gun to the
range and get your allotment, any unspent rounds have to be returned
before you leave.
Terje
On 16/04/2026 13:59, Dan Cross wrote:I have _never_ seen an actual pat-down looking for spare rounds in the
In article <10rqag7$1in0h$1@dont-email.me>,
David Brown <david.brown@hesbynett.no> wrote:
On 15/04/2026 22:35, Dan Cross wrote:
In article <10roqpe$16j1j$2@dont-email.me>,
The same is true in the US military; there is a process of
"lining out" (at least, that's what we called it in the Marine
Corps; I can't speak to other services, though I assume the Navy
is similar) whereby you are physically searched and patted down
to ensure that you're not holding any rounds, intentional or
otherwise.
If you want trustworthy military personell, you need to trust them.
I can't imagine that any other professional military does it
much differently than I described.
Maybe Terje can comment here, since he actually knows how it is done (or
was done) in Norway.
In article <10rqrkf$1nbrp$1@dont-email.me>,
David Brown <david.brown@hesbynett.no> wrote:
On 16/04/2026 13:59, Dan Cross wrote:
You don't shoot to wound at 500 yards. At that distance, you are either
a sniper, or shooting to scare the enemy.
Actually, Marines are trained to accurately engage the enemy out
to those distances. With the RCO, its not even that hard.
Maybe soldiers from the US Army could even do it.
Chris M. Thomasson <chris.m.thomasson.1@gmail.com> schrieb:
On 4/15/2026 1:28 PM, Thomas Koenig wrote:
Chris M. Thomasson <chris.m.thomasson.1@gmail.com> schrieb:
Say target on single fire mode. Missed! Turn to auto and give a burst. >>> Or don't for what about 3 round burst? They are moving now. No single
sniper mode. A suppress fully auto can make the target think there might >>> be more than one person out there. Reminds me of the following scene:
Firing suppressive fire in full auto is not what assault guns are for.
That's what real machine guns are for.
Tu. But, they can scare the shit out of the target. They know round are going down range toward them. Therefore, they are in peril? But, the
ammo issue, ugg.
I first used the G3 at the Bundeswehr. 600 rounds per minute, 20
rounds per magazine. Firing that weapon at full auto will empty
it in a tid less than two seconds (note fencepost error here :-)
Firing short bursts or single shots will keep any enemy down for
a far longer time than that.
But a squad at the time had a MG3 (1200 rounds per minute) with it.
But firing that continously is also not a good idea because
a) ammunition: 24 grams per round means that you run through 0.48
kg (a bit more than a pound :-) per second of ammunition, which
somebody has to carry
b) you have to exchange barrels and locks after a certain number
of rounds to prevent overheating.
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> posted:That's the first and most obvious tell.
On 4/15/2026 1:00 PM, David Brown wrote:
On 15/04/2026 21:33, Terje Mathisen wrote:
moi wrote:
On 15/04/2026 01:44, MitchAlsup wrote:Anyone from (current) Switzerland or pre-1992 Norway would say that
If you fill out the right forms, fill in the right paperwork, pay the >>>>>> tax stamp cost, and wait through Sheriff interviews, and wait the ~18 >>>>>> months, you can legally own a fully automatic firearm.
One should also note: in the history of this system (~late 1930s)
to present: only 2 properly registered FA guns have been used in
any crimes. {Anyone with a brain would say this is a pretty good
record}
Anyone with a non-USAn brain would say this is utterly insane.
this is perfectly normal:
Every single home guard (think National Guard) member and every
reserve office, from NCOs up to general, had their AG3 (HK G3) in 7.62 >>>> NATO, with at least 150 rounds of ammo, at home. This was somewhere
around 300 000 guns in a country of less than 5M people, so one in
every three or four households.
The only security requirement was that you had to take out the firing
pin and store it apart from the gun.
These are not civilian guns. No one considers their National Guard gun >>> as "their" gun - they have it for use in National Guard exercises or
call-outs. The gun are always stored safely - kids can't show off Dad's >>> gun to their friends and accidentally kill them.
Right! Hey look at this. Self dead, and friends dead/injured. Actually,
I was at a friend of a friends house. A big house in Discovery Bay
California. His parent was gone, Dad divorced... He pulled out a big
revolver, might have been a 45 caliber. Holes galore. said he was able>> to find it from his Dad. I instantly asked him to show it to me. I
looked and found that there were two rounds of ammo in the chamber. God,
You can tell if a person with a gun knows about gun safety as he first touches the gun, he checks to see if it is unloaded and if not unloads
it prior to letting anyone else touch it.
cross@spitfire.i.gajendra.net (Dan Cross) writes:
In article <10rqrkf$1nbrp$1@dont-email.me>,
David Brown <david.brown@hesbynett.no> wrote:
On 16/04/2026 13:59, Dan Cross wrote:
<snip>
You don't shoot to wound at 500 yards. At that distance, you are either >>>a sniper, or shooting to scare the enemy.
Actually, Marines are trained to accurately engage the enemy out
to those distances. With the RCO, its not even that hard.
Maybe soldiers from the US Army could even do it.
My nephew is in the Corps. He's on the flight line as
an ordy[*], but still has qualified as expert marksman for the
last four years running.
[*] recently transferred to the CH-53E fleet due to the imminent
retirement of the F-16C fleet.
On 15 Apr 2026, David Brown wrote
(in article <10roqep$16j1j$1@dont-email.me>):
On 15/04/2026 17:36, quadi wrote:That is the bit they really can't fathom.
On Wed, 15 Apr 2026 03:32:00 +0100, moi wrote:
On 15/04/2026 01:44, MitchAlsup wrote:
One should also note: in the history of this system (~late 1930s)
to present: only 2 properly registered FA guns have been used in any >>>>> crimes. {Anyone with a brain would say this is a pretty good record}
Anyone with a non-USAn brain would say this is utterly insane.
Utterly insane would be if the same procedure applied to thermonuclear
warheads.
Of course, much about the consequences of the Second Amendment indeed does >>> appear insane. The sensible thing to do would be to repeal it, rather than >>> pretend it doesn't exist, or it doesn't mean what it says, and hope the
Supreme Court will look the other way.
[wise words omitted]
That's just my two cents - coming from someone in a country ...
where we have far more real-world freedoms than the USA.
You can tell if a person with a gun knows about gun safety as he first >touches the gun, he checks to see if it is unloaded and if not unloads
it prior to letting anyone else touch it.
In article <079ER.43148$7WA4.42916@fx48.iad>,
Scott Lurndal <slp53@pacbell.net> wrote:
cross@spitfire.i.gajendra.net (Dan Cross) writes:
In article <10rqrkf$1nbrp$1@dont-email.me>,
David Brown <david.brown@hesbynett.no> wrote:
On 16/04/2026 13:59, Dan Cross wrote:
<snip>
You don't shoot to wound at 500 yards. At that distance, you are either >>>>a sniper, or shooting to scare the enemy.
Actually, Marines are trained to accurately engage the enemy out
to those distances. With the RCO, its not even that hard.
Maybe soldiers from the US Army could even do it.
My nephew is in the Corps. He's on the flight line as
an ordy[*], but still has qualified as expert marksman for the
last four years running.
That's a dangerous job.
But yeah, "Every Marine a Rifleman First". Though if you talk
to people in the 03 (USMC infantry) community, they'll say that
is nonsense. As a career communicator, I tend to agree: the
Marine Corps has a definition of a rifleman, and that's an 0311.
If a Marine is not trained to that standard, they cannot really
call themselves a rifleman.
What I ultimately came out interpreting the "every Marine a
rifleman first" to mean is that the Marine Corps keeps Marines
trained to the extent that they can be folded into a grunt unit,
and OJT'd to an operationally-capable level. Hence, annual
marksmanship training, continuous training in hand-to-hand
combat, regula4r organized physical training, etc. That is, we
reserve the right to take any Marine and insert them into a line
unit to serve as a rifleman, regardless of their primary MOS.
[*] recently transferred to the CH-53E fleet due to the imminent
retirement of the F-16C fleet.
The Marine Corps doesn't fly the F-16. :-) Perhaps you mean
the F/A-18 or the Harrier?
cross@spitfire.i.gajendra.net (Dan Cross) writes:
In article <079ER.43148$7WA4.42916@fx48.iad>,
Scott Lurndal <slp53@pacbell.net> wrote:
cross@spitfire.i.gajendra.net (Dan Cross) writes:
In article <10rqrkf$1nbrp$1@dont-email.me>,
David Brown <david.brown@hesbynett.no> wrote:
On 16/04/2026 13:59, Dan Cross wrote:
<snip>
You don't shoot to wound at 500 yards. At that distance, you are either >>>>>a sniper, or shooting to scare the enemy.
Actually, Marines are trained to accurately engage the enemy out
to those distances. With the RCO, its not even that hard.
Maybe soldiers from the US Army could even do it.
My nephew is in the Corps. He's on the flight line as
an ordy[*], but still has qualified as expert marksman for the
last four years running.
That's a dangerous job.
But yeah, "Every Marine a Rifleman First". Though if you talk
to people in the 03 (USMC infantry) community, they'll say that
is nonsense. As a career communicator, I tend to agree: the
Marine Corps has a definition of a rifleman, and that's an 0311.
If a Marine is not trained to that standard, they cannot really
call themselves a rifleman.
What I ultimately came out interpreting the "every Marine a
rifleman first" to mean is that the Marine Corps keeps Marines
trained to the extent that they can be folded into a grunt unit,
and OJT'd to an operationally-capable level. Hence, annual
marksmanship training, continuous training in hand-to-hand
combat, regula4r organized physical training, etc. That is, we
reserve the right to take any Marine and insert them into a line
unit to serve as a rifleman, regardless of their primary MOS.
[*] recently transferred to the CH-53E fleet due to the imminent >>>retirement of the F-16C fleet.
The Marine Corps doesn't fly the F-16. :-) Perhaps you mean
the F/A-18 or the Harrier?
Brain fart. His squadron flys the F/A-18C and D models. The
E's and F's will remain in the active fleet along with the F-35,
but the final days of the C and D models are in sight.
I got to visit the flight line in 2024, very interesting.
Prior visit to a Marine base was at 29 Palms in the 1980s, visiting
a cousin. He was living on-base in married housing and told
me to avoid the well-lit compound several miles east of the housing area, which
was secured and managed by the NOP.
Thomas Koenig <tkoenig@netcologne.de> posted:
Chris M. Thomasson <chris.m.thomasson.1@gmail.com> schrieb:
On 4/15/2026 1:28 PM, Thomas Koenig wrote:
Chris M. Thomasson <chris.m.thomasson.1@gmail.com> schrieb:
Say target on single fire mode. Missed! Turn to auto and give a burst. >>>>> Or don't for what about 3 round burst? They are moving now. No single >>>>> sniper mode. A suppress fully auto can make the target think there might >>>>> be more than one person out there. Reminds me of the following scene: >>>>Firing suppressive fire in full auto is not what assault guns are for. >>>> That's what real machine guns are for.
Tu. But, they can scare the shit out of the target. They know round are
going down range toward them. Therefore, they are in peril? But, the
ammo issue, ugg.
I first used the G3 at the Bundeswehr. 600 rounds per minute, 20
rounds per magazine. Firing that weapon at full auto will empty
it in a tid less than two seconds (note fencepost error here :-)
Firing short bursts or single shots will keep any enemy down for
a far longer time than that.
But a squad at the time had a MG3 (1200 rounds per minute) with it.
But firing that continously is also not a good idea because
a) ammunition: 24 grams per round means that you run through 0.48
kg (a bit more than a pound :-) per second of ammunition, which
somebody has to carry
b) you have to exchange barrels and locks after a certain number
of rounds to prevent overheating.
Where the military definition of overheating is: "The bullets no longer
go anywhere close to where the barrel is pointing".
5 rounds at 20 second intervals is enough to heat a sniper barrel
to the point it is not "accurate enough". Now, imaging those 5
rounds in 0.5 seconds ...
MitchAlsup wrote:
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> posted:
On 4/15/2026 1:00 PM, David Brown wrote:
On 15/04/2026 21:33, Terje Mathisen wrote:
moi wrote:
On 15/04/2026 01:44, MitchAlsup wrote:Anyone from (current) Switzerland or pre-1992 Norway would say that
If you fill out the right forms, fill in the right paperwork, pay >>>>>>> the
tax stamp cost, and wait through Sheriff interviews, and wait the >>>>>>> ~18
months, you can legally own a fully automatic firearm.
One should also note: in the history of this system (~late 1930s) >>>>>>> to present: only 2 properly registered FA guns have been used in >>>>>>> any crimes. {Anyone with a brain would say this is a pretty good >>>>>>> record}
Anyone with a non-USAn brain would say this is utterly insane.
this is perfectly normal:
Every single home guard (think National Guard) member and every
reserve office, from NCOs up to general, had their AG3 (HK G3) in 7.62 >>>>> NATO, with at least 150 rounds of ammo, at home. This was somewhere
around 300 000 guns in a country of less than 5M people, so one in
every three or four households.
The only security requirement was that you had to take out the firing >>>>> pin and store it apart from the gun.
These are not civilian guns. No one considers their National Guard >>>> gun
as "their" gun - they have it for use in National Guard exercises or
call-outs. The gun are always stored safely - kids can't show off >>>> Dad's
gun to their friends and accidentally kill them.
Right! Hey look at this. Self dead, and friends dead/injured. Actually,
I was at a friend of a friends house. A big house in Discovery Bay
California. His parent was gone, Dad divorced... He pulled out a big
revolver, might have been a 45 caliber. Holes galore. said he was able
to find it from his Dad. I instantly asked him to show it to me. I
looked and found that there were two rounds of ammo in the chamber. God,
You can tell if a person with a gun knows about gun safety as he first
touches the gun, he checks to see if it is unloaded and if not unloads
it prior to letting anyone else touch it.
That's the first and most obvious tell.
Even if I've watched my brother-in-law empty, check, dry fire away from everyone, his pistol before he hands it to me, I'll still do the same
checks myself.
The other and slightly more subtle one is trigger finger placement: If
it is anywhere inside the trigger guard before the range officer have
given the ready to fire command, then stop them at once.
(I have done this once or twice during these 50 years, each time I got a proper dressing down so I would remember it.)
On 4/16/2026 10:46 AM, Terje Mathisen wrote:
MitchAlsup wrote:
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> posted:
On 4/15/2026 1:00 PM, David Brown wrote:
On 15/04/2026 21:33, Terje Mathisen wrote:
moi wrote:
On 15/04/2026 01:44, MitchAlsup wrote:Anyone from (current) Switzerland or pre-1992 Norway would say that >>>>>> this is perfectly normal:
If you fill out the right forms, fill in the right paperwork, >>>>>>>> pay the
tax stamp cost, and wait through Sheriff interviews, and wait >>>>>>>> the ~18
months, you can legally own a fully automatic firearm.
One should also note: in the history of this system (~late 1930s) >>>>>>>> to present: only 2 properly registered FA guns have been used in >>>>>>>> any crimes. {Anyone with a brain would say this is a pretty good >>>>>>>> record}
Anyone with a non-USAn brain would say this is utterly insane.
Every single home guard (think National Guard) member and every
reserve office, from NCOs up to general, had their AG3 (HK G3) in >>>>>> 7.62
NATO, with at least 150 rounds of ammo, at home. This was somewhere >>>>>> around 300 000 guns in a country of less than 5M people, so one in >>>>>> every three or four households.
The only security requirement was that you had to take out the firing >>>>>> pin and store it apart from the gun.
These are not civilian guns. No one considers their National
Guard gun
as "their" gun - they have it for use in National Guard exercises or >>>>> call-outs. The gun are always stored safely - kids can't show off >>>>> Dad's
gun to their friends and accidentally kill them.
Right! Hey look at this. Self dead, and friends dead/injured. Actually, >>>> I was at a friend of a friends house. A big house in Discovery Bay
California. His parent was gone, Dad divorced... He pulled out a big
revolver, might have been a 45 caliber. Holes galore. said he was able >>>> to find it from his Dad. I instantly asked him to show it to me. I
looked and found that there were two rounds of ammo in the chamber.
God,
You can tell if a person with a gun knows about gun safety as he first
touches the gun, he checks to see if it is unloaded and if not unloads
it prior to letting anyone else touch it.
That's the first and most obvious tell.
Even if I've watched my brother-in-law empty, check, dry fire away
from everyone, his pistol before he hands it to me, I'll still do the
same checks myself.
The other and slightly more subtle one is trigger finger placement: If
it is anywhere inside the trigger guard before the range officer have
given the ready to fire command, then stop them at once.
Absolutely. No reason to have a finger on the trigger unless you intend
to open fire on something. Also, be sure to check the safety! Load a
round, put the safety on, point down range, pull the trigger over and
over again. It should not go off. Turn safety off, then it should fire.
(I have done this once or twice during these 50 years, each time I got
a proper dressing down so I would remember it.)
Oh yeah!
cross@spitfire.i.gajendra.net (Dan Cross) writes:
In article <079ER.43148$7WA4.42916@fx48.iad>,
Scott Lurndal <slp53@pacbell.net> wrote:
cross@spitfire.i.gajendra.net (Dan Cross) writes:
In article <10rqrkf$1nbrp$1@dont-email.me>,
David Brown <david.brown@hesbynett.no> wrote:
On 16/04/2026 13:59, Dan Cross wrote:
<snip>
You don't shoot to wound at 500 yards. At that distance, you are either >>>>> a sniper, or shooting to scare the enemy.
Actually, Marines are trained to accurately engage the enemy out
to those distances. With the RCO, its not even that hard.
Maybe soldiers from the US Army could even do it.
My nephew is in the Corps. He's on the flight line as
an ordy[*], but still has qualified as expert marksman for the
last four years running.
That's a dangerous job.
But yeah, "Every Marine a Rifleman First". Though if you talk
to people in the 03 (USMC infantry) community, they'll say that
is nonsense. As a career communicator, I tend to agree: the
Marine Corps has a definition of a rifleman, and that's an 0311.
If a Marine is not trained to that standard, they cannot really
call themselves a rifleman.
What I ultimately came out interpreting the "every Marine a
rifleman first" to mean is that the Marine Corps keeps Marines
trained to the extent that they can be folded into a grunt unit,
and OJT'd to an operationally-capable level. Hence, annual
marksmanship training, continuous training in hand-to-hand
combat, regula4r organized physical training, etc. That is, we
reserve the right to take any Marine and insert them into a line
unit to serve as a rifleman, regardless of their primary MOS.
[*] recently transferred to the CH-53E fleet due to the imminent
retirement of the F-16C fleet.
The Marine Corps doesn't fly the F-16. :-) Perhaps you mean
the F/A-18 or the Harrier?
Brain fart. His squadron flys the F/A-18C and D models. The
E's and F's will remain in the active fleet along with the F-35,
but the final days of the C and D models are in sight.
I got to visit the flight line in 2024, very interesting.
Prior visit to a Marine base was at 29 Palms in the 1980s, visiting
a cousin. He was living on-base in married housing and told
me to avoid the well-lit compound several miles east of the housing area, which
was secured and managed by the NOP.
On 4/15/2026 5:44 PM, Bill Findlay wrote:
On 15 Apr 2026, David Brown wrote
(in article <10roqep$16j1j$1@dont-email.me>):
On 15/04/2026 17:36, quadi wrote:That is the bit they really can't fathom.
On Wed, 15 Apr 2026 03:32:00 +0100, moi wrote:
On 15/04/2026 01:44, MitchAlsup wrote:
One should also note: in the history of this system (~late 1930s)Anyone with a non-USAn brain would say this is utterly insane.
to present: only 2 properly registered FA guns have been used in any >>>>>> crimes. {Anyone with a brain would say this is a pretty good record} >>>>
Utterly insane would be if the same procedure applied to thermonuclear >>>> warheads.
Of course, much about the consequences of the Second Amendment
indeed does
appear insane. The sensible thing to do would be to repeal it,
rather than
pretend it doesn't exist, or it doesn't mean what it says, and hope the >>>> Supreme Court will look the other way.
[wise words omitted]
That's just my two cents - coming from someone in a country ...
where we have far more real-world freedoms than the USA.
?...
But, AFAIK, the UK is the place that went and banned:
Sharp points on knives;
Sharp points on scissors;
Buying solder without having certifications;
So, it is effectively sold black-market in small amounts,
to the electronics hobbyists.
MitchAlsup <user5857@newsgrouper.org.invalid> writes:
You can tell if a person with a gun knows about gun safety as he first >touches the gun, he checks to see if it is unloaded and if not unloads
it prior to letting anyone else touch it.
While true, if someone tried to hand me a bolt-action rifle with
the bolt in place, I'd refuse. Likewise any magazine fed
weapon should not have a magazine installed and the action should
be open, if possible before handed to anyone.
In article <SlNDR.276690$4wI6.88606@fx24.iad>,
Scott Lurndal <slp53@pacbell.net> wrote:
David Brown <david.brown@hesbynett.no> writes:
On 15/04/2026 13:30, Dan Cross wrote:
In article <n48bl0Fdbm4U1@mid.individual.net>,
moi <findlaybill@blueyonder.co.uk> wrote:
On 15/04/2026 01:44, MitchAlsup wrote:
<snip>
Broadly speaking, they're a pain, and pretty much only useful as
either a suppression weapon or for guarding avenues of approach
to fixed defensive positions.
They're also extremely expensive to use and maintain. at $2.00 or
more _per round_, the cost rises rapidly.
Full-auto weapons are also heavy, and so is the ammo. Carrying
even a SAW is no fun after a few hours; a 240 or Ma Deuce? Not
happening. A Mk19? Forget about it.
Mythbusters shot a minigun on a couple episodes and the ammo cost
(more than a decade ago) was huge.
I suppose that the proponents will point to smaller weapons
systems, like submachine guns, that are full-auto but shoot
conventional cartidges (the Thompson shoots .45ACP, for example)
but they often don't realize that the kickback makes them
difficult to control. Even the 3-round burst on the M4/M16
pattern weapons will kick you off target almost instantly; that
mode is only useful as a direct fire alternative for suppression
to support advancing infantry in a complex attack scenario when
indirect fire is not viable, you don't have combined-arms
support, or you don't have crew-served weapons. It's like a
method of last resort.
I don't know why anyone would want a full-auto weapon as
anything other than a museum piece or a novelty. I strongly
suspect that such people have never heard a shot fired in anger
before.
- Dan C.
On 4/15/2026 5:44 PM, Bill Findlay wrote:
On 15 Apr 2026, David Brown wrote
(in article <10roqep$16j1j$1@dont-email.me>):
On 15/04/2026 17:36, quadi wrote:
On Wed, 15 Apr 2026 03:32:00 +0100, moi wrote:
On 15/04/2026 01:44, MitchAlsup wrote:
One should also note: in the history of this system (~late 1930s) to present: only 2 properly registered FA guns have been used in any
crimes. {Anyone with a brain would say this is a pretty good record}
Anyone with a non-USAn brain would say this is utterly insane.
Utterly insane would be if the same procedure applied to thermonuclear warheads.
Of course, much about the consequences of the Second Amendment indeed does
appear insane. The sensible thing to do would be to repeal it, rather than
pretend it doesn't exist, or it doesn't mean what it says, and hope the Supreme Court will look the other way.
[wise words omitted]
That's just my two cents - coming from someone in a country ...That is the bit they really can't fathom.
where we have far more real-world freedoms than the USA.
?...
But, AFAIK, the UK is the place that went and banned:
Sharp points on knives;
Sharp points on scissors;
Buying solder without having certifications;
So, it is effectively sold black-market in small amounts,
to the electronics hobbyists.
...
And, where a person can be arrested, for stuff they say on social media
(or "thought crime" as some are calling it);
Where corporations can lead search-and-seizure operations for claimed IP violations;
On 16 Apr 2026, BGB wrote
(in article <10rr8vi$1sh0n$1@dont-email.me>):
On 4/15/2026 5:44 PM, Bill Findlay wrote:
On 15 Apr 2026, David Brown wrote
(in article <10roqep$16j1j$1@dont-email.me>):
On 15/04/2026 17:36, quadi wrote:That is the bit they really can't fathom.
On Wed, 15 Apr 2026 03:32:00 +0100, moi wrote:
On 15/04/2026 01:44, MitchAlsup wrote:
One should also note: in the history of this system (~late 1930s) >>>>>>> to present: only 2 properly registered FA guns have been used in any >>>>>>> crimes. {Anyone with a brain would say this is a pretty good record} >>>>>Anyone with a non-USAn brain would say this is utterly insane.
Utterly insane would be if the same procedure applied to thermonuclear >>>>> warheads.
Of course, much about the consequences of the Second Amendment indeed does
appear insane. The sensible thing to do would be to repeal it, rather than
pretend it doesn't exist, or it doesn't mean what it says, and hope the >>>>> Supreme Court will look the other way.
[wise words omitted]
That's just my two cents - coming from someone in a country ...
where we have far more real-world freedoms than the USA.
?...
But, AFAIK, the UK is the place that went and banned:
Sharp points on knives;
Sharp points on scissors;
Buying solder without having certifications;
So, it is effectively sold black-market in small amounts,
to the electronics hobbyists.
...
And, where a person can be arrested, for stuff they say on social media
(or "thought crime" as some are calling it);
Where corporations can lead search-and-seizure operations for claimed IP
violations;
It is clear from that claptrap that in fact you know very little.
(MAGA shills like JD are not a trustworthy source of information.)
In article <NdaER.1511$r_k6.609@fx38.iad>,<snip>
Scott Lurndal <slp53@pacbell.net> wrote:
[*] recently transferred to the CH-53E fleet due to the imminent >>>>retirement of the F-16C fleet.
The Marine Corps doesn't fly the F-16. :-) Perhaps you mean
the F/A-18 or the Harrier?
Brain fart. His squadron flys the F/A-18C and D models. The
E's and F's will remain in the active fleet along with the F-35,
but the final days of the C and D models are in sight.
No problem; I can see wanting to switch over to helos from fixed
wing. It's a different world.
I got to visit the flight line in 2024, very interesting.
Cool.
Prior visit to a Marine base was at 29 Palms in the 1980s, visiting
a cousin. He was living on-base in married housing and told
me to avoid the well-lit compound several miles east of the housing area, which
was secured and managed by the NOP.
Ah, the stumps. I remember the first time I got there, stepping
off a bus (we'd just flown from NC, having completed post Parris
Island training at Camp Lejeune) and immediately seeing tumble
weed blowing down the main drag. "Oh my god; I have to stay
here for a YEAR?!" (This was before I became an officer.)
I wonder which part your cousin meant; perhaps Camp Wilson,
which is an active training area (and pretty much nothing else,
though there is a very small PX there selling pogey bait).
On 4/16/2026 11:52 AM, Scott Lurndal wrote:
Brain fart. His squadron flys the F/A-18C and D models. The
E's and F's will remain in the active fleet along with the F-35,
Can he fly the F-35?
And, where a person can be arrested, for stuff they say on social media
(or "thought crime" as some are calling it);
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:
On 4/16/2026 11:52 AM, Scott Lurndal wrote:
Brain fart. His squadron flys the F/A-18C and D models. The
E's and F's will remain in the active fleet along with the F-35,
Can he fly the F-35?
Only if he gets a ride in the back seat. Which, since the F35
is a single seater, is not gonna happen.
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:
On 4/16/2026 11:52 AM, Scott Lurndal wrote:
Brain fart. His squadron flys the F/A-18C and D models. The
E's and F's will remain in the active fleet along with the F-35,
Can he fly the F-35?
Only if he gets a ride in the back seat. Which, since the F35
is a single seater, is not gonna happen.
On Thu, 16 Apr 2026 13:15:13 -0500, BGB wrote:
And, where a person can be arrested, for stuff they say on social media
(or "thought crime" as some are calling it);
Almost all countries other than the United States limit freedom of speech
by excluding the incitment of hatred towards minority groups.
This is perhaps a natural result of Europe having had World War II fought
on its own soil, and so they consider it a matter of survival to prevent
the rise of another movement similar to Nazism.
Given current political trends in Europe, I have to say it's a pity they didn't think that one way to prevent the rise of bigoted extremist
movements would have been not to have such a liberal immigration policy
that the demographic consequences would end up being an annoyance to a lot
of ordinary people not previously inclined to bigotry.
Now, I took out one excessively elaborate header format, and restored a feature to the architecture that I took out when pruning header types,
but this time in a different form, associated with a different header
type.
And now I rearranged the headers a bit, to defragment their opcode
space.
Thomas Koenig <tkoenig@netcologne.de> posted:
I first used the G3 at the Bundeswehr. 600 rounds per minute, 20
rounds per magazine. Firing that weapon at full auto will empty
it in a tid less than two seconds (note fencepost error here :-)
Firing short bursts or single shots will keep any enemy down for
a far longer time than that.
But a squad at the time had a MG3 (1200 rounds per minute) with it.
But firing that continously is also not a good idea because
a) ammunition: 24 grams per round means that you run through 0.48
kg (a bit more than a pound :-) per second of ammunition, which
somebody has to carry
b) you have to exchange barrels and locks after a certain number
of rounds to prevent overheating.
Where the military definition of overheating is: "The bullets no longer
go anywhere close to where the barrel is pointing".
5 rounds at 20 second intervals is enough to heat a sniper barrel
to the point it is not "accurate enough". Now, imaging those 5
rounds in 0.5 seconds ...
On 4/15/2026 5:44 PM, Bill Findlay wrote:
On 15 Apr 2026, David Brown wrote
(in article <10roqep$16j1j$1@dont-email.me>):
On 15/04/2026 17:36, quadi wrote:That is the bit they really can't fathom.
On Wed, 15 Apr 2026 03:32:00 +0100, moi wrote:
On 15/04/2026 01:44, MitchAlsup wrote:
One should also note: in the history of this system (~late 1930s)Anyone with a non-USAn brain would say this is utterly insane.
to present: only 2 properly registered FA guns have been used in any >>>>>> crimes. {Anyone with a brain would say this is a pretty good record} >>>>
Utterly insane would be if the same procedure applied to thermonuclear >>>> warheads.
Of course, much about the consequences of the Second Amendment
indeed does
appear insane. The sensible thing to do would be to repeal it,
rather than
pretend it doesn't exist, or it doesn't mean what it says, and hope the >>>> Supreme Court will look the other way.
[wise words omitted]
That's just my two cents - coming from someone in a country ...
where we have far more real-world freedoms than the USA.
?...
But, AFAIK, the UK is the place that went and banned:
Sharp points on knives;
Sharp points on scissors;
Buying solder without having certifications;
So, it is effectively sold black-market in small amounts,
to the electronics hobbyists.
...
And, where a person can be arrested, for stuff they say on social media
(or "thought crime" as some are calling it);
Where corporations can lead search-and-seizure operations for claimed IP violations;
...
So, sorta like California but worse...
California apparently banned the 60/40 lead/tin stuff IIRC, but still
allows people to freely possess lead-free solder (so people apparently
need to smuggle the 60/40 into CA if they want to use it). Everywhere
else, 60/40 is OK. Well, and CA has the "age verification" controversy,
etc.
Could be wrong, this is from memory and stuff I heard on the internet.
In article <10rqrkf$1nbrp$1@dont-email.me>,
David Brown <david.brown@hesbynett.no> wrote:
On 16/04/2026 13:59, Dan Cross wrote:
In article <10rqag7$1in0h$1@dont-email.me>,
David Brown <david.brown@hesbynett.no> wrote:
[snip]
(The service members have all their other equipment at
home too - they store their own uniforms and other stuff, and are
responsible for washing and repairs or ordering replacements after the >>>> exercises.)
The same is true in the US military. I always found it annoying
that I had to make space for my issued equipment at home, but
c'est la vie.
Personally, I have no military experience at all (not counting school
cadets). But one of my sons joined the National Guard after his
military service. He has a neat solution to problem of space for his
equipment - he keeps it in his old bedroom in our house, not in his own
flat :-)
Seems like your son should take his obligations a bit more
seriously: keeping his equipment at your house, when it's
supposed to be in his dwelling, sounds like a rules violation.
What's good for the goose is good for the gander.
It also means that there are less guns stored in
concentrated places as potential targets for robberies. And in the
event of a real invasion, it's a lot easier to smugle around and
distribute firing pins to service members than to pass around guns from >>>> a central armoury.
There are tradeoffs, however: it is also easier for a bad actor
to source a weapon by breaking into a private home.
It is plausible, but AFAIK it is extremely rare here. The solid
majority of criminals here don't want guns, and would probably not take
one if they found one in a house they were robbing. As a house burglar,
you can't easily sell a gun, you don't need one for defence, you don't
need one to threaten anyone - it just increases your chance of being
shot yourself, and increases your punishment if you get got. There are
guns in the more serious narcotics gangs, but those are handguns - they
have no use for military weapons.
FWIW, handguns are military weapoons.
My T/E weapons in Afghanistan were a 9mm handgun and an M4
carbine. I was embedded with an Afghan Army Unit, and was armed
pretty much at all time. This was at a time when we knew there
were Taliban infiltrators in the army. Indeed, I mentioned
working with UK forces: such an infiltrator threw a hand grenade
into a tent full of British soldiers, who were sleeping at the
time (this was in the middle of the night) and sprayed it with
fire from an AK-47, killing three and wounding several more.
That is to say, we were at a relatively low, but constant and
higher than baseline level of risk that most ISAF troops were
not subject to. Despite that, and despite being directly and
indirectly threatened myself on multiple occasions, I only
carried my pistol unless I was outside the wire.
We also don't really go in for shoot-to-kill in Norway.
Note that I'm talking about the use of deadly force to prevent a
bad actor from forcibly taking military-grade arms. That is
exactly the sort of thing that deadly force arguably _should_ be
authorized for.
There is a distinction (which I did not make, but should have) between
authorising deadly force, and encouraging it. As a last resort, it
makes sense in situations like this. But it should be very much the
last resort. Real-life criminals are not like in the movies - if
military guards point guns at them, they will put their hands in the air
and no one needs to be shot. (It's a different matter for criminals
high on drugs and unable to think rationally, but they don't try to raid
military armouries.)
Of course there, is a continuum of force, and despite recent
idiots in charge of the US military asserting otherwise, the
rules of engagement and the laws of warfare are taken _very_
seriously.
But the military are not the police. Full stop. If someone is
trying to attack a military armory with the intention of seizing
arms, they're not likely to be some petty criminal, but if they
obviously are, they will likely be subdued uninjured. The point
of mentioning that deadly force is authorized when protecting
those kinds of assets is to point out the relative value of the
assets themselves. To whit: weapons are dangerous, and in the
wrong hands, even more dangerous. They can, and should, be
protected.
Btw: as a veteran, one of the things that _really_ bothers me in
the US is when the police, in particular, refer to members of
the general public as "civilians". Words have meaning;
"civilian" refers to someone who is not a member of a military.
The police are are definitionally civilians.
If shots need to be fired, the primary aim should
be to persuade the bad guys to surrender, not to kill them.
Is it better if the enemy surrenders? Sure. But this idea that
you are going to shoot to wound in a combat scenario is not
realistic. As you said, it's not like in the movies.
But more broadly, from a military perspective, this doesn't make
a lot of sense to me, because it ignores the human factors at
play in the fog of war.
Due to the sympathetic physiological reaction to stress, one
tends to lose one's fine motor skills in a combat-type situation
and it can be difficult to remember even the most basic bodily
functions: lose of urinary and sphincter control are common,
for example (hence the expression, "scared shitless"). Moreover
long experience in human history shows that it is impossible to
know a priori how one will react: some people are ridiculously
calm in combat, others are not.
While I have (as I said) no military experience, I have a fair bit of
martial art experience - and what you describe is entirely correct.
Martial arts are art forms, like dance, not combat training.
I really wish people who study them would internalize that. You
get one good punch on the street; you are not experts on actual
warfare, lethal or otherwise. You should take care not to
extrapolate your study of an art form to things you have no
direct experince of.
Or you can listen to someone who's actually done it and who is
telling you that the intent (which yes, is explained to the
troops) is to demonstrate that we take all of this _very_
seriously, that human falibility means that people can and do
make mistakes, and that we build processes and procedures to try
and mitigate or avoid those mistakes.
Long experience has shown that mutual inspections are better
than relying on self-affirmation.
On 16/04/2026 20:15, BGB wrote:
On 4/15/2026 5:44 PM, Bill Findlay wrote:
On 15 Apr 2026, David Brown wrote
(in article <10roqep$16j1j$1@dont-email.me>):
On 15/04/2026 17:36, quadi wrote:That is the bit they really can't fathom.
On Wed, 15 Apr 2026 03:32:00 +0100, moi wrote:
On 15/04/2026 01:44, MitchAlsup wrote:
One should also note: in the history of this system (~late 1930s) >>>>>>> to present: only 2 properly registered FA guns have been used in any >>>>>>> crimes. {Anyone with a brain would say this is a pretty good record} >>>>>Anyone with a non-USAn brain would say this is utterly insane.
Utterly insane would be if the same procedure applied to thermonuclear >>>>> warheads.
Of course, much about the consequences of the Second Amendment
indeed does
appear insane. The sensible thing to do would be to repeal it,
rather than
pretend it doesn't exist, or it doesn't mean what it says, and hope >>>>> the
Supreme Court will look the other way.
[wise words omitted]
That's just my two cents - coming from someone in a country ...
where we have far more real-world freedoms than the USA.
?...
Note - I come from the UK originally, but live in Norway.
But, AFAIK, the UK is the place that went and banned:
Sharp points on knives;
Sharp points on scissors;
Buying solder without having certifications;
So, it is effectively sold black-market in small amounts,
to the electronics hobbyists.
...
Complete nonsense.
But both the UK and Norway have restrictions on people carrying around deadly weapons of all sorts. The freedom not to be stabbed, shot, or otherwise injured or killed trumps the freedom to carry such weapons.
And, where a person can be arrested, for stuff they say on social
media (or "thought crime" as some are calling it);
Only thoughtless people are calling it that. You've been watching tool much Fox News - a channel that describes itself as "entertainment"
without any obligation to tell the truth.
The freedom of innocent people not to suffer abuse, hatred and prejudice trumps the freedom of nasty little sods who think they have the right to abuse others. And inciting hatred or encouraging others to commit
criminal behaviour is just as much a crime in the USA as the UK.
Where corporations can lead search-and-seizure operations for claimed
IP violations;
No, they can't.
And in European countries, unlike the USA, corporations don't get to lie
and cheat then claim "freedom of speech".
We are free to live safely. We have the freedom to send our kids to
school without worrying if they will survive the day. We have the
freedom of knowing that we won't lose our jobs just because the boss is having a bad hair day. And losing a job does not mean losing our
health. And we have freedom to vote, knowing that votes count equally. (Well, the UK parliament elections still have a way to go here, but the Scottish and Norwegian elections have fair votes.)
No country is perfect by any means, but Europeans live far freer lives.
We might not have the freedom to own guns so our kids can accidentally
kill each other, but overall we win out.
Remember, freedoms are always a balance, not an absolute. Lots of types
of freedom for one person reduce other freedoms for other people.
...
So, sorta like California but worse...
California apparently banned the 60/40 lead/tin stuff IIRC, but still
allows people to freely possess lead-free solder (so people apparently
need to smuggle the 60/40 into CA if they want to use it). Everywhere
else, 60/40 is OK. Well, and CA has the "age verification"
controversy, etc.
I can't answer for California, but if I want leaded solder I can just
order some. But the regulations against the use of lead in general are
a good thing - the freedom to drink water without lead trumps the
freedom of a handful of people to use cheaper and lower temperature soldering irons.
Could be wrong, this is from memory and stuff I heard on the internet.
You should be a lot more careful about what you watch on the internet.
On 16/04/2026 20:15, BGB wrote:
And, where a person can be arrested, for stuff they say on social media
(or "thought crime" as some are calling it);
Only thoughtless people are calling it that. You've been watching tool
much Fox News
David Brown <david.brown@hesbynett.no> writes:
On 16/04/2026 20:15, BGB wrote:
And, where a person can be arrested, for stuff they say on social
media (or "thought crime" as some are calling it);
Only thoughtless people are calling it that. You've been watching
tool much Fox News
Or he has been watching too much Youtube (or the like). Every time
somebody tells me that he thinks that something is true that isn't, or
makes a strange judgement, as in this case, and I ask them where they
got that from, they tell me "Youtube".
- anton
On 4/16/2026 5:00 PM, Bill Findlay wrote:
On 16 Apr 2026, BGB wrote
(in article <10rr8vi$1sh0n$1@dont-email.me>):
...
But, AFAIK, the UK is the place that went and banned:
Sharp points on knives;
Sharp points on scissors;
Buying solder without having certifications;
So, it is effectively sold black-market in small amounts,
to the electronics hobbyists.
...
And, where a person can be arrested, for stuff they say on social media (or "thought crime" as some are calling it);
Where corporations can lead search-and-seizure operations for claimed IP violations;
It is clear from that claptrap that in fact you know very little.
(MAGA shills like JD are not a trustworthy source of information.)
I am not really part of the MAGA crowd.
I am not really into politics in general...
But, this is still what people say online about the UK and CA and similar...
On 16/04/2026 20:15, BGB wrote:
On 4/15/2026 5:44 PM, Bill Findlay wrote:
On 15 Apr 2026, David Brown wrote
(in article <10roqep$16j1j$1@dont-email.me>):
On 15/04/2026 17:36, quadi wrote:
On Wed, 15 Apr 2026 03:32:00 +0100, moi wrote:
On 15/04/2026 01:44, MitchAlsup wrote:
One should also note: in the history of this system (~late 1930s) to present: only 2 properly registered FA guns have been used in any
crimes. {Anyone with a brain would say this is a pretty good record}
Anyone with a non-USAn brain would say this is utterly insane.
Utterly insane would be if the same procedure applied to thermonuclear
warheads.
Of course, much about the consequences of the Second Amendment
indeed does
appear insane. The sensible thing to do would be to repeal it,
rather than
pretend it doesn't exist, or it doesn't mean what it says, and hope the
Supreme Court will look the other way.
[wise words omitted]
That's just my two cents - coming from someone in a country ...That is the bit they really can't fathom.
where we have far more real-world freedoms than the USA.
?...
Note - I come from the UK originally, but live in Norway.
But, AFAIK, the UK is the place that went and banned:
Sharp points on knives;
Sharp points on scissors;
Buying solder without having certifications;
So, it is effectively sold black-market in small amounts,
to the electronics hobbyists.
...
Complete nonsense.
But both the UK and Norway have restrictions on people carrying around
deadly weapons of all sorts. The freedom not to be stabbed, shot, or otherwise injured or killed trumps the freedom to carry such weapons.
And, where a person can be arrested, for stuff they say on social media
(or "thought crime" as some are calling it);
Only thoughtless people are calling it that. You've been watching tool
much Fox News - a channel that describes itself as "entertainment"
without any obligation to tell the truth.
The freedom of innocent people not to suffer abuse, hatred and prejudice trumps the freedom of nasty little sods who think they have the right to abuse others. And inciting hatred or encouraging others to commit
criminal behaviour is just as much a crime in the USA as the UK.
Where corporations can lead search-and-seizure operations for claimed IP violations;
No, they can't.
And in European countries, unlike the USA, corporations don't get to lie
and cheat then claim "freedom of speech".
We are free to live safely. We have the freedom to send our kids to
school without worrying if they will survive the day. We have the
freedom of knowing that we won't lose our jobs just because the boss is having a bad hair day. And losing a job does not mean losing our
health. And we have freedom to vote, knowing that votes count equally.
(Well, the UK parliament elections still have a way to go here, but the Scottish and Norwegian elections have fair votes.)
No country is perfect by any means, but Europeans live far freer lives.
We might not have the freedom to own guns so our kids can accidentally
kill each other, but overall we win out.
Remember, freedoms are always a balance, not an absolute. Lots of types
of freedom for one person reduce other freedoms for other people.
...
So, sorta like California but worse...
California apparently banned the 60/40 lead/tin stuff IIRC, but still allows people to freely possess lead-free solder (so people apparently
need to smuggle the 60/40 into CA if they want to use it). Everywhere
else, 60/40 is OK. Well, and CA has the "age verification" controversy, etc.
I can't answer for California, but if I want leaded solder I can just
order some. But the regulations against the use of lead in general are
a good thing - the freedom to drink water without lead trumps the
freedom of a handful of people to use cheaper and lower temperature
soldering irons.
Could be wrong, this is from memory and stuff I heard on the internet.
You should be a lot more careful about what you watch on the internet.
On 4/17/2026 1:05 AM, David Brown wrote:
On 16/04/2026 20:15, BGB wrote:
On 4/15/2026 5:44 PM, Bill Findlay wrote:
On 15 Apr 2026, David Brown wrote
(in article <10roqep$16j1j$1@dont-email.me>):
On 15/04/2026 17:36, quadi wrote:That is the bit they really can't fathom.
On Wed, 15 Apr 2026 03:32:00 +0100, moi wrote:
On 15/04/2026 01:44, MitchAlsup wrote:
One should also note: in the history of this system (~late 1930s) >>>>>>>> to present: only 2 properly registered FA guns have been used in >>>>>>>> any
crimes. {Anyone with a brain would say this is a pretty good
record}
Anyone with a non-USAn brain would say this is utterly insane.
Utterly insane would be if the same procedure applied to
thermonuclear
warheads.
Of course, much about the consequences of the Second Amendment
indeed does
appear insane. The sensible thing to do would be to repeal it,
rather than
pretend it doesn't exist, or it doesn't mean what it says, and
hope the
Supreme Court will look the other way.
[wise words omitted]
That's just my two cents - coming from someone in a country ...
where we have far more real-world freedoms than the USA.
?...
Note - I come from the UK originally, but live in Norway.
But, AFAIK, the UK is the place that went and banned:
Sharp points on knives;
Sharp points on scissors;
Buying solder without having certifications;
So, it is effectively sold black-market in small amounts,
to the electronics hobbyists.
...
Complete nonsense.
But both the UK and Norway have restrictions on people carrying around
deadly weapons of all sorts. The freedom not to be stabbed, shot, or
otherwise injured or killed trumps the freedom to carry such weapons.
Fair enough.
Later went and asked Gemini about it, it said that the laws restrict carrying things with sharp tips (like knives and similar) rather than possession of them (say, at a person's house).
Apparently, the idea that it was a ban on all pointy things was an over- generalization that floats around on the internet.
...
And, where a person can be arrested, for stuff they say on social
media (or "thought crime" as some are calling it);
Only thoughtless people are calling it that. You've been watching
tool much Fox News - a channel that describes itself as
"entertainment" without any obligation to tell the truth.
Actually, mostly, it has been a mix of YouTube videos/shorts and
Twitter/X threads...
The freedom of innocent people not to suffer abuse, hatred and
prejudice trumps the freedom of nasty little sods who think they have
the right to abuse others. And inciting hatred or encouraging others
to commit criminal behaviour is just as much a crime in the USA as the
UK.
OK.
Some people were making it sound like they were opposing peoples'
abilities to have and express opinions in general (though they didn't usually specify on what sorts of topics).
Originally, seemed like, it could have been something like, say:
Person says something bad about a political leader or similar;
Political leader sees it and feels insulted and has person arrested.
Or, something of this sort, ...
But, yeah, in the US people usually say the First Amendment guarantees peoples' freedom to have and express opinions about whatever.
Though, OTOH, I guess things like social media platforms still have the ability to ban people from the platform if they go around spreading hate-speech or similar.
Apparently I guess that was a problem in the past with DJT, then he got banned off of Twitter, then he started his own social network, then Elon bought Twitter and renamed it X, and DJT got back on there, ...
Where corporations can lead search-and-seizure operations for claimed
IP violations;
No, they can't.
And in European countries, unlike the USA, corporations don't get to
lie and cheat then claim "freedom of speech".
Saw a thing not too long ago talking about how apparently Sega left some Nintendo devkits in an old office building, then abandoned the building,
and later the building owners sold off all the old junk that was left in
the buildings.
Story goes that the guy who bought up some of the old junk posted about
it on the internet, and then Sega + Nintendo + UK Police went in and arrested the guy and took all his stuff (then they released the guy, but
he didn't get the stuff back), because the idea was that him having the devkits was considered as theft of intellectual property.
Eg (finding a few videos talking about one of the incidents): https://www.youtube.com/watch?v=Sy9Eb8J0xGk https://www.youtube.com/watch?v=NU040CTdJI0
Remember, freedoms are always a balance, not an absolute. Lots of
types of freedom for one person reduce other freedoms for other people.
OK.
...
So, sorta like California but worse...
California apparently banned the 60/40 lead/tin stuff IIRC, but still
allows people to freely possess lead-free solder (so people
apparently need to smuggle the 60/40 into CA if they want to use it).
Everywhere else, 60/40 is OK. Well, and CA has the "age verification"
controversy, etc.
I can't answer for California, but if I want leaded solder I can just
order some. But the regulations against the use of lead in general
are a good thing - the freedom to drink water without lead trumps the
freedom of a handful of people to use cheaper and lower temperature
soldering irons.
Where I am, solder is sold on Amazon or similar...
Had seen videos where people made it seem like solder was some sort of black-market contraband.
Looking around, apparently the restrictions were specifically on lead-
based solder though, rather than restricting all solder.
In the case of California, did see something not too long ago saying
that they were trying to get something passed to ban personal ownership
of 3D printers and CNC machines.
Though, I didn't see anyone else talking about this, so it seemed unconfirmed.
There is a lot more talking going on about the CA "OS age verification" bull, and now something saying that the US federal people are now
looking into something similar (groan, this has a risk to potentially
ruin open source and make everything suck...). Hopefully it goes the way
of past proposals for bans on OSS and RISC-V and similar, ...
So, not like US is exactly perfect either...
Could be wrong, this is from memory and stuff I heard on the internet.
You should be a lot more careful about what you watch on the internet.
Possibly.
Then again, I guess a lot of the news I had seen had also been fed
through the lens of video game commentators and similar.
On Fri, 17 Apr 2026 08:51:12 GMT
anton@mips.complang.tuwien.ac.at (Anton Ertl) wrote:
David Brown <david.brown@hesbynett.no> writes:
On 16/04/2026 20:15, BGB wrote:
And, where a person can be arrested, for stuff they say on social
media (or "thought crime" as some are calling it);
Only thoughtless people are calling it that. You've been watching
tool much Fox News
Or he has been watching too much Youtube (or the like). Every time
somebody tells me that he thinks that something is true that isn't, or
makes a strange judgement, as in this case, and I ask them where they
got that from, they tell me "Youtube".
Pay attention that David Brown didn't say that things mentioned by BGB
don't actually happen in UK. He was merely disagreeinng with Orwellian naming.
On 17 Apr 2026, David Brown wrote
(in article <10rsik4$287kv$1@dont-email.me>):
On 16/04/2026 20:15, BGB wrote:
Could be wrong, this is from memory and stuff I heard on the internet.
You should be a lot more careful about what you watch on the internet.
Bravo! You put a lot more work into that than I could
stomach in response to Fuck News talking points.
Thank you.
On 17/04/2026 09:20, BGB wrote:Norway did not use to have any restrictions at all on tools, like knives/axes/scythes up to and including shotguns.
On 4/17/2026 1:05 AM, David Brown wrote:
Complete nonsense.
But both the UK and Norway have restrictions on people carrying
around deadly weapons of all sorts. The freedom not to be stabbed,
shot, or otherwise injured or killed trumps the freedom to carry such
weapons.
Fair enough.
Later went and asked Gemini about it, it said that the laws restrict
carrying things with sharp tips (like knives and similar) rather than >> possession of them (say, at a person's house).
I don't think any LLM is going to be a good source of information here. Gemini might not be as bad as Grok, but AI will often miss the point,
and be heavily influenced by the kinds of drivel that is often published
on the net.
Basically, the laws say that if you are caught with a large screwdriver
that you are using to stab or threaten people, you will be charged and > treated as though you were carrying a knife for that purpose. Older
laws banned carrying knifes and the like in public places - newer laws > target weapons, where a "weapon" is anything that you use or plan to use
for violence or threats of violence.
David Brown wrote:
On 17/04/2026 09:20, BGB wrote:
On 4/17/2026 1:05 AM, David Brown wrote:
Complete nonsense.
But both the UK and Norway have restrictions on people carrying
around deadly weapons of all sorts. The freedom not to be stabbed, >>>> shot, or otherwise injured or killed trumps the freedom to carry
such weapons.
Fair enough.
Later went and asked Gemini about it, it said that the laws restrict
carrying things with sharp tips (like knives and similar) rather than
possession of them (say, at a person's house).
I don't think any LLM is going to be a good source of information
here. Gemini might not be as bad as Grok, but AI will often miss the
point, and be heavily influenced by the kinds of drivel that is often
published on the net.
Basically, the laws say that if you are caught with a large
screwdriver that you are using to stab or threaten people, you will be
charged and treated as though you were carrying a knife for that
purpose. Older laws banned carrying knifes and the like in public
places - newer laws target weapons, where a "weapon" is anything that
you use or plan to use for violence or threats of violence.
Norway did not use to have any restrictions at all on tools, like knives/axes/scythes up to and including shotguns.
The current regulations have explicit exceptions for knife carry in
public plaes when those knives (or swords!) are part of uniform or traditional dress. I.e around May 17th it is perfectly fine to carry
large amounts of metal (mostly silver) through airport security, but
they might tell you that the silver-decorated knife should go in checked luggage.
Similarly, Scouts' knives are fine anywhere.
Regarding firearms the Norwegian regulations are still way less strict
than the UK, pretty much anyone without a mental illness or felony
record can legally own a handgun:
You just need to start by becoming a member of a local pistol shooting
club, then turn up regularly to practice using club guns (at least 10
times or more) over a year, then pass a police security vetting which
check for those mental/felony bans.
At this point you can legally buy something like a Glock or 1911 and get
the serial number on your credit-card sized ownership card.
If you are very active, then you can get separate permits for a primary
and spare gun for each of the competition classes you regularly compete
in, I know people with 10+ handguns in their gun safe.
However, unlike the US, there is absolutely no way to get either an open
or concealed carry permit unless you are military or police.
Any handgun you own _must_ be stored in a proper gun safe, in can only
be brought out for cleaning and to transport it to the shooting range.
During that transport, the gun cannot be in the front seat with you, it
has to stay in the trunk or back seat, unloaded of course, and still in
its carrying box.
On 17/04/2026 16:07, Terje Mathisen wrote:Its worse as far as I know:
David Brown wrote:
On 17/04/2026 09:20, BGB wrote:
On 4/17/2026 1:05 AM, David Brown wrote:
Complete nonsense.
But both the UK and Norway have restrictions on people carrying
around deadly weapons of all sorts. The freedom not to be
stabbed, shot, or otherwise injured or killed trumps the freedom to >>>>> carry such weapons.
Fair enough.
Later went and asked Gemini about it, it said that the laws restrict
carrying things with sharp tips (like knives and similar) rather
than possession of them (say, at a person's house).
I don't think any LLM is going to be a good source of information
here. Gemini might not be as bad as Grok, but AI will often miss the >>> point, and be heavily influenced by the kinds of drivel that is often
published on the net.
Basically, the laws say that if you are caught with a large
screwdriver that you are using to stab or threaten people, you will
be charged and treated as though you were carrying a knife for that
purpose. Older laws banned carrying knifes and the like in public
places - newer laws target weapons, where a "weapon" is anything that
you use or plan to use for violence or threats of violence.
Norway did not use to have any restrictions at all on tools, like
knives/axes/scythes up to and including shotguns.
The current regulations have explicit exceptions for knife carry in
public plaes when those knives (or swords!) are part of uniform or
traditional dress. I.e around May 17th it is perfectly fine to carry
large amounts of metal (mostly silver) through airport security, but
they might tell you that the silver-decorated knife should go in
checked luggage.
I were my sgian-dubh with my kilt. Despite the name, it's not very hidden. It used to be legal to have one in the cabin of planes in the
UK, as long as it stayed in your sock.
Similarly, Scouts' knives are fine anywhere.
Regarding firearms the Norwegian regulations are still way less strict
than the UK, pretty much anyone without a mental illness or felony
record can legally own a handgun:
You just need to start by becoming a member of a local pistol shooting
club, then turn up regularly to practice using club guns (at least 10 >> times or more) over a year, then pass a police security vetting which >> check for those mental/felony bans.
At this point you can legally buy something like a Glock or 1911 and
get the serial number on your credit-card sized ownership card.
If you are very active, then you can get separate permits for a
primary and spare gun for each of the competition classes you
regularly compete in, I know people with 10+ handguns in their gun safe.
However, unlike the US, there is absolutely no way to get either an
open or concealed carry permit unless you are military or police.
Indeed. And you have to keep them locked in a gun safe, which the
police can check at short notice.
Similarly, you can own a hunting rifle if you pass the hunting tests and
are vetted by the police.
Any handgun you own _must_ be stored in a proper gun safe, in can only
be brought out for cleaning and to transport it to the shooting range.>>
During that transport, the gun cannot be in the front seat with you,
it has to stay in the trunk or back seat, unloaded of course, and
still in its carrying box.
Basically, in Norway you can have guns for sport or hunting, but not for threatening or shooting people.
The gun laws in the UK are a lot more restrictive (after all, there's
not nearly as much scope for hunting in most of the UK). Farmers can
get shotgun licenses, but I think if you have a pistol for sport it has
to be kept at the pistol club, not at home. (I have not looked at the rules in detail, so I could be wrong or out-dated.)
On 16/04/2026 20:15, BGB wrote:
On 4/15/2026 5:44 PM, Bill Findlay wrote:
California apparently banned the 60/40 lead/tin stuff IIRC, but still
allows people to freely possess lead-free solder (so people apparently
need to smuggle the 60/40 into CA if they want to use it). Everywhere
else, 60/40 is OK. Well, and CA has the "age verification" controversy,
etc.
I can't answer for California,
On 4/16/2026 5:13 PM, Scott Lurndal wrote:
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:
On 4/16/2026 11:52 AM, Scott Lurndal wrote:
Brain fart. His squadron flys the F/A-18C and D models. The
E's and F's will remain in the active fleet along with the F-35,
Can he fly the F-35?
Only if he gets a ride in the back seat. Which, since the F35
is a single seater, is not gonna happen.
Oh damn! Shit. He can fly the f-16?
On 17/04/2026 14:11, Bill Findlay wrote:
On 17 Apr 2026, David Brown wrote
(in article <10rsik4$287kv$1@dont-email.me>):
On 16/04/2026 20:15, BGB wrote:
Could be wrong, this is from memory and stuff I heard on the internet.
You should be a lot more careful about what you watch on the internet.
Bravo! You put a lot more work into that than I could
stomach in response to Fuck News talking points.
Thank you.
I've "known" BGB for many years on Usenet. He is very intelligent, but sometimes a bit too quick to trust the wrong sources. I hope I can encourage him to be more careful about what to trust and what not to trust. (And that includes not believing things just because /I/ say so either - I can be wrong too.)
Fun fact - I heard about the "ground.news" site I mentioned because they sponsored some Youtube videos I have watched :-)
On 17 Apr 2026, BGB wrote
(in article <10rrsqc$22m9c$1@dont-email.me>):
On 4/16/2026 5:00 PM, Bill Findlay wrote:
On 16 Apr 2026, BGB wrote
(in article <10rr8vi$1sh0n$1@dont-email.me>):
...
But, AFAIK, the UK is the place that went and banned:
Sharp points on knives;
Sharp points on scissors;
Buying solder without having certifications;
So, it is effectively sold black-market in small amounts,
to the electronics hobbyists.
...
And, where a person can be arrested, for stuff they say on social media >>>> (or "thought crime" as some are calling it);
Where corporations can lead search-and-seizure operations for claimed IP >>>> violations;
It is clear from that claptrap that in fact you know very little.
(MAGA shills like JD are not a trustworthy source of information.)
I am not really part of the MAGA crowd.
I am not really into politics in general...
But, this is still what people say online about the UK and CA and similar...
So, myevaluation of your words was spot on.
This led me to feel I had the perfect spot in which to re-introduce to
this iteration of the Concertina II architecture that most bizarre
feature of the architecture which was cited as one of its defining features... I think of it as an exotic and strictly optional feature, existing mainly to enhance emulation, while the ability to go from RISC
to CISC to VLIW is what defines Concertina II.
But let's get back to gate delays, please.
John Levine <johnl@taugh.com> schrieb:
But let's get back to gate delays, please.
Let's.
How do people actually count gate delays, and how useful is it?
Different gates have different delays (obviously), so counting
an inverter the same as a three-input NOR gate (independent of
fan-out, even) seems to be a large simplification which may be
useful for a fairly rough approximation, but not that much better.
Or am I missing something?
On 4/17/2026 8:01 AM, David Brown wrote:
On 17/04/2026 14:11, Bill Findlay wrote:
On 17 Apr 2026, David Brown wrote
(in article <10rsik4$287kv$1@dont-email.me>):
On 16/04/2026 20:15, BGB wrote:
Could be wrong, this is from memory and stuff I heard on the internet. >>>>You should be a lot more careful about what you watch on the internet.
Bravo! You put a lot more work into that than I could
stomach in response to Fuck News talking points.
Thank you.
I've "known" BGB for many years on Usenet. He is very intelligent,
but sometimes a bit too quick to trust the wrong sources. I hope I
can encourage him to be more careful about what to trust and what not
to trust. (And that includes not believing things just because /I/
say so either - I can be wrong too.)
Fun fact - I heard about the "ground.news" site I mentioned because
they sponsored some Youtube videos I have watched :-)
Not usually been one for fact checking, as my interest areas are still (mostly) technical (rather than political or legal), so whatever
political leaning I would have mostly shouldn't matter.
But, yeah, sometimes it gets a little sketchy if it is just someone
rambling on top of gameplay footage, like Subway Surfers, or similar.
Back in the day, we had Audiosurf, but seems that Subway Surfers has overtaken this role.
Some people have also used games like COD or Minecraft, but watching
someone play these games from a first person POV for any length of time causes motion sickness.
At one point, people doing videos with talking over the top of clips of Skibidi Toilet was pretty popular (during the high point of Skibidi
Toilet, but its popularity seems to have weakened as of late).
The video of the guy ranting about CA taking away personal ownership of
3D printers and CNC machines was over the top of video of him working on
one of his craft projects. Usually though, for stuff like this, there
would be repetition from multiple sources (in a case of "one guy saying something, possibly all just nothing, many people saying the same thing, possibly true" sense).
Sometimes there is a lot of stuff with people fighting over "Evolution
vs Young Earth Creationism" and similar. Sometimes people arguing for
the Earth being a flat disk (obviously wrong), ...
All sorts of stuff going on...
Sometimes does wander into international politics territory.
Sort of reminded how for a while there were lots of YouTube sponsored segments for a company claiming to sell Lordship status...
Then other people saying it was a scam, because that was "not how it worked". IIRC idea was that they bought a farm somewhere and were
"selling" it in 1ft^2 parcels or similar, planting a little flag on each one, and then selling the people the title of "Lord Whatever" under the premise of them having their flag planted on a parcel of land in the UK
or such...
Had to look, couldn't initially remember name off-hand: https://en.wikipedia.org/wiki/Established_Titles
Then the whole thing went away.
Apparently a combination of public controversy and also the UK
government apparently also being like "that is not how that works".
...
Sort of reminded how for a while there were lots of YouTube sponsored segments for a company claiming to sell Lordship status...
Then other people saying it was a scam, because that was "not how it worked". IIRC idea was that they bought a farm somewhere and were
"selling" it in 1ft^2 parcels or similar, planting a little flag on each one, and then selling the people the title of "Lord Whatever" under the premise of them having their flag planted on a parcel of land in the UK
or such...
Had to look, couldn't initially remember name off-hand: https://en.wikipedia.org/wiki/Established_Titles
Then the whole thing went away.
Apparently a combination of public controversy and also the UK
government apparently also being like "that is not how that works".
BGB wrote:
Sort of reminded how for a while there were lots of YouTube sponsored
segments for a company claiming to sell Lordship status...
Then other people saying it was a scam, because that was "not how it
worked". IIRC idea was that they bought a farm somewhere and were
"selling" it in 1ft^2 parcels or similar, planting a little flag on
each one, and then selling the people the title of "Lord Whatever"
under the premise of them having their flag planted on a parcel of
land in the UK or such...
Had to look, couldn't initially remember name off-hand:
https://en.wikipedia.org/wiki/Established_Titles
Then the whole thing went away.
Apparently a combination of public controversy and also the UK
government apparently also being like "that is not how that works".
Something similar to this actually happened, in Norway:
At one point, after establishing that all men could vote, it was
understood that this of course only meant men with a tie to the land,
i.e farmers, millers, blacksmiths, industialists etc.
In reaction, a group working to make voting rights really universal
bought up large tracts of worthless swamp/marshland and split it into
square foot parcels. Armed with a owership certificate for said plot,
you could not be denied your voting rights.
I've also seen this done in the UK as a way to protect land from
developers. A forest (or whatever land is to be protected) is bought
then parcelled up and sold to thousands of people. If someone wants to destroy the forest to build houses, factories, or whatever, they need to find all these owners and buy from each of them individually.
| Sysop: | DaiTengu |
|---|---|
| Location: | Appleton, WI |
| Users: | 1,113 |
| Nodes: | 10 (0 / 10) |
| Uptime: | 492337:11:34 |
| Calls: | 14,238 |
| Files: | 186,312 |
| D/L today: |
3,909 files (1,274M bytes) |
| Messages: | 2,514,893 |