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:
-a Sharp points on knives;
-a Sharp points on scissors;
-a Buying solder without having certifications;
-a-a-a So, it is effectively sold black-market in small amounts,
-a-a-a-a-a 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:
-a Sharp points on knives;
-a Sharp points on scissors;
-a Buying solder without having certifications;
-a-a-a So, it is effectively sold black-market in small amounts,
-a-a-a-a-a to the electronics hobbyists.
-a ...
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:
-a-a Sharp points on knives;
-a-a Sharp points on scissors;
-a-a Buying solder without having certifications;
-a-a-a-a So, it is effectively sold black-market in small amounts,
-a-a-a-a-a-a to the electronics hobbyists.
-a-a ...
Complete nonsense.
But both the UK and Norway have restrictions on people carrying around deadly weapons of all sorts.-a 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.-a 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.-a 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.-a We have the freedom to send our kids to
school without worrying if they will survive the day.-a We have the
freedom of knowing that we won't lose our jobs just because the boss is having a bad hair day.-a And losing a job does not mean losing our
health.-a 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.-a 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.-a 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:
-a-a Sharp points on knives;
-a-a Sharp points on scissors;
-a-a Buying solder without having certifications;
-a-a-a-a So, it is effectively sold black-market in small amounts,
-a-a-a-a-a-a to the electronics hobbyists.
-a-a ...
Complete nonsense.
But both the UK and Norway have restrictions on people carrying around
deadly weapons of all sorts.-a 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.-a 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.-a 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:
-a Person says something bad about a political leader or similar;
-a 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.-a 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.-a 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.|e-a 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.-a 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.|e-a 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.-a 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.|arCU|e-a 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.|e-a 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.-a Despite the name, it's not very hidden.-a 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.-a 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).-a 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.-a (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.-a He is very intelligent, but sometimes a bit too quick to trust the wrong sources.-a I hope I can encourage him to be more careful about what to trust and what not to trust.-a (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.-a He is very intelligent,
but sometimes a bit too quick to trust the wrong sources.-a I hope I
can encourage him to be more careful about what to trust and what not
to trust.-a (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.
David Brown <david.brown@hesbynett.no> schrieb:
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.
You can also buy a square foot of land to get a (worthless, but
amusing) title, for example as "Laird" in Scotland.
Thomas Koenig <tkoenig@netcologne.de> posted:
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?
There is the "standard" FO4 counting scheme where 1 gate drives
4 other gate inputs, and in this scheme, a D-type flip-flop was
2.5 gates of delay.
As one can guess, gates can be sized: as small as obeys the FAB
design rules, to <basically> as big as one can afford. Naturally,
as gates get bigger, they can drive bigger loads--BUT they also
present bigger loads to the gates driving them.
Conway figured out that the fastest way to "buffer up" a signal
was to use inverters staged in the ratio of 1:e:e^2:e^3... with
e being the standard 2.7... base of natural logarithms. Rounding
e up to 3 degrades speed by less than 1%, rounding up to 4 only
slows down 10% or so--so, most buffering is done at FO4, where
a minimum sized gate drives an inverter 4|u as big which would then
drive another inverter 16|u as big...
Each transistor between a power connection and the signal connec-
tion basically, adds its own transconductance to the electrical path (ignoring body effect). Knowing that deMorgan's laws apply; we
instantly see that a Nand gate is simply a Nor gate with inverted
inputs. A Nand gate has its serial string of FETs between signal
and ground and a parralel path from signal to Vdd, while a Nor has
its serial FETs between signal and Vdd and its parallel path between
signal and ground. To deal with these serial paths, the transistors
are lengthened; a 2Nand has N-channels 2|u as wide and can use 1|u
P channels, a 3Nand has 3|u N-channels and still 1|u P-channels, ...
{Nors are similar but reverse Ns and Ps} Somewhere along the line,
the parallel path FETs have to get lengthened because the capacitance
of all the serial path diffusion capacitance (to maintain rather
equal pull up and pull down).
Soon, one realizes that one needs SPICE simulation with accurate
models to push the edge--just like when pushing the Young's Modulus
in engineering models.
In fast designs, there is an entire team charged with buffering and
routing the CLOCK so that every gate in 10^2 mm^2 receives its rising
edge and falling edge with less than 1 gate of delay 'skew' across
the whole chip using wires that have more than 1 gate of delay when
jumping over 30 gates. CRAY-1 had less than 1ns of clock skew in a
machine the size of restaurant refrigerator using wires with 2ns/foot
of delay. In ASIC designs, we assume (starting out) that there will
be 1/2 clock of skew in the 'clock'
On 2026-Apr-17 21:11, MitchAlsup wrote:
Thomas Koenig <tkoenig@netcologne.de> posted:
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?
There is the "standard" FO4 counting scheme where 1 gate drives
4 other gate inputs, and in this scheme, a D-type flip-flop was
2.5 gates of delay.
As one can guess, gates can be sized: as small as obeys the FAB
design rules, to <basically> as big as one can afford. Naturally,
as gates get bigger, they can drive bigger loads--BUT they also
present bigger loads to the gates driving them.
Conway figured out that the fastest way to "buffer up" a signal
was to use inverters staged in the ratio of 1:e:e^2:e^3... with
e being the standard 2.7... base of natural logarithms. Rounding
e up to 3 degrades speed by less than 1%, rounding up to 4 only
slows down 10% or so--so, most buffering is done at FO4, where
a minimum sized gate drives an inverter 4|u as big which would then
drive another inverter 16|u as big...
Each transistor between a power connection and the signal connec-
tion basically, adds its own transconductance to the electrical path (ignoring body effect). Knowing that deMorgan's laws apply; we
instantly see that a Nand gate is simply a Nor gate with inverted
inputs. A Nand gate has its serial string of FETs between signal
and ground and a parralel path from signal to Vdd, while a Nor has
its serial FETs between signal and Vdd and its parallel path between
signal and ground. To deal with these serial paths, the transistors
are lengthened; a 2Nand has N-channels 2|u as wide and can use 1|u
P channels, a 3Nand has 3|u N-channels and still 1|u P-channels, ...
{Nors are similar but reverse Ns and Ps} Somewhere along the line,
the parallel path FETs have to get lengthened because the capacitance
of all the serial path diffusion capacitance (to maintain rather
equal pull up and pull down).
Soon, one realizes that one needs SPICE simulation with accurate
models to push the edge--just like when pushing the Young's Modulus
in engineering models.
In fast designs, there is an entire team charged with buffering and
routing the CLOCK so that every gate in 10^2 mm^2 receives its rising
edge and falling edge with less than 1 gate of delay 'skew' across
the whole chip using wires that have more than 1 gate of delay when
jumping over 30 gates. CRAY-1 had less than 1ns of clock skew in a
machine the size of restaurant refrigerator using wires with 2ns/foot
of delay. In ASIC designs, we assume (starting out) that there will
be 1/2 clock of skew in the 'clock'
The part I don't see is the rules for combinatorial gates.
There also seem to be combinatorial gates like XOR or AND-OR-INV or MUX
where multiple gates are combined in one but at a lower gate delay.
For example, in TTL an XOR or a 2:1 or 4:1 mux has 3 or 4 gate delays
because it really is an INV, an AND and a OR,
but in CMOS those seem to be just 1 or 1.5 gate delays.
In CMOS sometimes one is able to smoosh gates together and eliminate
gate delays, but the rules for when smooshing is allowed are not
obvious to me. I just assumed that it all sorts out in SPICE simulation.
I find this makes it more difficult to just look at a CMOS logic circuit
and know whether it will fit within a 20 gate delay stage budget.
In fast designs, there is an entire team charged with buffering and
routing the CLOCK so that every gate in 10^2 mm^2 receives its rising
edge and falling edge with less than 1 gate of delay 'skew' across
the whole chip using wires that have more than 1 gate of delay when
jumping over 30 gates. CRAY-1 had less than 1ns of clock skew in a
machine the size of restaurant refrigerator using wires with 2ns/foot
of delay. In ASIC designs, we assume (starting out) that there will
be 1/2 clock of skew in the 'clock'
The part I don't see is the rules for combinatorial gates.
There also seem to be combinatorial gates like XOR or AND-OR-INV or MUX
where multiple gates are combined in one but at a lower gate delay.
For example, in TTL an XOR or a 2:1 or 4:1 mux has 3 or 4 gate delays
because it really is an INV, an AND and a OR,
but in CMOS those seem to be just 1 or 1.5 gate delays.
In CMOS sometimes one is able to smoosh gates together and eliminate
gate delays, but the rules for when smooshing is allowed are not
obvious to me. I just assumed that it all sorts out in SPICE simulation.
I find this makes it more difficult to just look at a CMOS logic circuit
and know whether it will fit within a 20 gate delay stage budget.
On 17/04/2026 19:37, BGB wrote:
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:
Bravo! You put a lot more work into that than I couldCould 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. >>>>
stomach in response to Fuck News talking points.
Thank you.
I've "known" BGB for many years on Usenet.-a He is very intelligent,
but sometimes a bit too quick to trust the wrong sources.-a I hope I
can encourage him to be more careful about what to trust and what not
to trust.-a (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.
Fact checking is also important in technical fields!
But while you might not be particularly interested in politics, politics
and other aspects of societies and countries around the world still
affect you.-a It is still good to have some rough ideas about what is
going on in the world - and how to tell if something is true or not (or
at least likely to be true or not).
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).
One particular politician is famous for prefacing many of his boldest
and most absurd lies with "many people are saying...".-a Many people can
say the same thing, and still be wrong.-a (Just look at religion around
the world.-a Many people say one thing.-a Many people say something
totally different.-a They can't all be right - many people are wrong.)
"Proof by repeated assertion" is not a valid argument, whether it is one person saying something many times, or many people saying the same thing.
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), ...
I'm glad that you at least consider "flat Earth" to be obviously wrong.
The same applies to any kind of "young earth" idea.
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...
It is possible to argue that believing the nonsense you have heard about
is harmless - though I would say making yourself look foolish can be considered "harm".-a But scams con people out of real money.-a Fair enough if it is a small amount of money, and clearly nonsense, bought as a joke
- like buying insurance against alien kidnapping.-a Please be careful
about any kinds of scams you come across.
On 4/18/2026 3:56 AM, David Brown wrote:-----------------------
"Proof by repeated assertion" is not a valid argument, whether it is one person saying something many times, or many people saying the same thing.
Possibly...
But, OTOH, if one person is saying something any no one else is saying
it, there is a higher probability that that person had pulled something
out of thin air.
some things don't hold up:deNorms are not needed in well written FP arithmetic
Flat Earth:
Pretty much all of the evidence is against it;
Young Earth Creationism:
Hard to reconcile with geology and physics;
Depends on a particular interpretation of Genesis,
but, easier to assert that this is not the correct interpretation.
A lot of the "alien Conspiracy" stuff:
Would require implausible levels of coordination to hide,
if their claims were true;
Has similar logical problems as "Flat Earth" and similar.
A lot of the stories about various "cryptids"/etc:
Alas, if bigfoot/yeti/etc were around,
there would likely be more confirmed physical evidence.
BGB <cr88192@gmail.com> posted:
On 4/18/2026 3:56 AM, David Brown wrote:-----------------------
"Proof by repeated assertion" is not a valid argument, whether it
is one person saying something many times, or many people saying
the same thing.
Possibly...
But, OTOH, if one person is saying something any no one else is
saying it, there is a higher probability that that person had
pulled something out of thin air.
This coming from the one person here who does not subscribe to the
minutia of IEEE 754 while accepting the formats and arithmetic defini-
tions.
cross@spitfire.i.gajendra.net (Dan Cross) writes:
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.
His eventual goal is to get his A&P. Figures helos will be good
experience.
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).
I just looked on google maps and they've pretty much censored
the entire base in both the map and satellite views.
On 16/04/2026 18:31, Dan Cross wrote:
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.
I don't know the details of the regulations, but I can assure you that
it is entirely within them. As a student, his flat is considered
temporary accommodation and our house is his permanent home. His
National Guard base is in our area, not where he is a student.
Maybe the regulations in the USA are different. Maybe there are
different standards about how quickly you can be called up and need to >deploy.
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.
Sorry - I meant pistols, rather than rifle-sized weapons. (Of course >pistols are also used in the military.)
[snip]
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.
It's nice to know - especially with the current muppets at the top of
the USA chain.
[snip]
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.
I think that there has been a bit of a disparity in the situations we
have been imagining. I agree entirely that shooting to wound in a
combat situation is not realistic. It just seemed to me that you were >suggesting armoury guards were moving to combat mode a lot more quickly
than I thought appropriate.
[snip]
Just to be clear here - mutual inspections are fine and often a good
thing. It is the idea of standing in line while a commander of some
sort pats you down that is not. Maybe I just misunderstood what you
were saying.
On Sat, 18 Apr 2026 21:02:58 GMT
MitchAlsup <user5857@newsgrouper.org.invalid> wrote:
BGB <cr88192@gmail.com> posted:
On 4/18/2026 3:56 AM, David Brown wrote:-----------------------
"Proof by repeated assertion" is not a valid argument, whether it
is one person saying something many times, or many people saying
the same thing.
Possibly...
But, OTOH, if one person is saying something any no one else is
saying it, there is a higher probability that that person had
pulled something out of thin air.
This coming from the one person here who does not subscribe to the
minutia of IEEE 754 while accepting the formats and arithmetic defini-
tions.
I don't know what exactly do you mean by "subscribe" and "minutia", but
if you mean what I am guessing you mean then my own position is pretty
close to that.
More precisely, I think IEEE 754 formats and definitions of basic ops
are mostly great, with exception of omission of very useful rsqrt
primitive.
I think that 90% of IEEE 754 exception are useless crap and in one or
two places it's worse than that.
I think that effort-to-reward ratio of non-default rounding modes is
pretty low and the choice of mandatory non-default modes is sub-optimal.
I think that common practice of FP control and FP status shared
across different supported precisions is wrong. Although, in this case
it's more a fault of language bindings of 754 rather than of 754 itself.
But 754 leaves the issue underspecified which is also no good.
So, if BGB shares my view then there are already two of us.
According to quadi <quadibloc@ca.invalid>:
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.
The evidence is that for over 150 years, everyone agreed that it meant
state militias. There were two Supreme Court decisions in 1876 and
1886 that confirmed the rights of states to regulate militias, one in
1939 saying that a sawed off shotgun wasn't the kind of arm that the
2nd was intended to protect, and one in 1980 confirming that it was OK
for states to forbid convicted felons from owning guns.
I'm not aware of anyone claiming it was an individual right that the
states could not regulate until the 1960 revisionists, and no court
decision until Heller in 2008 which reversed the previous century and
a half's precedent. Heller was decided 5-4, over strong dissents.
On Sat, 18 Apr 2026 21:02:58 GMT
MitchAlsup <user5857@newsgrouper.org.invalid> wrote:
BGB <cr88192@gmail.com> posted:
On 4/18/2026 3:56 AM, David Brown wrote:-----------------------
"Proof by repeated assertion" is not a valid argument, whether it
is one person saying something many times, or many people saying
the same thing.
Possibly...
But, OTOH, if one person is saying something any no one else is
saying it, there is a higher probability that that person had
pulled something out of thin air.
This coming from the one person here who does not subscribe to the
minutia of IEEE 754 while accepting the formats and arithmetic defini-
tions.
I don't know what exactly do you mean by "subscribe" and "minutia", but
if you mean what I am guessing you mean then my own position is pretty
close to that.
More precisely, I think IEEE 754 formats and definitions of basic ops
are mostly great, with exception of omission of very useful rsqrt
primitive.
I think that 90% of IEEE 754 exception are useless crap and in one or
two places it's worse than that.
I think that effort-to-reward ratio of non-default rounding modes is
pretty low and the choice of mandatory non-default modes is sub-optimal.
I think that common practice of FP control and FP status shared
across different supported precisions is wrong. Although, in this case
it's more a fault of language bindings of 754 rather than of 754 itself.
But 754 leaves the issue underspecified which is also no good.
So, if BGB shares my view then there are already two of us.
Did see someone on the RISC-V sig-fp mailing also favoring DAZ/FTZ
and similar for floating point.
So, it isn't exactly unheard of...
Some of your comments, such as repeatedly asserting the
ridiculous notion that people are "bribing" armorers so they can
avoid "doing their jobs" lead me to wonder whether you are
deliberately misrepresenting what I am saying so that you can
feel yourself morally superior to an American.
I have, I think, been patient with my responses, but in the this
and my previous message, my patience is slipping.
On 19/04/2026 03:02, Dan Cross wrote:
[snip]
I have, I think, been patient with my responses, but in the this
and my previous message, my patience is slipping.
It is best to close of this thread branch. [...]
In article <10rsktu$287kv$2@dont-email.me>,
David Brown <david.brown@hesbynett.no> wrote:
I don't know the details of the regulations, but I can assure you that
it is entirely within them. As a student, his flat is considered
temporary accommodation and our house is his permanent home. His
National Guard base is in our area, not where he is a student.
Maybe the regulations in the USA are different. Maybe there are
different standards about how quickly you can be called up and need to
deploy.
Misrepresenting your home address, such as using your parents'
home when you don't actually live there, temporary accommodation
or not, is not something the US military looks upon favorably.
John Levine <johnl@taugh.com> writes:
According to quadi <quadibloc@ca.invalid>:
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.
The evidence is that for over 150 years, everyone agreed that it meant state militias. There were two Supreme Court decisions in 1876 and
1886 that confirmed the rights of states to regulate militias, one in
1939 saying that a sawed off shotgun wasn't the kind of arm that the
2nd was intended to protect, and one in 1980 confirming that it was OK
for states to forbid convicted felons from owning guns.
I'm not aware of anyone claiming it was an individual right that the
states could not regulate until the 1960 revisionists, and no court decision until Heller in 2008 which reversed the previous century and
a half's precedent. Heller was decided 5-4, over strong dissents.
Has anyone seen comp.arch around here somewhere? I seem to have
wandered into rec.guns.
EricP <ThatWouldBeTelling@thevillage.com> posted:
On 2026-Apr-17 21:11, MitchAlsup wrote:
Thomas Koenig <tkoenig@netcologne.de> posted:
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?
There is the "standard" FO4 counting scheme where 1 gate drives
4 other gate inputs, and in this scheme, a D-type flip-flop was
2.5 gates of delay.
As one can guess, gates can be sized: as small as obeys the FAB
design rules, to <basically> as big as one can afford. Naturally,
as gates get bigger, they can drive bigger loads--BUT they also
present bigger loads to the gates driving them.
Conway figured out that the fastest way to "buffer up" a signal
was to use inverters staged in the ratio of 1:e:e^2:e^3... with
e being the standard 2.7... base of natural logarithms. Rounding
e up to 3 degrades speed by less than 1%, rounding up to 4 only
slows down 10% or so--so, most buffering is done at FO4, where
a minimum sized gate drives an inverter 4|u as big which would then
drive another inverter 16|u as big...
Each transistor between a power connection and the signal connec-
tion basically, adds its own transconductance to the electrical path
(ignoring body effect). Knowing that deMorgan's laws apply; we
instantly see that a Nand gate is simply a Nor gate with inverted
inputs. A Nand gate has its serial string of FETs between signal
and ground and a parralel path from signal to Vdd, while a Nor has
its serial FETs between signal and Vdd and its parallel path between
signal and ground. To deal with these serial paths, the transistors
are lengthened; a 2Nand has N-channels 2|u as wide and can use 1|u
P channels, a 3Nand has 3|u N-channels and still 1|u P-channels, ...
{Nors are similar but reverse Ns and Ps} Somewhere along the line,
the parallel path FETs have to get lengthened because the capacitance
of all the serial path diffusion capacitance (to maintain rather
equal pull up and pull down).
Soon, one realizes that one needs SPICE simulation with accurate
models to push the edge--just like when pushing the Young's Modulus
in engineering models.
In fast designs, there is an entire team charged with buffering and
routing the CLOCK so that every gate in 10^2 mm^2 receives its rising
edge and falling edge with less than 1 gate of delay 'skew' across
the whole chip using wires that have more than 1 gate of delay when
jumping over 30 gates. CRAY-1 had less than 1ns of clock skew in a
machine the size of restaurant refrigerator using wires with 2ns/foot
of delay. In ASIC designs, we assume (starting out) that there will
be 1/2 clock of skew in the 'clock'
The part I don't see is the rules for combinatorial gates.
There also seem to be combinatorial gates like XOR or AND-OR-INV or MUX
where multiple gates are combined in one but at a lower gate delay.
For example, in TTL an XOR or a 2:1 or 4:1 mux has 3 or 4 gate delays
because it really is an INV, an AND and a OR,
but in CMOS those seem to be just 1 or 1.5 gate delays.
A 4:1 Mux is a 2222AOI gate--one Ssllooww gate--but still 1 gate.
One slow gate is generally faster than 2 gates (and less power)
because only 1 signal has to move (Vdd->gnd or gnd->Vdd) instead
of more than one. Each signal moving is limited by the transcon-
ductance of the FET stack and the capacitance being driven. We
call the rise/fall time the edge speed.
In CMOS sometimes one is able to smoosh gates together and eliminate
gate delays, but the rules for when smooshing is allowed are not
obvious to me. I just assumed that it all sorts out in SPICE simulation.
Almost always be deMorganizing the logic.
I find this makes it more difficult to just look at a CMOS logic circuit
and know whether it will fit within a 20 gate delay stage budget.
If the gate delay count is less than 20, there is "some" sizing of
those gates which will result in minimum delay.
Dan Cross wrote:
In article <10rsktu$287kv$2@dont-email.me>,
David Brown <david.brown@hesbynett.no> wrote:
I don't know the details of the regulations, but I can assure you that
it is entirely within them. As a student, his flat is considered
temporary accommodation and our house is his permanent home. His
National Guard base is in our area, not where he is a student.
Maybe the regulations in the USA are different. Maybe there are
different standards about how quickly you can be called up and need to
deploy.
Misrepresenting your home address, such as using your parents'
home when you don't actually live there, temporary accommodation
or not, is not something the US military looks upon favorably.
Didn't you read his comment?
Here in Norway, any student's home address
is considered to be wherever she/he lived before starting to study.
The only exception is if you, like I did, actually buy a flat/apartment
near the university, at that point this was considered my primary residence.
On Sun, 19 Apr 2026 03:54:40 -0500
BGB <cr88192@gmail.com> wrote:
Did see someone on the RISC-V sig-fp mailing also favoring DAZ/FTZ
and similar for floating point.
So, it isn't exactly unheard of...
As I said above, I think that IEEE 754 definitions for basic ops are
great.
I strongly oppose "flush subnormals to zero".
I am not sure what is DAZ. Does it abbreviate "De-normals are zero" ?
I.e. subnormal not only never produced as result of arithmetic ops but
also silently converted to zero when taken as input?
If that what DAZ means then I oppose it even stronger than FTZ.
EricP <ThatWouldBeTelling@thevillage.com> schrieb:
In fast designs, there is an entire team charged with buffering and
routing the CLOCK so that every gate in 10^2 mm^2 receives its rising
edge and falling edge with less than 1 gate of delay 'skew' across
the whole chip using wires that have more than 1 gate of delay when
jumping over 30 gates. CRAY-1 had less than 1ns of clock skew in a
machine the size of restaurant refrigerator using wires with 2ns/foot
of delay. In ASIC designs, we assume (starting out) that there will
be 1/2 clock of skew in the 'clock'
The part I don't see is the rules for combinatorial gates.
There also seem to be combinatorial gates like XOR or AND-OR-INV or MUX
where multiple gates are combined in one but at a lower gate delay.
For example, in TTL an XOR or a 2:1 or 4:1 mux has 3 or 4 gate delays
because it really is an INV, an AND and a OR,
but in CMOS those seem to be just 1 or 1.5 gate delays.
There is the method of logical effort, see https://en.wikipedia.org/wiki/Logical_effort . I have not made
much effort to do calculations using that method.
An alternative would be to use an actual library as an example.
A company called Nangate released an open-sourced library (google
for NangateOpenCellLibrary_typical.lib ), based on a 45 nm process,
for which delay calculations can be done as example, for example
using Berkeley ABC. That program can also do optimiztations
(although it cannot handle gates with more than one input, such as
full adders, and has weaknesses in stability). I haven't tried to
model wire delays with this.
In CMOS sometimes one is able to smoosh gates together and eliminate
gate delays, but the rules for when smooshing is allowed are not
obvious to me. I just assumed that it all sorts out in SPICE simulation.
AOI and friends also work in TTL, I believe.
I find this makes it more difficult to just look at a CMOS logic circuit
and know whether it will fit within a 20 gate delay stage budget.
An interesting question :-)
On 2026-Apr-18 13:59, MitchAlsup wrote:------------------
A 4:1 Mux is a 2222AOI gate--one Ssllooww gate--but still 1 gate.
One slow gate is generally faster than 2 gates (and less power)
because only 1 signal has to move (Vdd->gnd or gnd->Vdd) instead
of more than one. Each signal moving is limited by the transcon-
ductance of the FET stack and the capacitance being driven. We
call the rise/fall time the edge speed.
In CMOS sometimes one is able to smoosh gates together and eliminate
gate delays, but the rules for when smooshing is allowed are not
obvious to me. I just assumed that it all sorts out in SPICE simulation.
Almost always be deMorganizing the logic.
I'm referring to where you merge gates together.
For example, an XOR is (A nand (not B)) nand ((not A) nand B)
which is 2 INV (4T) and 3 NAND gates (12T) with a total of
16 transistors and a delay of 3.
The 3 NAND can merge into a single gate of 8 transistors
and a total of 12T and a delay of 2.
Presumably this merging of gates can continue to some point
but what that point is isn't clear to me.
That makes it difficult to look at a logic diagram and
know how many gates are going to merge that way.
On 4/19/2026 4:28 AM, Michael S wrote:
On Sun, 19 Apr 2026 03:54:40 -0500
BGB <cr88192@gmail.com> wrote:
Did see someone on the RISC-V sig-fp mailing also favoring DAZ/FTZ
and similar for floating point.
So, it isn't exactly unheard of...
As I said above, I think that IEEE 754 definitions for basic ops are
great.
I strongly oppose "flush subnormals to zero".
I also agree with the formats and basic ops, main sticking point is that subnormals make some things more complicated and expensive for hardware.
Main problem case in practice (where differences between subnormals and
FTZ semantics becomes visible) involves dividing something by a value
very close to zero. This requires alternate handling to get correct
results (the naive x*y => x*(1.0/y) strategy no longer works).
So, for SIMD, I mostly ended up going with Fixed-RNE, DAZ+FTZ, and Two's Complement FSUB, mostly because the alternative was poor even for SIMD.
2.0 - 3.0 => -0.999999
Is kinda obvious in its suck.
On 2026-Apr-18 15:23, Thomas Koenig wrote:
EricP <ThatWouldBeTelling@thevillage.com> schrieb:
In fast designs, there is an entire team charged with buffering and
routing the CLOCK so that every gate in 10^2 mm^2 receives its rising
edge and falling edge with less than 1 gate of delay 'skew' across
the whole chip using wires that have more than 1 gate of delay when
jumping over 30 gates. CRAY-1 had less than 1ns of clock skew in a
machine the size of restaurant refrigerator using wires with 2ns/foot
of delay. In ASIC designs, we assume (starting out) that there will
be 1/2 clock of skew in the 'clock'
The part I don't see is the rules for combinatorial gates.
There also seem to be combinatorial gates like XOR or AND-OR-INV or MUX
where multiple gates are combined in one but at a lower gate delay.
For example, in TTL an XOR or a 2:1 or 4:1 mux has 3 or 4 gate delays
because it really is an INV, an AND and a OR,
but in CMOS those seem to be just 1 or 1.5 gate delays.
There is the method of logical effort, see https://en.wikipedia.org/wiki/Logical_effort . I have not made
much effort to do calculations using that method.
Yes, I haven't actually used it either.
Sutherland has examples of the gate merging I'm referring to.
Section 4.4 Asymmetric logic gates figure 4.3 has an example of
(A and B) nor C)
merges the AND and NOR gates so instead of 2 gates and 8 transistors
its 1 gate 6 transistors.
An alternative would be to use an actual library as an example.
A company called Nangate released an open-sourced library (google
for NangateOpenCellLibrary_typical.lib ), based on a 45 nm process,
for which delay calculations can be done as example, for example
using Berkeley ABC. That program can also do optimiztations
(although it cannot handle gates with more than one input, such as
full adders, and has weaknesses in stability). I haven't tried to
model wire delays with this.
A while ago I was rummaging about and found the individual gate
delay info in the open source Process Design Kit (PDK) files.
https://skywater-pdk.readthedocs.io/en/main/ https://github.com/google/skywater-pdk
In CMOS sometimes one is able to smoosh gates together and eliminate
gate delays, but the rules for when smooshing is allowed are not
obvious to me. I just assumed that it all sorts out in SPICE simulation.
AOI and friends also work in TTL, I believe.
Yes but you don't get to merge gates together to shorten the delay.
You only get to choose from the packages available
and for most situations just scan the spec sheet and use
the max of the all propagation delays.
I find this makes it more difficult to just look at a CMOS logic circuit >> and know whether it will fit within a 20 gate delay stage budget.
An interesting question :-)
BGB <cr88192@gmail.com> posted:
On 4/19/2026 4:28 AM, Michael S wrote:
On Sun, 19 Apr 2026 03:54:40 -0500
BGB <cr88192@gmail.com> wrote:
Did see someone on the RISC-V sig-fp mailing also favoring DAZ/FTZ
and similar for floating point.
So, it isn't exactly unheard of...
As I said above, I think that IEEE 754 definitions for basic ops are
great.
I strongly oppose "flush subnormals to zero".
I also agree with the formats and basic ops, main sticking point is that
subnormals make some things more complicated and expensive for hardware.
And yet we have single chips with 64 cores, each core containing 5
(sometimes 9) FMAC in 64-bit sizes--where most of the chip is actually
L2 and L3 caches. In real silicon technology, this means one can put
600 64-bit FMACs on a die. In the GPU world, they put 2000 FMACs on
a single die.
I submit that back when it was hard to put a whole core on a chip
you had a shred of an argument, now you do not--we grew out of those constraints.
Main problem case in practice (where differences between subnormals and
FTZ semantics becomes visible) involves dividing something by a value
very close to zero. This requires alternate handling to get correct
results (the naive x*y => x*(1.0/y) strategy no longer works).
If you consider FDIV as having to get the rounding correct--that
method NEVER EVER worked: but you don't even bother getting FMUL
correctly rounded.....
-------------------
So, for SIMD, I mostly ended up going with Fixed-RNE, DAZ+FTZ, and Two's
Complement FSUB, mostly because the alternative was poor even for SIMD.
2.0 - 3.0 => -0.999999
Is kinda obvious in its suck.
Note: IEEE 754 delivers the right answer, BTW...
On 4/19/2026 4:47 PM, MitchAlsup wrote:
BGB <cr88192@gmail.com> posted:
On 4/19/2026 4:28 AM, Michael S wrote:
On Sun, 19 Apr 2026 03:54:40 -0500
BGB <cr88192@gmail.com> wrote:
Did see someone on the RISC-V sig-fp mailing also favoring DAZ/FTZ
and similar for floating point.
So, it isn't exactly unheard of...
As I said above, I think that IEEE 754 definitions for basic ops are
great.
I strongly oppose "flush subnormals to zero".
I also agree with the formats and basic ops, main sticking point is that >>> subnormals make some things more complicated and expensive for hardware.
And yet we have single chips with 64 cores, each core containing 5
(sometimes 9) FMAC in 64-bit sizes--where most of the chip is actually
L2 and L3 caches. In real silicon technology, this means one can put
600 64-bit FMACs on a die. In the GPU world, they put 2000 FMACs on
a single die.
I submit that back when it was hard to put a whole core on a chip
you had a shred of an argument, now you do not--we grew out of those
constraints.
Realistically, anyone making a hobbyist class core can't make anything
like what you describe.
And, if doing it on an (affordable) FPGA, can only do what an FPGA can realistically manage. Which isn't even anywhere near the level of the
SoC that fits in a typical cellphone at this point.
more like late 1990s logic complexity at early 1990s clock speeds.
Well, and, for PCs, most people don't have 64 cores either...
-a Typical consumer-grade CPUs being more like 8 or 16 cores.
Also typical GPU FPUs are low precision (with trying to use "double" in
a GPGPU context often resulting in a fairly steep performance penalty).
For "enterprise" stuff, that is more "money to burn", which is a very different scenario.
Well, then there are NPUs, which seem to be going in a more "mixed FP8/ FP16" direction. But, doing FMA at "FP8*FP8+FP16" is also, a very
different situation.
Well, and if your task is mostly bandwidth bound, maximal FPU precision
is not the priority.
Even in my case, I am still left partly battling memory bandwidth walls (like, say, frequent use of FP8 or FP16 in my case not being about
trying to save RAM; rather trying to optimize for D$ and I$ and memory bandwidth and similar).
Which is ironic in a way, given that seemingly I am in a better place relative to memory-bandwidth compared with clock-speed vs a lot of
late-90s and early-2000s CPUs (well, because running a 16-bit wide DDR
chip at 50 MHz, isn't *that* drastically slower than a 64-bit wide SO-
DIMM running at 67 MHz from the early 2000s; or at least if comparing 50
MHz vs 1400 MHz for the CPU core).
Though, there is still the limit of what sorts of use-cases one can fit
into the limited precision of these formats.
...
Main problem case in practice (where differences between subnormals and
FTZ semantics becomes visible) involves dividing something by a value
very close to zero. This requires alternate handling to get correct
results (the naive x*y => x*(1.0/y) strategy no longer works).
If you consider FDIV as having to get the rounding correct--that
method NEVER EVER worked: but you don't even bother getting FMUL
correctly rounded.....
-------------------
Not in the DAZ/FTZ mode, granted.
For the IEEE emulation mode, the idea is to try to patch things up as
needed such that FMUL is correct (similar to the matter of dealing with subnormal numbers).
But, yeah, the DAZ/FTZ mode may typically also give incorrectly rounded
FMUL as well as incorrectly rounded FDIV.
In both cases, the issue appears to go away though if the intermediate computations are done at Binary128 precision. But, this is its own pros/ cons thing.
So, for SIMD, I mostly ended up going with Fixed-RNE, DAZ+FTZ, and Two's >>> Complement FSUB, mostly because the alternative was poor even for SIMD.
2.0 - 3.0 => -0.999999
Is kinda obvious in its suck.
Note: IEEE 754 delivers the right answer, BTW...
Yes, but I was pointing out mostly the problem of trying to cheap out
too much.
While for SIMD it initially seems like one can cheap out really hard,
basic integer arithmetic scenarios failing to give exact results, and a tendency for values to drift towards zero, can start to have fairly
obvious and visible effects.
So, there is a limit here...
It can escape notice if limited solely to graphics and audio tasks, but
as soon as one starts trying to use it for something much more demanding than pixel colors or audio mixing, it falls on its face.
One place it becomes obvious pretty quickly is if doing physics
calculations or rotation math, where objects' positions and rotations
will start to steadily drift. They tend to be adjusted every frame,
based on things like applying forces and time-steps.
If the objects all start slowly rotating and sliding towards the origin,
the suck is evident.
So, will need to draw a line here.
On 2026-04-19 7:04 p.m., BGB wrote:
On 4/19/2026 4:47 PM, MitchAlsup wrote:I made a 56-core system on an A7-200T. Granted only small 16-bit CPUs
BGB <cr88192@gmail.com> posted:
On 4/19/2026 4:28 AM, Michael S wrote:
On Sun, 19 Apr 2026 03:54:40 -0500
BGB <cr88192@gmail.com> wrote:
Did see someone on the RISC-V sig-fp mailing also favoring DAZ/FTZ >>>>>> and similar for floating point.
So, it isn't exactly unheard of...
As I said above, I think that IEEE 754 definitions for basic ops are >>>>> great.
I strongly oppose "flush subnormals to zero".
I also agree with the formats and basic ops, main sticking point is
that
subnormals make some things more complicated and expensive for
hardware.
And yet we have single chips with 64 cores, each core containing 5
(sometimes 9) FMAC in 64-bit sizes--where most of the chip is actually
L2 and L3 caches. In real silicon technology, this means one can put
600 64-bit FMACs on a die. In the GPU world, they put 2000 FMACs on
a single die.
I submit that back when it was hard to put a whole core on a chip
you had a shred of an argument, now you do not--we grew out of those
constraints.
Realistically, anyone making a hobbyist class core can't make anything
like what you describe.
with no FP. Strange thing, I could never get more than about 48 cores to work.
I think taking the target audience into consideration is important. If
one is trying to produce an example for a low-cost FPGA then there are limits to what can be done. Most people looking for starting-out type examples are not going to look at superscalar machines with FP ops. For
the more complex stuff people expect that larger, more expensive
hardware is required.
I think getting IEEE correct results does not use much more logic than simpler approaches. One is talking small percentages. What is the difference? Hundreds of LUTs in an FPGA with tens of thousands of LUTs available? 64-bit FMA is using about 3600 LUTs with sub-normals and rounding.
If one is not looking for IEEE compatibility there may be other
approaches to FP that might use fewer resources. TworCOs complement representation?
There is the method of logical effort, see
https://en.wikipedia.org/wiki/Logical_effort . I have not made
much effort to do calculations using that method.
Yes, I haven't actually used it either.
Sutherland has examples of the gate merging I'm referring to.
Section 4.4 Asymmetric logic gates figure 4.3 has an example of
(A and B) nor C)
merges the AND and NOR gates so instead of 2 gates and 8 transistors
its 1 gate 6 transistors.
An alternative would be to use an actual library as an example.
A company called Nangate released an open-sourced library (google
for NangateOpenCellLibrary_typical.lib ), based on a 45 nm process,
for which delay calculations can be done as example, for example
using Berkeley ABC. That program can also do optimiztations
(although it cannot handle gates with more than one input, such as
full adders, and has weaknesses in stability). I haven't tried to
model wire delays with this.
A while ago I was rummaging about and found the individual gate
delay info in the open source Process Design Kit (PDK) files.
https://skywater-pdk.readthedocs.io/en/main/ https://github.com/google/skywater-pdk
In CMOS sometimes one is able to smoosh gates together and eliminate
gate delays, but the rules for when smooshing is allowed are not
obvious to me. I just assumed that it all sorts out in SPICE simulation.
AOI and friends also work in TTL, I believe.
Yes but you don't get to merge gates together to shorten the delay.
You only get to choose from the packages available
and for most situations just scan the spec sheet and use
the max of the all propagation delays.
In fast designs, there is an entire team charged with buffering and
routing the CLOCK so that every gate in 10^2 mm^2 receives its rising
edge and falling edge with less than 1 gate of delay 'skew' across
the whole chip using wires that have more than 1 gate of delay when
jumping over 30 gates. CRAY-1 had less than 1ns of clock skew in a
machine the size of restaurant refrigerator using wires with 2ns/foot
of delay. In ASIC designs, we assume (starting out) that there will
be 1/2 clock of skew in the 'clock'
On 4/17/26 9:11 PM, MitchAlsup wrote:
[snip]
In fast designs, there is an entire team charged with buffering and
routing the CLOCK so that every gate in 10^2 mm^2 receives its rising
edge and falling edge with less than 1 gate of delay 'skew' across
the whole chip using wires that have more than 1 gate of delay when
jumping over 30 gates. CRAY-1 had less than 1ns of clock skew in a
machine the size of restaurant refrigerator using wires with 2ns/foot
of delay. In ASIC designs, we assume (starting out) that there will
be 1/2 clock of skew in the 'clock'
I thought that some designs used intentional clock skew. If the
natural places to divide pipeline stages results in different
logic depths, a skewed clock would enable some stages to borrow
time from others (I think).
Perhaps this is not called 'skew'.
(I have also read that pipeline stage delay can be kept constant
and area/power traded with time, i.e., a normally longer stage
can spend area/power to reduce delay and a normally shorter
stage can save area/power by spending the delay slack.)
5 pounds of sand does not fit in a 4 pound bag !
I had to toss out the feature I had briefly
added, of an alternate instruction set where memory operations were
aligned, so that paired short instructions without register restrictions could be included at 50% of the opcode space.
At the moment, I don't think that's worth the trouble.
In addition to adding the new header, I added some additional needed instructions to the alternate instruction set - and corrected a mistake
in it as well.
On Tue, 17 Mar 2026 18:16:16 +0000, MitchAlsup wrote:
5 pounds of sand does not fit in a 4 pound bag !
Indeed.
The basic load-store instruction set takes up about 75% of the opcode
space of 32-bit instructions.
Including pairs of short instructions, sharing a 32-bit word, takes up
about 25% of the opcode space of 32-bit instructions.
The trouble is, though, I need a few other things.
I needed 32-bit operate instructions and additional memory-reference instructions. In my current iteration, I squeeze them out of a few unused opcodes in the short instructions. I had to squash the operate--- Synchronet 3.21f-Linux NewsLink 1.2
instructions down to half the space I had been using for them to do this.
Operate instructions: about 1/128 of the opcode space; extra memory- reference instructions: about 1/64 of the opcode space.
Also, I wanted a header that took up 1/16 of the opcode space, as the preferred simplest way to call for variable-length instructions. I had two spare opcodes in the 32-bit load-store instructions, but I had wanted to hang on to them for one extra instruction. I finally decided to limit the destination registers for the load address instruction so I could grab
both opcodes.
Now I really have run out of opcode space as far as general 32-bit instructions are concerned. I had to toss out the feature I had briefly added, of an alternate instruction set where memory operations were
aligned, so that paired short instructions without register restrictions could be included at 50% of the opcode space. (That was because I didn't have a spare bit in the header for the type of code this would have been most useful with; of course, since an alternate instruction set is in a separate opcode space, I could still have it, just at a higher overhead
cost of requesting it for a block; it just was no longer worth having, or
so it seems.)
John Savard
An architecture is as much about what you leave out as what you leave
in.
On Fri, 01 May 2026 17:36:27 +0000, MitchAlsup wrote:
An architecture is as much about what you leave out as what you leave
in.
In Concertina II, it certainly does seem like I've included a lot. The
ISA could be said to be bulging at the seams, like an overstuffed
suitcase. I can see how that would seem to be a bad choice.
On Fri, 01 May 2026 17:36:27 +0000, MitchAlsup wrote:
An architecture is as much about what you leave out as what you leave
in.
That certainly is true.
And no matter what I do, since there are an infinity of possibilities, I
will always have left out more than I've included.
In Concertina II, it certainly does seem like I've included a lot. The ISA could be said to be bulging at the seams, like an overstuffed suitcase. I
can see how that would seem to be a bad choice.
Where is the emphasis in Concertina II? What does it prefer to leave in,
and what is it content to leave out?
The Motorola 68000 and the 80386 had groups of eight registers. The IBM
360 had sixteen integer registers, but only four floating-point ones. Most RISC processors have 32 registers.
Traditional processors had instructions that performed an arithmetic operation from memory into a register. RISC processors do arithmetic only
in registers, with operations to load and store from memory.
The System/360 addressed memory with a base register and an index register
in addition to a 12-bit displacement. Most microprocessors use 16-bit displacements, but usually only let you use one register with it.
I've tried to encompass all the features of these different processors as much as I could.
Accessing variables in arrays needs an index register for which element in the array is being accessed, and a base register in addition to the small displacement in the instruction.
I felt I couldn't leave _that_ out.
But every other modern architecture decided that they didn't need
separate base registers. Do you think they were wrong? Having them
doesn't save you anything - you still have to add to a register to
increment the element number. In fact it costs a little in the hardware
as the addressing requires two adds (Base+index+displacement) versus one (index + displacement). And it uses up a register needlessly. So why
include it?
On Fri, 01 May 2026 12:29:01 -0700, Stephen Fuld wrote:
But every other modern architecture decided that they didn't need
separate base registers. Do you think they were wrong? Having them doesn't save you anything - you still have to add to a register to increment the element number. In fact it costs a little in the hardware
as the addressing requires two adds (Base+index+displacement) versus one (index + displacement). And it uses up a register needlessly. So why include it?
It's true that address calculation, especially for multi-dimensional
arrays, involves extra steps.
Base-index addressing doesn't force two additions every time; one chooses whether or not an instruction is indexed.
But when one is referring to an array element, it saves adding the displacement either to the address or the base value by means of an
explicit add instruction. One doesn't save a register by not having indexing. One is still used to contain the modified address.
John Savard
But every other modern architecture decided that they didn't need
separate base registers. Do you think they were wrong?
On 5/1/2026 12:00 PM, quadi wrote:
The System/360 addressed memory with a base register and an index register >> in addition to a 12-bit displacement.
Most microprocessors use 16-bit
displacements, but usually only let you use one register with it.
But every other modern architecture decided that they didn't need
separate base registers.
quadi <quadibloc@ca.invalid> posted:
On Fri, 01 May 2026 12:29:01 -0700, Stephen Fuld wrote:
But every other modern architecture decided that they didn't need
separate base registers. Do you think they were wrong? Having them
doesn't save you anything - you still have to add to a register to
increment the element number. In fact it costs a little in the hardware >>> as the addressing requires two adds (Base+index+displacement) versus one >>> (index + displacement). And it uses up a register needlessly. So why
include it?
It's true that address calculation, especially for multi-dimensional
arrays, involves extra steps.
Base-index addressing doesn't force two additions every time; one chooses
whether or not an instruction is indexed.
People forget about the extra instructions:: lack of base+index causes
a) longer latency
b) more instructions
c) larger code footprint
d) compiler has to work harder
e)...
So the 2%-4% of its use causes 4%-8% more instructions which can be eliminated for 1-extra gate of delay (3-input adder versus 2-input).
It is a more delicate balance than one presupposes.
Given base+index+displacement there are never any support instruc-
tions in memory access. Given displacement can be {16-bits, 32-bits,
or 64-bits} all of memory is accessible in a single instruction...
ALWAYS !! This gets rid of another 3%-ish of instruction footprint
tipping the balance from 6%-ish (average of above) to 12%-ish (with
these additional savings, tipping the balance towards "put it in".
Stephen Fuld <sfuld@alumni.cmu.edu.invalid> writes:
On 5/1/2026 12:00 PM, quadi wrote:
The System/360 addressed memory with a base register and an index register >>> in addition to a 12-bit displacement.
The S/360 has general-purpose registers,
Most microprocessors use 16-bit
displacements, but usually only let you use one register with it.
How do you count "most"? There are a lot of AMD64 processors that
offer reg+reg*[1248]+offset.
But every other modern architecture decided that they didn't need
separate base registers.
The S/360 does not have separate base registers.
One might consider the FS and GS registers of AMD64 to be dedicated
base registers. AFAIK FS is used for thread-local variables in some
OSs. But for single-threaded code, I have never seen any compiler use
FS or GS, and have not seen any assembly language program (other than
those for demonstrating their existence) use FS or GS, either. So
there seems to be little need for separate base registers.
Concerning addressing modes that involve GPRs, there are a lot of
statistics around about their use, and you can make your own
relatively easily by observing the usage of addressing modes on AMD64.
Note that for some registers, AMD64 requires the use of a displacement
even if it is 0 (that's because the encoding that one would expect for
the displacementless use of these registers has anoter meaning).
- anton
The S/360 has general-purpose registers,
The S/360 does not have separate base registers.
On Fri, 01 May 2026 12:29:01 -0700, Stephen Fuld wrote:
But every other modern architecture decided that they didn't need
separate base registers. Do you think they were wrong?
This is a kind of question that is hard to answer.
Do I think that I'm smarter than all those guys who designed RISC
processors? No, of course not.
But a lot of smart guys worked on the System/360 also. So the question may
be whether or not my goals are different from theirs.
After all, when the very first RISC machines came out, they didn't include floating-point arithmetic; while that was partly due to enough gates not
yet being available, the rationale was given that floating-point
arithmetic couldn't be done in one cycle.
That was quickly rejected as silly.
Index registers were considered a good idea back when they were originally introduced. It meant you could redirect an instruction to point somewhere else without modifying the instruction in memory.
Base registers became a necessity once computer memories got so large -
over 64K locations or thereabouts - that it wasn't practical to put whole addresses in instructions.
So the base register, although it works the
same way as an index register, does something different - an index
register might be incremented once per loop, while base registers are left alone.
So accessing an array requires one basically to copy a base register value into another register, and add the index to it.
On Fri, 01 May 2026 12:29:01 -0700, Stephen Fuld wrote:
But every other modern architecture decided that they didn't need
separate base registers. Do you think they were wrong?
This is a kind of question that is hard to answer.
Do I think that I'm smarter than all those guys who designed RISC >processors? No, of course not.
But a lot of smart guys worked on the System/360 also.
Index registers were considered a good idea back when they were originally >introduced. It meant you could redirect an instruction to point somewhere >else without modifying the instruction in memory.
Base registers became a necessity once computer memories got so large -
over 64K locations or thereabouts - that it wasn't practical to put whole >addresses in instructions.
On 5/1/2026 10:09 PM, quadi wrote:
On Fri, 01 May 2026 12:29:01 -0700, Stephen Fuld wrote:
But every other modern architecture decided that they didn't need
separate base registers. Do you think they were wrong?
This is a kind of question that is hard to answer.
Do I think that I'm smarter than all those guys who designed RISC
processors? No, of course not.
But a lot of smart guys worked on the System/360 also. So the question may >> be whether or not my goals are different from theirs.
Not goals exactly, but constraints. Remember, S/360 had no memory
address relocation hardware such as a hardware base register or paging.
The addresses in a program were real memory addresses. Thus address say 1,000 in a program was real memory address 1,000. So absent base
registers, you couldn't have more than one program in memory at the same time, since program1's address 1,000 would have referred to the same
real memory address as program2's address 1,000.
quadi <quadibloc@ca.invalid> writes:
On Fri, 01 May 2026 12:29:01 -0700, Stephen Fuld wrote:
But every other modern architecture decided that they didn't need
separate base registers. Do you think they were wrong?
This is a kind of question that is hard to answer.
Do I think that I'm smarter than all those guys who designed RISC
processors? No, of course not.
But a lot of smart guys worked on the System/360 also.
It was a product of the times. We've advanced well beyond
that in the intervening half-century.
Really, the 360 operating
systems were relatively crude and difficult to use compared
with the contemporaneous competition.
Index registers were considered a good idea back when they were originally >> introduced. It meant you could redirect an instruction to point somewhere
else without modifying the instruction in memory.
The earliest incarnations of such were often not 'registers' per-se, but rather reserved locations in memory (c.f. PDP-8 'TAD I'). The Electrodata 220 had a 'B' register - the predecessor Electrodata 205 was the first commercial computer to offer an Index register (with the idea inspired
by the Manchester Mark I).
quadi <quadibloc@ca.invalid> posted:
On Fri, 01 May 2026 12:29:01 -0700, Stephen Fuld wrote:
But every other modern architecture decided that they didn't need
separate base registers. Do you think they were wrong? Having them
doesn't save you anything - you still have to add to a register to
increment the element number. In fact it costs a little in the hardware >>> as the addressing requires two adds (Base+index+displacement) versus one >>> (index + displacement). And it uses up a register needlessly. So why
include it?
It's true that address calculation, especially for multi-dimensional
arrays, involves extra steps.
Base-index addressing doesn't force two additions every time; one chooses
whether or not an instruction is indexed.
People forget about the extra instructions:: lack of base+index causes
a) longer latency
b) more instructions
c) larger code footprint
d) compiler has to work harder
e)...
So the 2%-4% of its use causes 4%-8% more instructions which can be eliminated for 1-extra gate of delay (3-input adder versus 2-input).
It is a more delicate balance than one presupposes.
Given base+index+displacement there are never any support instruc-
tions in memory access. Given displacement can be {16-bits, 32-bits,
or 64-bits} all of memory is accessible in a single instruction...
ALWAYS !! This gets rid of another 3%-ish of instruction footprint
tipping the balance from 6%-ish (average of above) to 12%-ish (with
these additional savings, tipping the balance towards "put it in".
Modern CPUs, and I presume your design, use paging to allow multiple occurrences of the same address (in different programs) to refer to
different real memory addresses, thus don't need to specify a base
address in every memory reference instruction.
But a lot of smart guys worked on the System/360 also.
After all, when the very first RISC machines came out, they didn't include >floating-point arithmetic;
while that was partly due to enough gates not
yet being available, the rationale was given that floating-point
arithmetic couldn't be done in one cycle.
Base registers became a necessity once computer memories got so large -
over 64K locations or thereabouts - that it wasn't practical to put whole >addresses in instructions.
So accessing an array requires one basically to copy a base register value >into another register, and add the index to it. That's an extra
instruction. It may not be needed for every array access, as you can still >increment that modified base value. (Hmm. So since an addition is removed >from address calculation in the instruction, one _could_ claim that
lacking index/base addressing forces an *optimization* to be done. I'll
have to think about that.)
On Sat, 02 May 2026 05:37:21 -0700, Stephen Fuld wrote:
Modern CPUs, and I presume your design, use paging to allow multiple
occurrences of the same address (in different programs) to refer to
different real memory addresses, thus don't need to specify a base
address in every memory reference instruction.
Actually, that conclusion isn't quite right. This would work for a CPU
like Intel's 432. But I intend programs to be able to work with large
linear address spaces bigger than 64K, bigger than the displacement field
in an instruction. That means a base register is still needed despite hardware paging features being potentially present.
On 5/1/2026 10:09 PM, quadi wrote:[...]
Modern CPUs, and I presume your design, use paging to allow multiple >occurrences of the same address (in different programs) to refer to >different real memory addresses, thus don't need to specify a base
address in every memory reference instruction.
So accessing an array requires one basically to copy a base register value >> into another register, and add the index to it.
No. Do you think that current CPU designs require that? They do not.
You simply load the starting address of the array into an index register
and add to that as needed.
On 5/1/2026 7:17 PM, MitchAlsup wrote:
quadi <quadibloc@ca.invalid> posted:
On Fri, 01 May 2026 12:29:01 -0700, Stephen Fuld wrote:
But every other modern architecture decided that they didn't need
separate base registers.-a Do you think they were wrong?-a Having them >>>> doesn't save you anything - you still have to add to a register to
increment the element number.-a In fact it costs a little in the
hardware
as the addressing requires two adds (Base+index+displacement) versus
one
(index + displacement).-a And it uses up a register needlessly. So why >>>> include it?
It's true that address calculation, especially for multi-dimensional
arrays, involves extra steps.
Base-index addressing doesn't force two additions every time; one
chooses
whether or not an instruction is indexed.
People forget about the extra instructions:: lack of base+index causes
a) longer latency
b) more instructions
c) larger code footprint
d) compiler has to work harder
e)...
So the 2%-4% of its use causes 4%-8% more instructions which can be
eliminated for 1-extra gate of delay (3-input adder versus 2-input).
It is a more delicate balance than one presupposes.
I can believe that.
Given base+index+displacement there are never any support instruc-
tions in memory access. Given displacement can be {16-bits, 32-bits,
or 64-bits} all of memory is accessible in a single instruction...
Yes, but adding the specification of a base register takes instruction
bits away from somewhere else, typically the displacement.-a So the
S/360s choice to use them reduced the displacement to 12 bits.-a So
larger programs required use of multiple base registers, which required loading them, i.e. extra support instructions, and increased register pressure (though with the availability of storage to storage
instructions, that was less of an issue)
ALWAYS !! This gets rid of another 3%-ish of instruction footprint
tipping the balance from 6%-ish (average of above) to 12%-ish (with
these additional savings, tipping the balance towards "put it in".
Then why did just about every modern architecture, including your My
66000, omit them?
On Fri, 01 May 2026 12:29:01 -0700, Stephen Fuld wrote:
But every other modern architecture decided that they didn't need
separate base registers. Do you think they were wrong?
This is a kind of question that is hard to answer.
Do I think that I'm smarter than all those guys who designed RISC processors? No, of course not.
But a lot of smart guys worked on the System/360 also. So the question may be whether or not my goals are different from theirs.
After all, when the very first RISC machines came out, they didn't include floating-point arithmetic; while that was partly due to enough gates not
yet being available, the rationale was given that floating-point
arithmetic couldn't be done in one cycle.
That was quickly rejected as silly.
Index registers were considered a good idea back when they were originally introduced. It meant you could redirect an instruction to point somewhere else without modifying the instruction in memory.
Base registers became a necessity once computer memories got so large -
over 64K locations or thereabouts - that it wasn't practical to put whole addresses in instructions.
So the base register, although it works the
same way as an index register, does something different - an index
register might be incremented once per loop, while base registers are left alone.
So accessing an array requires one basically to copy a base register value into another register, and add the index to it. That's an extra
instruction.
It may not be needed for every array access, as you can still increment that modified base value. (Hmm. So since an addition is removed from address calculation in the instruction, one _could_ claim that--- Synchronet 3.21f-Linux NewsLink 1.2
lacking index/base addressing forces an *optimization* to be done. I'll
have to think about that.)
John Savard
On Sat, 02 May 2026 06:19:43 +0000, Anton Ertl wrote:
The S/360 has general-purpose registers,
The S/360 does not have separate base registers.
That's true. But I think he was talking about the fact that S/360 memory- reference instructions had one field to specify a general register to use
as the index register, and another field to specify a general register to use as the base register, while most modern architectures only have _one_ field to specify a register the contents of which are to be added to the displacement.
John Savard--- Synchronet 3.21f-Linux NewsLink 1.2
On 5/2/2026 10:01 AM, Stephen Fuld wrote:
On 5/1/2026 7:17 PM, MitchAlsup wrote:
quadi <quadibloc@ca.invalid> posted:
On Fri, 01 May 2026 12:29:01 -0700, Stephen Fuld wrote:
But every other modern architecture decided that they didn't need
separate base registers.-a Do you think they were wrong?-a Having them >>>>> doesn't save you anything - you still have to add to a register to
increment the element number.-a In fact it costs a little in the
hardware
as the addressing requires two adds (Base+index+displacement)
versus one
(index + displacement).-a And it uses up a register needlessly. So why >>>>> include it?
It's true that address calculation, especially for multi-dimensional
arrays, involves extra steps.
Base-index addressing doesn't force two additions every time; one
chooses
whether or not an instruction is indexed.
People forget about the extra instructions:: lack of base+index causes
a) longer latency
b) more instructions
c) larger code footprint
d) compiler has to work harder
e)...
So the 2%-4% of its use causes 4%-8% more instructions which can be
eliminated for 1-extra gate of delay (3-input adder versus 2-input).
It is a more delicate balance than one presupposes.
I can believe that.
Given base+index+displacement there are never any support instruc-
tions in memory access. Given displacement can be {16-bits, 32-bits,
or 64-bits} all of memory is accessible in a single instruction...
Yes, but adding the specification of a base register takes instruction
bits away from somewhere else, typically the displacement.-a So the
S/360s choice to use them reduced the displacement to 12 bits.-a So
larger programs required use of multiple base registers, which
required loading them, i.e. extra support instructions, and increased
register pressure (though with the availability of storage to storage
instructions, that was less of an issue)
ALWAYS !! This gets rid of another 3%-ish of instruction footprint
tipping the balance from 6%-ish (average of above) to 12%-ish (with
these additional savings, tipping the balance towards "put it in".
Then why did just about every modern architecture, including your My
66000, omit them?
Apologies!-a I see that for loads and stores, your design does offer such modes.
On 5/1/2026 7:17 PM, MitchAlsup wrote:
quadi <quadibloc@ca.invalid> posted:
On Fri, 01 May 2026 12:29:01 -0700, Stephen Fuld wrote:
But every other modern architecture decided that they didn't need
separate base registers. Do you think they were wrong? Having them
doesn't save you anything - you still have to add to a register to
increment the element number. In fact it costs a little in the hardware >>> as the addressing requires two adds (Base+index+displacement) versus one >>> (index + displacement). And it uses up a register needlessly. So why
include it?
It's true that address calculation, especially for multi-dimensional
arrays, involves extra steps.
Base-index addressing doesn't force two additions every time; one chooses >> whether or not an instruction is indexed.
People forget about the extra instructions:: lack of base+index causes
a) longer latency
b) more instructions
c) larger code footprint
d) compiler has to work harder
e)...
So the 2%-4% of its use causes 4%-8% more instructions which can be eliminated for 1-extra gate of delay (3-input adder versus 2-input).
It is a more delicate balance than one presupposes.
I can believe that.
Given base+index+displacement there are never any support instruc-
tions in memory access. Given displacement can be {16-bits, 32-bits,
or 64-bits} all of memory is accessible in a single instruction...
Yes, but adding the specification of a base register takes instruction
bits away from somewhere else, typically the displacement. So the
S/360s choice to use them reduced the displacement to 12 bits. So
larger programs required use of multiple base registers,
which required loading them, i.e. extra support instructions, and increased register pressure (though with the availability of storage to storage
instructions, that was less of an issue)
ALWAYS !! This gets rid of another 3%-ish of instruction footprint
tipping the balance from 6%-ish (average of above) to 12%-ish (with
these additional savings, tipping the balance towards "put it in".
Then why did just about every modern architecture, including your My
66000, omit them?
On Sat, 02 May 2026 05:37:21 -0700, Stephen Fuld wrote:
Modern CPUs, and I presume your design, use paging to allow multiple occurrences of the same address (in different programs) to refer to different real memory addresses, thus don't need to specify a base
address in every memory reference instruction.
Actually, that conclusion isn't quite right. This would work for a CPU
like Intel's 432. But I intend programs to be able to work with large
linear address spaces bigger than 64K, bigger than the displacement field
in an instruction. That means a base register is still needed despite
hardware paging features being potentially present.
John Savard--- Synchronet 3.21f-Linux NewsLink 1.2
Stephen Fuld <sfuld@alumni.cmu.edu.invalid> writes:
On 5/1/2026 10:09 PM, quadi wrote:[...]
Modern CPUs, and I presume your design, use paging to allow multiple >occurrences of the same address (in different programs) to refer to >different real memory addresses, thus don't need to specify a base
address in every memory reference instruction.
And then we got ASLR, and now we have to live in a world again where
the code and the static data don't live in fixed locations.
So accessing an array requires one basically to copy a base register value >> into another register, and add the index to it.
No. Do you think that current CPU designs require that? They do not.
You simply load the starting address of the array into an index register >and add to that as needed.
In the general case (i.e., when the array index is not the counter of
a counted loop), instruction sets like MIPS, Alpha, and RISC-V need additional instructions for computing the address of the array
element, and only then use a load or store instruction to access the
element. However, these architectures are three-address
architectures, so the starting address of the array does not have to
be copied first in this process.
- anton--- Synchronet 3.21f-Linux NewsLink 1.2
quadi <quadibloc@ca.invalid> posted:
After all, when the very first RISC machines came out, they didn't
include floating-point arithmetic; while that was partly due to enough
gates not yet being available, the rationale was given that
floating-point arithmetic couldn't be done in one cycle.
MIPS had FP, SPARC had FP, Mc88K had FP, Clipper had FP.
What RISCS are you speaking ??
Yes, normally they wouldn't be needed there, since in that code, 48-bit instructions can be expressed in just 48 bits. But those existing 48-bit instructions require prefix bits to distinguish them from the regular
32- bit instructions in the code. The encapsulation format has room for
any arbitrary combination of 48 bits. So _additional_ 48-bit
instructions which don't have the necessary prefix could be defined,
which can only appear in encapsulated form in either kind of code. (So they're really additional 64-bit instructions, but I call them 48-bit
because of the fact that they're placed in association with the real
48-bit instructions.)
Yes, MIPS has FP now, but possibly the very first MIPS processor didn't.
Performance Effects of Architectural Complexity in the Intel 432, 1988 https://www.princeton.edu/~rblee/ELE572Papers/Fall04Readings/I432.pdf
EricP <ThatWouldBeTelling@thevillage.com> schrieb:
Performance Effects of Architectural Complexity in the Intel 432, 1988
https://www.princeton.edu/~rblee/ELE572Papers/Fall04Readings/I432.pdf
Wow... paved with good intentions and all that.
Performance Effects of Architectural Complexity in the Intel 432, 1988 https://www.princeton.edu/~rblee/ELE572Papers/Fall04Readings/I432.pdf
I've made one more little addition to the instruction set.
Now the 48-bit long instructions can be placed within a 64-bit pair of 32- bit "instructions" that can be placed within code without headers.
At first, when I found the opcode space to do that with, it seemed there--- Synchronet 3.21f-Linux NewsLink 1.2
was a conflict which prevented these 64-bit encapsulated instructions from appearing in code with variable-length instructions.
Yes, normally they wouldn't be needed there, since in that code, 48-bit instructions can be expressed in just 48 bits. But those existing 48-bit instructions require prefix bits to distinguish them from the regular 32-
bit instructions in the code. The encapsulation format has room for any arbitrary combination of 48 bits. So _additional_ 48-bit instructions
which don't have the necessary prefix could be defined, which can only appear in encapsulated form in either kind of code. (So they're really additional 64-bit instructions, but I call them 48-bit because of the fact that they're placed in association with the real 48-bit instructions.)
Fortunately, though, I was able to straighten things out and eliminate the conflict without doing violence to the bit-mappings in the instruction set.
John Savard
quadi <quadibloc@ca.invalid> posted:
I've made one more little addition to the instruction set.
I just had an epiphany wrt Concertina II
Now the 48-bit long instructions can be placed within a 64-bit pair of 32- >> bit "instructions" that can be placed within code without headers.
Headers are nothing more than mode-bits that change every block of code.
This means that ISA will be exceptionally difficult to verify, and
as you have found: very difficult to encode.
At first, when I found the opcode space to do that with, it seemed there
was a conflict which prevented these 64-bit encapsulated instructions from >> appearing in code with variable-length instructions.
Yes, normally they wouldn't be needed there, since in that code, 48-bit
instructions can be expressed in just 48 bits. But those existing 48-bit
instructions require prefix bits to distinguish them from the regular 32-
bit instructions in the code. The encapsulation format has room for any
arbitrary combination of 48 bits. So _additional_ 48-bit instructions
which don't have the necessary prefix could be defined, which can only
appear in encapsulated form in either kind of code. (So they're really
additional 64-bit instructions, but I call them 48-bit because of the fact >> that they're placed in association with the real 48-bit instructions.)
Fortunately, though, I was able to straighten things out and eliminate the >> conflict without doing violence to the bit-mappings in the instruction set. >>
John Savard
And, of course, in the event that I ever do define any instructions in
this category, I could always define a new header format in which a particular combination of bits in a prefix field indicates that the
16-bit zone to which it corresponds contains the start of a 48-bit instruction and not one of any other length, which would then give them
the right to be called 48-bit instructions.
Later, when MIPS processors became cheap enough for embedded
computing, there probably were MIPS processors without FPU,
In connection with the changes described in these posts, I had needed to
cut the opcode space available to operate instructions in half.
In re-examining the opcode space available, I've found that I could have three-quarters instead of just half of the original opcode space
available, and this let me add back much of what I had lost in that
area.
quadi <quadibloc@ca.invalid> posted:
So accessing an array requires one basically to copy a base register
value into another register, and add the index to it. That's an extra
instruction.
You are making assumptions that are not necessary. Why don't you spell
them out.
quadi <quadibloc@ca.invalid> posted:
I've made one more little addition to the instruction set.
I just had an epiphany wrt Concertina II
So, while I've said it before, and it hasn't happened, it seems like I'm finally at the point where I can start fleshing out the design by
listing the opcodes for the various instructions, and explaining the
fancy data types.
Oh, dear. We _are_ doomed to eternal suffering, after all: what
Intel took from all these learning experiences was to never try to
deviate from x86 ever again!
They abandoned x86S
On 2026-May-03 09:22, quadi wrote:
On Sun, 15 Mar 2026 14:35:00 +0000, John Dallman wrote:
iAPX 432 had instructions which weren't in whole bytes, and were
addressed by bit offset in a segment. You could only have 64K
instruction bits in a segment, or 8K bytes. The idea was that no
subroutine or function ever needed to be bigger than that.
It's worse than I thought.
While the STRETCH had bit addressing, unlike the STRETCH this sounds genuinely perverse.
John Savard
Performance Effects of Architectural Complexity in the Intel 432, 1988 https://www.princeton.edu/~rblee/ELE572Papers/Fall04Readings/I432.pdf
EricP <ThatWouldBeTelling@thevillage.com> posted:
Performance Effects of Architectural Complexity in the Intel 432, 1988
https://www.princeton.edu/~rblee/ELE572Papers/Fall04Readings/I432.pdf
There was a CMU paper on 432 that stated if Intel had used 1 more pin
that performance could have <about> doubled.
EricP <ThatWouldBeTelling@thevillage.com> posted:
On 2026-May-03 09:22, quadi wrote:There was a CMU paper on 432 that stated if Intel had used 1 more pin
On Sun, 15 Mar 2026 14:35:00 +0000, John Dallman wrote:
iAPX 432 had instructions which weren't in whole bytes, and were
addressed by bit offset in a segment. You could only have 64K
instruction bits in a segment, or 8K bytes. The idea was that no
subroutine or function ever needed to be bigger than that.
It's worse than I thought.
While the STRETCH had bit addressing, unlike the STRETCH this sounds
genuinely perverse.
John Savard
Performance Effects of Architectural Complexity in the Intel 432, 1988
https://www.princeton.edu/~rblee/ELE572Papers/Fall04Readings/I432.pdf
that performance could have <about> doubled.
On 2026-May-08 14:12, MitchAlsup wrote:04Readings/I432.pdf
There was a CMU paper on 432 that stated if Intel had used 1 more pin
that performance could have <about> doubled.
It is still going to have to chew through gobs of microcode to do anything.
I too had microcode on the brain back then. In 1976 I designed (but did not >build) a microcoded cpu core using TTL AMD 2900 bit-slice components.
Lately I have been playing around with circa 1975 TTL paper cpu designs but >done in a pipelined risc style. The instructions must be variable length because
memory was so expensive in 1975. The key is to not bottleneck in Fetch or Decode.
Last month I designed a TTL fetch-parse unit for a risc-ish pipeline using the same
parts as are on the VAX-780 bill of materials or in the 1976 TI logic data book.
The instructions are byte granular, variable length from 1 to 12 bytes long. >That is long enough to hold a 4 byte instruction specifier (opcode + registers)
plus 8 bytes of immediate data. I expect the average instruction to be ~3 bytes.
My fetch unit paper design reads an 8-byte fetch block each clock
into a 32 byte circular prefetch buffer. The parser rotates the whole
32 byte buffer to align the instruction start with the length parser,
and a PLA examines the first 12 instructon bits to get the length.
It then validates that all the bytes are present in the buffer
and passes the 1 to 12 bytes + IP virtual address to the Decoder board.
This can do a sustained 5 MHz parse of 1 variable instruction/clock,
provided it hits the instruction cache. As most instructions are simple
and take 1 clock to execute, it should do sustained 5 MIPS.
Remember the 780 was 5 MHz but only executes at 0.5 MIPS.
It might also fit onto the same size PCB as the 780 used, about 15" x 15", >but requires more edge connector pins for more buses (~300).
On a separate board Decode will store the fetched instruction and
feed it through a bank of PLA chips, which controls tri-state buffers
to route signals into the Decode uOp output register.
If built my Fetch and Decode units could run 10x the speed of a 780,
using the exact same parts but just designed from a non-microcode
point of view.
Lately I have been playing around with circa 1975 TTL paper cpu
designs but done in a pipelined risc style. The instructions must be
variable length because memory was so expensive in 1975. The key is
to not bottleneck in Fetch or Decode.
Last month I designed a TTL fetch-parse unit for a risc-ish pipeline
using the same parts as are on the VAX-780 bill of materials or in
the 1976 TI logic data book.
The instructions are byte granular, variable length from 1 to 12
bytes long. That is long enough to hold a 4 byte instruction
specifier (opcode + registers) plus 8 bytes of immediate data. I
expect the average instruction to be ~3 bytes.
Lately I have been playing around with circa 1975 TTL paper cpu designs but done in a pipelined risc style. The instructions must be variable length because
memory was so expensive in 1975. The key is to not bottleneck in Fetch or Decode.
Last month I designed a TTL fetch-parse unit for a risc-ish pipeline using the same
parts as are on the VAX-780 bill of materials or in the 1976 TI logic data book.
The instructions are byte granular, variable length from 1 to 12 bytes long. That is long enough to hold a 4 byte instruction specifier (opcode + registers)
plus 8 bytes of immediate data. I expect the average instruction to be ~3 bytes.
My fetch unit paper design reads an 8-byte fetch block each clock--
into a 32 byte circular prefetch buffer. The parser rotates the whole
32 byte buffer to align the instruction start with the length parser,
and a PLA examines the first 12 instructon bits to get the length.
It then validates that all the bytes are present in the buffer
and passes the 1 to 12 bytes + IP virtual address to the Decoder board.
This can do a sustained 5 MHz parse of 1 variable instruction/clock,
provided it hits the instruction cache. As most instructions are simple
and take 1 clock to execute, it should do sustained 5 MIPS.
Remember the 780 was 5 MHz but only executes at 0.5 MIPS.
It might also fit onto the same size PCB as the 780 used, about 15" x 15", but requires more edge connector pins for more buses (~300).
On a separate board Decode will store the fetched instruction and
feed it through a bank of PLA chips, which controls tri-state buffers
to route signals into the Decode uOp output register.
If built my Fetch and Decode units could run 10x the speed of a 780,
using the exact same parts but just designed from a non-microcode
point of view.
EricP <ThatWouldBeTelling@thevillage.com> writes:
On 2026-May-08 14:12, MitchAlsup wrote:04Readings/I432.pdf
There was a CMU paper on 432 that stated if Intel had used 1 more pin
that performance could have <about> doubled.
It is still going to have to chew through gobs of microcode to do anything. >> I too had microcode on the brain back then. In 1976 I designed (but did not >> build) a microcoded cpu core using TTL AMD 2900 bit-slice components.
Lately I have been playing around with circa 1975 TTL paper cpu designs but >> done in a pipelined risc style. The instructions must be variable length because
memory was so expensive in 1975. The key is to not bottleneck in Fetch or Decode.
Last month I designed a TTL fetch-parse unit for a risc-ish pipeline using the same
parts as are on the VAX-780 bill of materials or in the 1976 TI logic data book.
The instructions are byte granular, variable length from 1 to 12 bytes long. >> That is long enough to hold a 4 byte instruction specifier (opcode + registers)
plus 8 bytes of immediate data. I expect the average instruction to be ~3 bytes.
My fetch unit paper design reads an 8-byte fetch block each clock
into a 32 byte circular prefetch buffer. The parser rotates the whole
32 byte buffer to align the instruction start with the length parser,
and a PLA examines the first 12 instructon bits to get the length.
It then validates that all the bytes are present in the buffer
and passes the 1 to 12 bytes + IP virtual address to the Decoder board.
This can do a sustained 5 MHz parse of 1 variable instruction/clock,
provided it hits the instruction cache. As most instructions are simple
and take 1 clock to execute, it should do sustained 5 MIPS.
Remember the 780 was 5 MHz but only executes at 0.5 MIPS.
It might also fit onto the same size PCB as the 780 used, about 15" x 15", >> but requires more edge connector pins for more buses (~300).
On a separate board Decode will store the fetched instruction and
feed it through a bank of PLA chips, which controls tri-state buffers
to route signals into the Decode uOp output register.
If built my Fetch and Decode units could run 10x the speed of a 780,
using the exact same parts but just designed from a non-microcode
point of view.
At what relative cost differential, i.e. what would a VAX-11/780
have cost if it had been built using your design?
EricP <ThatWouldBeTelling@thevillage.com> writes:
[reformatted to fit in 80-char lines with some slack for quote levels]
Lately I have been playing around with circa 1975 TTL paper cpu
designs but done in a pipelined risc style. The instructions must be
variable length because memory was so expensive in 1975. The key is
to not bottleneck in Fetch or Decode.
Cool!
Last month I designed a TTL fetch-parse unit for a risc-ish pipeline
using the same parts as are on the VAX-780 bill of materials or in
the 1976 TI logic data book.
The instructions are byte granular, variable length from 1 to 12
bytes long. That is long enough to hold a 4 byte instruction
specifier (opcode + registers) plus 8 bytes of immediate data. I
expect the average instruction to be ~3 bytes.
Interesting that you got this to work at 1 IPC. And, as the Skymont
shows, with enough resources such an instruction set can be made to
work at 9 IPC (the decoders of the Skymont are 3x3 wide, the renamer
is 8 wide).
Still, the question is how much, if any, code density advantage this
provides over something like RV32GC. In any case, given that RV32GC
code is smaller then VAX code
<2025Mar4.093916@mips.complang.tuwien.ac.at>, the code density of
RV32GC should be good enough, and the decoder may then need less
circuitry. I expect that your approach also gives some advantage in work/instruction, especially over RISC-V.
- anton
I don't know what 780 used for its integer multiplier
(I can't find it in the schematics).
On 2026-May-09 13:07, Anton Ertl wrote:
Interesting that you got this to work at 1 IPC. And, as the Skymont
shows, with enough resources such an instruction set can be made to
work at 9 IPC (the decoders of the Skymont are 3x3 wide, the renamer
is 8 wide).
The design is for the Fetch and Decode stages, and it is a paper design.
But those two stages each fit in a single pcb and would run at 1 IPC.
Still, the question is how much, if any, code density advantage this
provides over something like RV32GC. In any case, given that RV32GC
code is smaller then VAX code
<2025Mar4.093916@mips.complang.tuwien.ac.at>, the code density of
RV32GC should be good enough, and the decoder may then need less
circuitry. I expect that your approach also gives some advantage in
work/instruction, especially over RISC-V.
- anton
The high usage integer operate instructions fit have a 12b opcode
and 3 x 4b register fields. A 4B instruction would waste 1B each.
In 1975 memory was so expensive I didn't think that would go
down well with customers.
Also having immediate values avoids
all the risc constant pasting instructions.
On 2026-May-08 17:21, Scott Lurndal wrote:[...]
At what relative cost differential, i.e. what would a VAX-11/780Just eyeballing it, I'd say about the same.
have cost if it had been built using your design?
I also need way more than 240 pcb edge connector pins because
there are many more buses operating concurrently.
350 or so would be nice.
So, the question comes down to how much would it cost to increase the
240 pins to, say, 360.
[ My gut feeling is that it could be (have been) fairly expensive. ]
EricP [2026-05-10 08:59:27] wrote:
On 2026-May-08 17:21, Scott Lurndal wrote:[...]
At what relative cost differential, i.e. what would a VAX-11/780Just eyeballing it, I'd say about the same.
have cost if it had been built using your design?
I also need way more than 240 pcb edge connector pins because
there are many more buses operating concurrently.
350 or so would be nice.
So, the question comes down to how much would it cost to increase the
240 pins to, say, 360.
[ My gut feeling is that it could be (have been) fairly expensive. ]
=== Stefan
On 2026-May-10 16:23, Stefan Monnier wrote:I've seen those both on EPROMs and CPUs, quite nice actually.
EricP [2026-05-10 08:59:27] wrote:
On 2026-May-08 17:21, Scott Lurndal wrote:[...]
At what relative cost differential, i.e. what would a VAX-11/780Just eyeballing it, I'd say about the same.
have cost if it had been built using your design?
I also need way more than 240 pcb edge connector pins because
there are many more buses operating concurrently.
350 or so would be nice.
So, the question comes down to how much would it cost to increase the
240 pins to, say, 360.
[ My gut feeling is that it could be (have been) fairly expensive.-a ]
=== Stefan
Yes, that's why I mention it.
The problem is that as the # of pins goes up, so does the insertion friction.
At some point, which I don't know, the insertion force is high enough that
it can exceed the crush strength of the connector contact.
The contact gets crushed into the bottom of the connector and it is
useless.
On a bus like a PC bus where a card can go in any slot,
you would (hopefully) just move to another slot.
But on a backplane design like the 780 where cards must go in
specific slots, you just trashed your whole backplane and now
have to disassemble the machine to replace it.
There are connectors called Zero Insertion Force connectors
where you put the card in, then twist a screw or something and
the connector closes like a clamp on the card contacts.
On Wed, 06 May 2026 18:58:00 +0100, John Dallman wrote:
They abandoned x86SWhich I thought was a _good_ idea, not a bad one. Because upwards compatibility with the huge pool of software out there is the only
excuse for sticking with x86.
Stefan Monnier <monnier@iro.umontreal.ca> writes:
So, the question comes down to how much would it cost to increase the
240 pins to, say, 360.
[ My gut feeling is that it could be (have been) fairly expensive. ]
I am not an expert, but it seems to me that 120 extra pins on the
inter-board connectors would cost about as much as 120 pins of regular (socketed) chips per board. So if EricP can eliminate that many chips
or maybe a board, the cost should be the same. If not, it would be a
few percent higher. In absolute numbers, I expect that the increase
in cost would be <$1000.
The other question, of course, is, how much DEC could have charged for--- Synchronet 3.22a-Linux NewsLink 1.2
a machine that is 10x faster than a VAX 11/780. I guess that they
could easily have recouped the additional cost, if any.
- anton
EricP <ThatWouldBeTelling@thevillage.com> schrieb:
Lately I have been playing around with circa 1975 TTL paper cpu designs but >> done in a pipelined risc style. The instructions must be variable length because
memory was so expensive in 1975. The key is to not bottleneck in Fetch or Decode.
Last month I designed a TTL fetch-parse unit for a risc-ish pipeline using the same
parts as are on the VAX-780 bill of materials or in the 1976 TI logic data book.
The instructions are byte granular, variable length from 1 to 12 bytes long. >> That is long enough to hold a 4 byte instruction specifier (opcode + registers)
plus 8 bytes of immediate data. I expect the average instruction to be ~3 bytes.
That is quite impressive.
Could you share some details of the ISA, number of registers, what
do you use your 1-byte opcode for etc?
My fetch unit paper design reads an 8-byte fetch block each clock
into a 32 byte circular prefetch buffer. The parser rotates the whole
32 byte buffer to align the instruction start with the length parser,
and a PLA examines the first 12 instructon bits to get the length.
It then validates that all the bytes are present in the buffer
and passes the 1 to 12 bytes + IP virtual address to the Decoder board.
This can do a sustained 5 MHz parse of 1 variable instruction/clock,
provided it hits the instruction cache. As most instructions are simple
and take 1 clock to execute, it should do sustained 5 MIPS.
Remember the 780 was 5 MHz but only executes at 0.5 MIPS.
It might also fit onto the same size PCB as the 780 used, about 15" x 15", >> but requires more edge connector pins for more buses (~300).
On a separate board Decode will store the fetched instruction and
feed it through a bank of PLA chips, which controls tri-state buffers
to route signals into the Decode uOp output register.
If built my Fetch and Decode units could run 10x the speed of a 780,
using the exact same parts but just designed from a non-microcode
point of view.
On 2026-May-09 15:41, Thomas Koenig wrote:
EricP <ThatWouldBeTelling@thevillage.com> schrieb:
Lately I have been playing around with circa 1975 TTL paper cpu designs but
done in a pipelined risc style. The instructions must be variable length because
memory was so expensive in 1975. The key is to not bottleneck in Fetch or Decode.
Last month I designed a TTL fetch-parse unit for a risc-ish pipeline using the same
parts as are on the VAX-780 bill of materials or in the 1976 TI logic data book.
The instructions are byte granular, variable length from 1 to 12 bytes long.
That is long enough to hold a 4 byte instruction specifier (opcode + registers)
plus 8 bytes of immediate data. I expect the average instruction to be ~3 bytes.
That is quite impressive.
Could you share some details of the ISA, number of registers, what
do you use your 1-byte opcode for etc?
My fetch unit paper design reads an 8-byte fetch block each clock
into a 32 byte circular prefetch buffer. The parser rotates the whole
32 byte buffer to align the instruction start with the length parser,
and a PLA examines the first 12 instructon bits to get the length.
It then validates that all the bytes are present in the buffer
and passes the 1 to 12 bytes + IP virtual address to the Decoder board.
This can do a sustained 5 MHz parse of 1 variable instruction/clock,
provided it hits the instruction cache. As most instructions are simple
and take 1 clock to execute, it should do sustained 5 MIPS.
Remember the 780 was 5 MHz but only executes at 0.5 MIPS.
It might also fit onto the same size PCB as the 780 used, about 15" x 15", >> but requires more edge connector pins for more buses (~300).
On a separate board Decode will store the fetched instruction and
feed it through a bank of PLA chips, which controls tri-state buffers
to route signals into the Decode uOp output register.
If built my Fetch and Decode units could run 10x the speed of a 780,
using the exact same parts but just designed from a non-microcode
point of view.
To answer your second question first,
I have 3 instructions that must be sized at 1 instruction granule,
which in this case is 1 byte, as can occur on arbitrary boundary:
ILLG Illegal is opcode 0, causes an Illegal instruction fault
NOP No Operation
BRKP Breakpoint
ILLG is used pad non-executing space, NOP pads executing space,
BRKP can be deposited by a debugger at any instruction start.
Other instructions may be 1 granule, only these 3 must be.
The goal of my exercise was to see if Fetch and Decode units could
be designed with circa 1975 TTL that execute at 5 MHz getting 1 IPC.
The ISA is just a prototype to set some boundaries for the
Fetch and Decode designs have something fixed to shoot for.
The Fetch unit cares little what the internal format of an instruction is.
It only looks at most at the first up to 12 bits to determine length.
It only cares how many bytes are in the instruction and are they all
present in the prefetch register. If they are Fetch copies them to
the Decode input instruction register.
internal instruction of instructions and translates them into a uOp.
Provided Fetch and Decode meet there performance goal,
the instructions and their formats would be chosen such
that they are compatible with any limitations on those units.
The ISA is 32 bit integer and virtual address space.
Instruction Pointer register,
16 x 32b integer registers, 16 x 64b float registers.
No integer condition codes.
I wanted variable length instructions so it could have large immediates.
12 bytes was large enough to hold a 4B opcode and register numbers
with an 8B immediate that is either 1 fp64
or 2 int32 for compare and branch.
The Fetch unit parser uses a Signetics 82S100 FPLA to determine
the instruction length. The 82S100 has 16 inputs, 8 outputs,
and can match 48 product terms with 0, 1 or x dont-care bits.
The parser feeds the first 12 bits from the first 2 bytes plus
their 2 byte Valid flags and an error signal into the 82S100.
There is one input spare for future use.
The PLA outputs a 4b length from 0 to 12, plus 2 status bits
indicating the length is valid, or fetch unit stalled,
or fetch error, either page fault exception or HW error.
If the parse length is valid then fetch checks that all the
bytes of the instruction length are also valid.
If they are it passes the instruction to Decode input register.
To give an example, to encode the 3 1B instructions I define
(0 matches a 0, 1 matches a 1, x = a dont-care bit):
ILLG = bxxxx_0000_0000
NOP = bxxxx_1000_0000
BRKP = bxxxx_0100_0000
spare = bxxxx_1100_0000
Notice bits [5:0] of all are 0. So I define a PLA pattern
that matches that and spits out the length 1
11
1098_7654_3210
xxxx_xx00_0000 => 1
Now I want low usage frequency instructions like SYSENTER, SYSEXIT
that have no registers but I don't want to use up all my primary
byte code space so I continue in the second byte.
11So, Mil-like
1098_7654_3210
0000_0010_0000 => 2
Now I want 3 byte instructions for the high usage 3 operand instructions
like ADD, SUB, AND, OR, etc. with 3 x 4b register fields.
There are many of them, lets say 64 or 4 groups of 16.
11
1098_7654_3210
xxxx_xx01_0000 => 3
So all of the integer and float 3 register instructions begin
with the bits [5:0] = 01_0000, and bits [11:6] select individual instructions.
Now I go back and define exactly what those instructions are:
ADD Add Rd1 = Rs2 + Rs3
ADDFS Add fault signed overflow Rd1 = Rs2 + Rs3
ADDFU Add fault unsigned overflow Rd1 = Rs2 + Rs3
SUB Subtract Rd1 = Rs2 - Rs3
SUBFS Subtract fault signed overflow Rd1 = Rs2 - Rs3
SUBFU Subtract fault unsigned overflow Rd1 = Rs2 - Rs3
...
Now I'll do conditional branches.
Conditional branches need a 4b register to test,
a 3b condition code to test for (EZ = equal zero, NZ = not zero, ...)
and either a short byte or long 32b word offset.
But wait... a 12b opcode, 4b register and a 1B offset
is a 3B instruction so I can take all the short conditional
branches and merge them with the other 3B instruction groups.
That leaves long branches which have a 12b opcode, 4b register,
and 4B offset and a length of 6 bytes.
11
1098_7654_3210
xxx0_0011_0000 => 6
But wait... a 12b opcode, 4b register and 4B immediate is the
same length as an ADDIW add immediate word with a single
source-dest register. So I make the long branch group bigger
by moving the dont-care point:
11
1098_7654_3210
xxxx_x011_0000 => 6
and now define all those instructions.
And so on.
There are connectors called Zero Insertion Force connectors
where you put the card in, then twist a screw or something and
the connector closes like a clamp on the card contacts.
I did a quicky search to see if there were anything like what
I need, just to get the price, but could not find anything.
If they exist I imagine they are considerably more expensive
but each cpu only needs 25 of them.
If it had been "16-bit goes, all 32-bit stays, including operating
systems" they'd likely have got a lot more buy-in. But would that have
been a worthwhile simplification?
On Mon, 11 May 2026 15:34:00 +0100, John Dallman wrote:
If it had been "16-bit goes, all 32-bit stays, including operating
systems" they'd likely have got a lot more buy-in. But would that have
been a worthwhile simplification?
As far as I'm concerned, they made the same mistake with EM64T as they did >with the 80286. Not only should 16-bit stay, but they should have had it
so that 16-bit was as easily accessible from 64-bit as it was from 32-bit, >so as to retain all 16-bit software running perfectly and transparently in >64-bit editions of Windows.
EricP <ThatWouldBeTelling@thevillage.com> writes:
I don't know what 780 used for its integer multiplier
(I can't find it in the schematics).
Then I expect that it used microcode to do 1 multiplier bit per cycle.
IIRC that was the approach that SPARC took at first, and that was also designed into HPPA (but then they added the FPU and multiplied by
using the multiplier of the FPU).
- anton
On 2026-May-10 11:59, Anton Ertl wrote:
EricP <ThatWouldBeTelling@thevillage.com> writes:
I don't know what 780 used for its integer multiplier
(I can't find it in the schematics).
Then I expect that it used microcode to do 1 multiplier bit per cycle.
IIRC that was the approach that SPARC took at first, and that was also designed into HPPA (but then they added the FPU and multiplied by
using the multiplier of the FPU).
- anton
I think so. There is one line in the hardware manual that says
the optional FPU also "enhances the performance of integer multiply".
The FPU technical manual describes how the FPU does its multiplies.
It chops the values into 4b nibbles and looks up 4b x 4b values in ROMs
in a loop, and sums the partial products.
There are two sets of ROMs so it can interleave the lookups.
Note that there are TTL parts available in 1975 to build a
Wallace tree multiplier that can do 32b x 32b in ~130 ns.
From FP780_Technical_Description_1978-12
"In order to obtain fast multiplication, a pipeline technique is used (Figure 2-21 ).
The multiplier is divided into 4-bit nibbles. The nibbles are then accessed consecutively
by a counter-multiplexer combination (least significant nibble first) and each nibble
operates on up to 32 bits of multiplicand. The MCA ND bus and MPLIER nibbles are used to
address the ROMs. The banks of ROMs provide a 4 X 4 primitive with 2-way interleaving.
The data is latched (ROM.STORE) and applied to the inputs of 4-bit adders (PALU).
These adders combine the ROM data to form a partial product, storing the carryout
of each 4-bit section, to be added in on the next cycle. The partial product is latched
in PPROD and passed to another row of adders (AALU) which accumulate the final product,
again, saving the carries. Thus, when the pipeline is operating, there are four processes
cycling at the same time:
1. Select ROM addresses
2. Latch ROM data
3. Form partial product
4. Accumulate final product.
After the final product is calculated, the stored carriers from both stages are
combined with the accumulated product using full carry look-ahead to produce the
final answer in a single precision (float) operation. In double precision, this result is stored and used during the generation of the final answer during the second pass.
Each of the pipeline processes, with the exception of accessing ROM data (which occurs in each bank of ROMs on 100 ns) occurs at SO ns intervals."
EricP <ThatWouldBeTelling@thevillage.com> posted:
On 2026-May-10 11:59, Anton Ertl wrote:
EricP <ThatWouldBeTelling@thevillage.com> writes:
I don't know what 780 used for its integer multiplier
(I can't find it in the schematics).
Then I expect that it used microcode to do 1 multiplier bit per cycle.
IIRC that was the approach that SPARC took at first, and that was also
designed into HPPA (but then they added the FPU and multiplied by
using the multiplier of the FPU).
- anton
I think so. There is one line in the hardware manual that says
the optional FPU also "enhances the performance of integer multiply".
The FPU technical manual describes how the FPU does its multiplies.
It chops the values into 4b nibbles and looks up 4b x 4b values in ROMs
in a loop, and sums the partial products.
There are two sets of ROMs so it can interleave the lookups.
Note that there are TTL parts available in 1975 to build a
Wallace tree multiplier that can do 32b x 32b in ~130 ns.
s/Wallace/Dadda/
So, at 5MHz == 200ns this is probably a 2-cycle multiplier after
you add the input multiplexing and output selection.
As far as I'm concerned, they made the same mistake with EM64T as
they did with the 80286. Not only should 16-bit stay, but they
should have had it so that 16-bit was as easily accessible from
64-bit as it was from 32-bit, so as to retain all 16-bit software
running perfectly and transparently in 64-bit editions of Windows.
In article <10tvimf$22n8v$1@dont-email.me>, quadibloc@ca.invalid (quadi) >wrote:
As far as I'm concerned, they made the same mistake with EM64T as
they did with the 80286. Not only should 16-bit stay, but they
should have had it so that 16-bit was as easily accessible from
64-bit as it was from 32-bit, so as to retain all 16-bit software
running perfectly and transparently in 64-bit editions of Windows.
When x86-64 was released, AMD were at pains to point out that running
16-bit environments was possible. It was Microsoft who decided to drop
16-bit support from 64-bit Windows.
When x86-64 was released, AMD were at pains to point out that
running 16-bit environments was possible. It was Microsoft who
decided to drop 16-bit support from 64-bit Windows.
I think you need to cite a source for that.
The AMD64 Opterons did not support the segment limit registers
when released.
jgd@cix.co.uk (John Dallman) writes:
In article <10tvimf$22n8v$1@dont-email.me>, quadibloc@ca.invalid (quadi) >>wrote:
As far as I'm concerned, they made the same mistake with EM64T as
they did with the 80286. Not only should 16-bit stay, but they
should have had it so that 16-bit was as easily accessible from
64-bit as it was from 32-bit, so as to retain all 16-bit software
running perfectly and transparently in 64-bit editions of Windows.
When x86-64 was released, AMD were at pains to point out that running >>16-bit environments was possible. It was Microsoft who decided to drop >>16-bit support from 64-bit Windows.
I think you need to cite a source for that.
The AMD64 Opterons did not support the segment limit registers
when released.
Some incomplete support was added in the second generation of
Opteron because VMware and XEN had been using the segment limit registers for >virtualization (shadow page tables). The support was sufficient
to support XEN temporarily until the NPT (nested page table)
and Pacifica (SVM) features were added to the processor, but
it was not complete enough to support random 16-bit applications.
https://www.pagetable.com/?p=25
In article <iBNMR.2$2K1.1@fx17.iad>, scott@slp53.sl.home (Scott Lurndal) >wrote:
When x86-64 was released, AMD were at pains to point out that
running 16-bit environments was possible. It was Microsoft who
decided to drop 16-bit support from 64-bit Windows.
I think you need to cite a source for that.
The AMD64 Opterons did not support the segment limit registers
when released.
I suspect my informant may have been exaggerating, or I've mis-remembered.
scott@slp53.sl.home (Scott Lurndal) writes:
jgd@cix.co.uk (John Dallman) writes:
In article <10tvimf$22n8v$1@dont-email.me>, quadibloc@ca.invalid (quadi) >>wrote:
As far as I'm concerned, they made the same mistake with EM64T as
they did with the 80286. Not only should 16-bit stay, but they
should have had it so that 16-bit was as easily accessible from
64-bit as it was from 32-bit, so as to retain all 16-bit software
running perfectly and transparently in 64-bit editions of Windows.
When x86-64 was released, AMD were at pains to point out that running >>16-bit environments was possible. It was Microsoft who decided to drop >>16-bit support from 64-bit Windows.
I think you need to cite a source for that.
The AMD64 Opterons did not support the segment limit registers
when released.
When I bought my Athlon 64 in October 2003, no 64-bit OSs were readily available for it, and all the 32-bit and 16-bit stuff I used ran
nicely. For the game operating system, I always lagged behind, so
maybe I was at W98 when I switched the hardware, and IIRC W98 gave low
frame rates on the new hardware, so I switched to WME, or somesuch,
which fixed the problem. All the 32-bit and 16-bit stuff that was
still in WME worked on the Athlon 64 (which is the same
microarchitecture (K8) as the early Opterons).
If the segment limit registers were not supported, they obviously were
not needed.
But my guess is that you confuse this with the fact that the long mode (unlike legacy mode, in which the 32-bit OSs run) does not support
most segmentation features of IA-32, and that the FS and GS
segmentation registers it supports does so without limiting the
segment (so they are just base registers in long mode). But, as
mentioned, in legacy mode all segmentation is fully supported.
However, if you have an OS that runs in long mode (i.e., a 64-bit OS),
you cannot run real-mode programs (no real mode, virtual 8086 mode, or
unreal mode), only 16-bit protected mode according to <https://en.wikipedia.org/wiki/X86-64#Operating_modes>. So an OS
would have to switch to legacy mode to get to these modes. That page
also says:
|However, such [real mode] programs may be started from an operating
|system running in long mode on processors supporting VT-x or AMD-V by |creating a virtual processor running in the desired mode.
Some incomplete support was added in the second generation of
Opteron because VMware and XEN had been using the segment limit registers for
virtualization (shadow page tables). The support was sufficient
to support XEN temporarily until the NPT (nested page table)
and Pacifica (SVM) features were added to the processor, but
it was not complete enough to support random 16-bit applications.
https://www.pagetable.com/?p=25
|While VMware could still virtualize 32 bit operating systems on AMD64
|CPUs, they could not virtualize 64 bit operating systems, because they |required segment limits.
So it's not that the Opterons did not support any pre-existing
functionality (no earlier 64-bit OSs for AMD64 existed, because
Opteron was the first AMD64 processor), just that VMware could not use
the same virtualization technique for 64-bit OSs that they could use
for 32-bit OSs and had been using on earlier 32-bit processors and
that they could still use in legacy mode.
- anton--- Synchronet 3.22a-Linux NewsLink 1.2
In article <10tvimf$22n8v$1@dont-email.me>, quadibloc@ca.invalid (quadi) wrote:
As far as I'm concerned, they made the same mistake with EM64T as
they did with the 80286. Not only should 16-bit stay, but they
should have had it so that 16-bit was as easily accessible from
64-bit as it was from 32-bit, so as to retain all 16-bit software
running perfectly and transparently in 64-bit editions of Windows.
When x86-64 was released, AMD were at pains to point out that running
16-bit environments was possible. It was Microsoft who decided to drop
16-bit support from 64-bit Windows.
EricP <ThatWouldBeTelling@thevillage.com> posted:
On 2026-May-09 15:41, Thomas Koenig wrote:
EricP <ThatWouldBeTelling@thevillage.com> schrieb:
Lately I have been playing around with circa 1975 TTL paper cpu designs but
done in a pipelined risc style. The instructions must be variable length because
memory was so expensive in 1975. The key is to not bottleneck in Fetch or Decode.
Last month I designed a TTL fetch-parse unit for a risc-ish pipeline using the same
parts as are on the VAX-780 bill of materials or in the 1976 TI logic data book.
The Fetch unit cares little what the internal format of an instruction is. >> It only looks at most at the first up to 12 bits to determine length.
It only cares how many bytes are in the instruction and are they all
present in the prefetch register. If they are Fetch copies them to
the Decode input instruction register.
This is the stage I call PARSE. Fetch is responsible for presenting
cache sub-lines to PARSE, PARSE slices instructions out of the words
and presenting parsed instructions to multiple parallel DECODE units.
The Fetch unit parser uses a Signetics 82S100 FPLA to determine
the instruction length. The 82S100 has 16 inputs, 8 outputs,
and can match 48 product terms with 0, 1 or x dont-care bits.
The parser feeds the first 12 bits from the first 2 bytes plus
their 2 byte Valid flags and an error signal into the 82S100.
There is one input spare for future use.
The PLA outputs a 4b length from 0 to 12, plus 2 status bits
indicating the length is valid, or fetch unit stalled,
or fetch error, either page fault exception or HW error.
If the parse length is valid then fetch checks that all the
bytes of the instruction length are also valid.
If they are it passes the instruction to Decode input register.
I should mention that the DECODE unit of Mc 88100 was a siingle
NOR plane {while a PLA is 2 NOR planes}.
EricP <ThatWouldBeTelling@thevillage.com> posted:
On 2026-May-10 11:59, Anton Ertl wrote:
EricP <ThatWouldBeTelling@thevillage.com> writes:
I don't know what 780 used for its integer multiplier
(I can't find it in the schematics).
Then I expect that it used microcode to do 1 multiplier bit per cycle.
IIRC that was the approach that SPARC took at first, and that was also
designed into HPPA (but then they added the FPU and multiplied by
using the multiplier of the FPU).
- anton
I think so. There is one line in the hardware manual that says
the optional FPU also "enhances the performance of integer multiply".
The FPU technical manual describes how the FPU does its multiplies.
It chops the values into 4b nibbles and looks up 4b x 4b values in ROMs
in a loop, and sums the partial products.
There are two sets of ROMs so it can interleave the lookups.
Note that there are TTL parts available in 1975 to build a
Wallace tree multiplier that can do 32b x 32b in ~130 ns.
s/Wallace/Dadda/
So, at 5MHz == 200ns this is probably a 2-cycle multiplier after
you add the input multiplexing and output selection.
MitchAlsup <user5857@newsgrouper.org.invalid> schrieb:
EricP <ThatWouldBeTelling@thevillage.com> posted:
On 2026-May-10 11:59, Anton Ertl wrote:
EricP <ThatWouldBeTelling@thevillage.com> writes:
I don't know what 780 used for its integer multiplier
(I can't find it in the schematics).
Then I expect that it used microcode to do 1 multiplier bit per cycle. >>>> IIRC that was the approach that SPARC took at first, and that was also >>>> designed into HPPA (but then they added the FPU and multiplied by
using the multiplier of the FPU).
- anton
I think so. There is one line in the hardware manual that says
the optional FPU also "enhances the performance of integer multiply".
The FPU technical manual describes how the FPU does its multiplies.
It chops the values into 4b nibbles and looks up 4b x 4b values in ROMs
in a loop, and sums the partial products.
There are two sets of ROMs so it can interleave the lookups.
Note that there are TTL parts available in 1975 to build a
Wallace tree multiplier that can do 32b x 32b in ~130 ns.
130 ns? That sounds quite fast. Do you happen to have details
of such a design?
s/Wallace/Dadda/
So, at 5MHz == 200ns this is probably a 2-cycle multiplier after
you add the input multiplexing and output selection.
But that is only for mutiplying two nibbles with 32 bits.
By using 64 74S274 and a corresponding number of 74S275, 74S183 and
74S283 (full adders for the corners and for speeding up incoming
carries) plus a carry lookahead cascade of 74S181 and 74S182, it
would have been probably quite possible to build a two-cycle 32*32
multiplier for a VAX-like comptuter on two boards (each of which
can hold around 120 chips), pipelined for one result per cycle.
It is also interesting that they chose ROMs instead of 74S274s
with the same function, probably due to price or power.
When I bought my Athlon 64 in October 2003, no 64-bit OSs were readily available for it, and all the 32-bit and 16-bit stuff I used ran nicely.
Given that Dosemu runs much faster in emulation than on the original hardware, that is not such a big loss.
On 2026-May-15 09:54, Thomas Koenig wrote:^^^^^^^^^
130 ns? That sounds quite fast. Do you happen to have details
of such a design?
I thought so too but it says (the 74LS times are in () )
"When SN74S274 is Combined With SN74H183
(or SN74LS183) and Schottky Look-Ahead
Adders, Multiplication Times are Typically:
16-Bit Product in 75 ns (79 ns)
32-Bit Product in 116 ns (132 ns)"
Starting at page 7-391, after technical specs it
shows a number of example configurations.
54/74 Family MSI/LSI Circuits 1976
Manual is page indexed and searchable https://www.bitsavers.org/components/ti/_dataBooks/1976_TI_The_TTL_Data_Book_2ed/07.pdf
On Thu, 14 May 2026 21:10:32 +0000, Thomas Koenig wrote:
Given that Dosemu runs much faster in emulation than on the original
hardware, that is not such a big loss.
That is not the right comparison. If my old 16-bit software doesn't run at full *native* speed on my shiny new 64-bit computer, then I still have to run out and buy new software to get my work done faster.
Although it is correct to say that Microsoft could have done something to fix this, even with the hardware issue as it is. They could have let
people buy just one copy of Windows, and install it twice on the same computer - so as to be able to boot into either the 32-bit version or the 64-bit version.
quadi <quadibloc@ca.invalid> schrieb:
On Thu, 14 May 2026 21:10:32 +0000, Thomas Koenig wrote:
Given that Dosemu runs much faster in emulation than on the original
hardware, that is not such a big loss.
That is not the right comparison. If my old 16-bit software doesn't run at full *native* speed on my shiny new 64-bit computer, then I still have to run out and buy new software to get my work done faster.
At work, I actually use a 16-bit MS-DOS program, which was written
in the early 1990s. Originally, it had run 15-20 minutes; now it
runs in far less than 10 seconds (I never timed it, it is fast).
A newer 64-bit version is available, but I actually don't use it
because the old one works well, and I'm simply too lazy to learn
the new qirks, when I am quite used to the old quirks. It may also
be faster by a factor of 5, I don't care.
By comparison: It takes ages for for me to open an Excel file,
and whenever I change something in a certain complex Excel file,
like moing around a text box in a graph, it decides to recalculate,
taking maybe 30 seconds for me to see that the text box is not
where it should be. (And yes, I have switched off calculation, but
graphics doesn't care).
Although it is correct to say that Microsoft could have done something to fix this, even with the hardware issue as it is. They could have let people buy just one copy of Windows, and install it twice on the same computer - so as to be able to boot into either the 32-bit version or the 64-bit version.
Haha.
Forcing people to ditch their own computers because they are not
Windows 11 compatible is the Microsoft way.
Thomas Koenig <tkoenig@netcologne.de> posted:
quadi <quadibloc@ca.invalid> schrieb:
On Thu, 14 May 2026 21:10:32 +0000, Thomas Koenig wrote:
Given that Dosemu runs much faster in emulation than on the original
hardware, that is not such a big loss.
That is not the right comparison. If my old 16-bit software doesn't run at
full *native* speed on my shiny new 64-bit computer, then I still have to >> > run out and buy new software to get my work done faster.
At work, I actually use a 16-bit MS-DOS program, which was written
in the early 1990s. Originally, it had run 15-20 minutes; now it
runs in far less than 10 seconds (I never timed it, it is fast).
A newer 64-bit version is available, but I actually don't use it
because the old one works well, and I'm simply too lazy to learn
the new qirks, when I am quite used to the old quirks. It may also
be faster by a factor of 5, I don't care.
I have an automobile engine simulator* written in eXcel. When run on
my 33 MHz 486, I had time to get up from my chair, walk to the kitchen,
open the fridge, grab a beer, walk back, and the calculations were just finishing. When I got a 200 MHz Pentium Pro the same calculations took
a blink of an eye.
(*) 15 spread sheets, more than 10,000 equations somewhere around
10% of them using SQRT(), SIN(), COS(), EXP(), and LOG().
By comparison: It takes ages for for me to open an Excel file,
and whenever I change something in a certain complex Excel file,
like moing around a text box in a graph, it decides to recalculate,
You can (CAN) turn off automatic recalculation...
taking maybe 30 seconds for me to see that the text box is not
where it should be. (And yes, I have switched off calculation, but
graphics doesn't care).
Although it is correct to say that Microsoft could have done something to >> > fix this, even with the hardware issue as it is. They could have let
people buy just one copy of Windows, and install it twice on the same
computer - so as to be able to boot into either the 32-bit version or the >> > 64-bit version.
Haha.
Forcing people to ditch their own computers because they are not
Windows 11 compatible is the Microsoft way.
With Intel and AMD support.
On Wed, 13 May 2026 18:07:41 +0000, Anton Ertl wrote:
When I bought my Athlon 64 in October 2003, no 64-bit OSs were readily
available for it, and all the 32-bit and 16-bit stuff I used ran nicely.
Yes. You can run 32-bit Windows 7 on a 64-bit CPU in 32-bit mode, and 16-
bit programs will run just as well.
But apparently without rebooting to get into 32-bit mode, there really is
a hardware reason why 16-bit software can't easily be made to work from 64- bit mode. Whatever the hardware reason is, in my opinion that's a mistake
on the part of the hardware designers.
John Savard
Headers are nothing more than mode-bits that change every block of code.
This means that ISA will be exceptionally difficult to verify, and as
you have found: very difficult to encode.
| Sysop: | Amessyroom |
|---|---|
| Location: | Fayetteville, NC |
| Users: | 65 |
| Nodes: | 6 (0 / 6) |
| Uptime: | 01:48:29 |
| Calls: | 862 |
| Files: | 1,311 |
| D/L today: |
10 files (20,373K bytes) |
| Messages: | 264,321 |
