From Newsgroup: comp.arch

While Concertina IV seemed to have achieved my goals, without
resorting to block structure, as best as would be possible... I was
still deeply dissatisfied.
The short instructions were profoundly inadequate.
And the basic structure of the instruction set, the length indications
of the instructions, was so messy as to kill whatever slight, meagre
chance the design would have of interest or adoption.
Could I make the design more symmetrical, more straightforward,
without sacrificing the efficiency in terms of code compactness I had
so laboriously fought my way to achieve?
Well, I have thought of something.
Let 3/4 of the opcode space be given to a basic set of 32-bit
instructions.
Everything else that starts with the two bits 11 is longer than 32
bits, and begins with an eight bit prefix of the form:

11
(3 bits) length
(3 bits) type

Length 0 is 64 bits, length 1 is 96 bits, and so on, the lengths being multiples of 32 bits.

The different type values allow different kinds of blocks, such as:

An instruction with multiple 18-bit short instructions embedded. The
64-bit one would have three; the 96 bit one would have four, and each additional 32 bits would add two more short instructions.

An instruction with immediate data that is 32, 64, or 128 bits long.

An instruction with one or more 40-bit instructions embedded; the
first 32 bits would contain up to seven 8-bit prefixes, and there
could be from one to seven additional 32-bit extents.

An instruction with one or more 56-bit instructions embedded; all
64-bit extents except the first would have eight unused bits.

In this way, the instruction set would have some appearance of being well-organized instead of chaotically messy.

This, at least, is the basic concept. More may be needed. 88-bit
instructions taking up 96-bit spaces. A large instruction type with
embedded VLIW capabilities. A large instruction starting with an
embedded 24-bit instruction, followed by 32-bit instructions, with the distinguishing feature that it can't be a branch target.

Will there be any way for me to cope with 16-bit or 48-bit immediates
except by wasting 16 unused bits?

John Savard
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.arch

On 6/28/2026 12:41 AM, John Savard wrote:

While Concertina IV seemed to have achieved my goals, without
resorting to block structure, as best as would be possible... I was
still deeply dissatisfied.
The short instructions were profoundly inadequate.
And the basic structure of the instruction set, the length indications
of the instructions, was so messy as to kill whatever slight, meagre
chance the design would have of interest or adoption.
Could I make the design more symmetrical, more straightforward,
without sacrificing the efficiency in terms of code compactness I had
so laboriously fought my way to achieve?
Well, I have thought of something.
Let 3/4 of the opcode space be given to a basic set of 32-bit
instructions.
Everything else that starts with the two bits 11 is longer than 32
bits, and begins with an eight bit prefix of the form:

11
(3 bits) length
(3 bits) type

Length 0 is 64 bits, length 1 is 96 bits, and so on, the lengths being multiples of 32 bits.

The different type values allow different kinds of blocks, such as:

An instruction with multiple 18-bit short instructions embedded. The
64-bit one would have three;

So you take 64 bits to encode three 18 bit instructions, and "waste" 10
bits or over 15% of the space! This doesn't seem efficient.

the 96 bit one would have four,

Wasting 25% - even worse!

and each
additional 32 bits would add two more short instructions.

An instruction with immediate data that is 32, 64, or 128 bits long.

An instruction with one or more 40-bit instructions embedded; the
first 32 bits would contain up to seven 8-bit prefixes,

How are you going to fit "seven 8 bit prefixes" which takes 7*8=56 bits
in the first 32 bits?
--
- Stephen Fuld
(e-mail address disguised to prevent spam)
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.arch


quadibloc@invalid.com (John Savard) posted:

While Concertina IV seemed to have achieved my goals, without
resorting to block structure, as best as would be possible... I was
still deeply dissatisfied.

So have "we".

The short instructions were profoundly inadequate.

Most find this.

And the basic structure of the instruction set, the length indications
of the instructions, was so messy as to kill whatever slight, meagre
chance the design would have of interest or adoption.

Could I make the design more symmetrical, more straightforward,
without sacrificing the efficiency in terms of code compactness I had
so laboriously fought my way to achieve?
Well, I have thought of something.
Let 3/4 of the opcode space be given to a basic set of 32-bit
instructions.

Why even go that far:: My 66000 reserves only 1/8th of opcodes for "potentially" longer than 32-bits--these can have long constants,
but don't have to.

Everything else that starts with the two bits 11 is longer than 32
bits, and begins with an eight bit prefix of the form:

11
(3 bits) length
(3 bits) type

Sounds expensive--whereas My 66000 uses 4-bits in that 1/8th OpCode
space to denote Operand Routing. Operand Routing supplies {negation,
inversion, -#5-bit immediates, 32-bit and 64-bit constants.}

Length 0 is 64 bits, length 1 is 96 bits, and so on, the lengths being multiples of 32 bits.

The different type values allow different kinds of blocks,

Which we fount so useful in Concertina II--Oh wait !

such as:

An instruction with multiple 18-bit short instructions embedded. The
64-bit one would have three; the 96 bit one would have four, and each additional 32 bits would add two more short instructions.

An instruction with immediate data that is 32, 64, or 128 bits long.

Nothing in My 66000 (now) is longer than 96-bits.

An instruction with one or more 40-bit instructions embedded; the
first 32 bits would contain up to seven 8-bit prefixes, and there
could be from one to seven additional 32-bit extents.

An instruction with one or more 56-bit instructions embedded; all
64-bit extents except the first would have eight unused bits.

In this way, the instruction set would have some appearance of being well-organized instead of chaotically messy.

Trying to replace George Carlin??

This, at least, is the basic concept. More may be needed. 88-bit
instructions taking up 96-bit spaces. A large instruction type with
embedded VLIW capabilities. A large instruction starting with an
embedded 24-bit instruction, followed by 32-bit instructions, with the distinguishing feature that it can't be a branch target.

Will there be any way for me to cope with 16-bit or 48-bit immediates
except by wasting 16 unused bits?

John Savard

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.arch

On Sun, 28 Jun 2026 09:26:40 -0700, Stephen Fuld
<sfuld@alumni.cmu.edu.invalid> wrote:

So you take 64 bits to encode three 18 bit instructions, and "waste" 10
bits or over 15% of the space! This doesn't seem efficient.

Wasting 25% - even worse!

You're quite right. But given my experience with going around in
circles with many previous iterations of Concertina II and later, I
came to the conclusion that seeking the absolute maximum of efficiency
was chimeric, and I had to give the ISA some semblance of order and
regularity for it to have any hope of acceptance.

How are you going to fit "seven 8 bit prefixes" which takes 7*8=56 bits
in the first 32 bits?

Oops. Obviously, three eight-bit prefixes in the first 32 bits, or, if
I have more 40-bit instructions in a group, up to seven eight-bit
prefixes in the first 64 bits.

John Savard
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.arch

On Sun, 28 Jun 2026 20:07:34 GMT, MitchAlsup
<user5857@newsgrouper.org.invalid> wrote:

quadibloc@invalid.com (John Savard) posted:

In this way, the instruction set would have some appearance of being
well-organized instead of chaotically messy.

Trying to replace George Carlin??

If you had referred to Rodney Dangerfield, I might have gotten the
joke.

John Savard
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.arch


quadibloc@invalid.com (John Savard) posted:

On Sun, 28 Jun 2026 09:26:40 -0700, Stephen Fuld <sfuld@alumni.cmu.edu.invalid> wrote:

So you take 64 bits to encode three 18 bit instructions, and "waste" 10 >bits or over 15% of the space! This doesn't seem efficient.

Wasting 25% - even worse!

You're quite right. But given my experience with going around in
circles with many previous iterations of Concertina II and later,

You seem to have a patent on "going around in circles".

I
came to the conclusion that seeking the absolute maximum of efficiency
was chimeric, and I had to give the ISA some semblance of order and regularity for it to have any hope of acceptance.

How are you going to fit "seven 8 bit prefixes" which takes 7*8=56 bits
in the first 32 bits?

Oops. Obviously, three eight-bit prefixes in the first 32 bits, or, if
I have more 40-bit instructions in a group, up to seven eight-bit
prefixes in the first 64 bits.

John Savard

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.arch


quadibloc@invalid.com (John Savard) posted:

On Sun, 28 Jun 2026 20:07:34 GMT, MitchAlsup <user5857@newsgrouper.org.invalid> wrote:

quadibloc@invalid.com (John Savard) posted:

In this way, the instruction set would have some appearance of being
well-organized instead of chaotically messy.

Trying to replace George Carlin??

If you had referred to Rodney Dangerfield, I might have gotten the
joke.

I never considered Rodney funny.

John Savard

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.arch

On Mon, 29 Jun 2026 17:41:20 GMT, MitchAlsup
<user5857@newsgrouper.org.invalid> wrote:

You seem to have a patent on "going around in circles".

I can't take credit for the invention of the wheel; that existed
before I was born.

I keep hoping, though, that I am, however slowly, getting closer to my poorly-defined goal, to finally reach a point that I can settle on,
and move forwards from.

I have now started to post the pages for this new iteration online.
The former Concertina III and Concertina IV have been removed, and
instead of being Concertina V, this more organized scheme has become
the new Concertina III.

So the Concertina II with block structure has been retained, as block
structure does allow greater space efficiency compared to having each instruction indicate its length.

John Savard
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.arch

John Savard <quadibloc@invalid.com> schrieb:

On Mon, 29 Jun 2026 17:41:20 GMT, MitchAlsup
<user5857@newsgrouper.org.invalid> wrote:

You seem to have a patent on "going around in circles".

I can't take credit for the invention of the wheel; that existed
before I was born.

Really? I would have guessed you were born before 2001.

See https://patents.google.com/patent/AU2001100012A4/en?oq=AU2001100012
where somebody patented a "Circular transportation facilitation device".

So the Concertina II with block structure has been retained, as block structure does allow greater space efficiency compared to having each instruction indicate its length.

Again, grouping instructions will make the job of a compiler or
assembler very close to impossible.
--
This USENET posting was made without artificial intelligence,
artificial impertinence, artificial arrogance, artificial stupidity,
artificial flavorings or artificial colorants.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.arch


quadibloc@invalid.com (John Savard) posted:

On Mon, 29 Jun 2026 17:41:20 GMT, MitchAlsup <user5857@newsgrouper.org.invalid> wrote:

You seem to have a patent on "going around in circles".

I can't take credit for the invention of the wheel; that existed
before I was born.

I keep hoping, though, that I am, however slowly, getting closer to my poorly-defined goal, to finally reach a point that I can settle on,
and move forwards from.

I have now started to post the pages for this new iteration online.
The former Concertina III and Concertina IV have been removed, and
instead of being Concertina V, this more organized scheme has become
the new Concertina III.

I see, maximizing confusion.

So the Concertina II with block structure has been retained, as block structure does allow greater space efficiency compared to having each instruction indicate its length.

John Savard

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.arch

On 6/29/2026 12:41 PM, MitchAlsup wrote:

quadibloc@invalid.com (John Savard) posted:

On Sun, 28 Jun 2026 09:26:40 -0700, Stephen Fuld
<sfuld@alumni.cmu.edu.invalid> wrote:

So you take 64 bits to encode three 18 bit instructions, and "waste" 10
bits or over 15% of the space! This doesn't seem efficient.

Wasting 25% - even worse!

You're quite right. But given my experience with going around in
circles with many previous iterations of Concertina II and later,

You seem to have a patent on "going around in circles".

Yeah, agreed, the faff seemingly doesn't go anywhere...


I am ending up with an ISA that tends to fragment, but mostly does seem
to have a trajectory, and reasons.

XG1 -> XG2:
Drop the 16-bit ops to expand GPRs to 6 bits;
Convoluted encoding scheme such that there existed a common subset.

XG2 -> XG3:
Repack to fit into the same encoding space as RV64G;
Some initial tweaks to "un-dog-chew" some of the encodings;
Some divergences that have increased over time.


I had considered the possibility of doing a soft-reboot of the CPU core,
but thus far this is looking mostly like dropping XG1 and XG2 to focus
more narrowly on XG3.


Did recently start working on a new compiler (mostly focusing on GLSL
for now), and in the process some sharp corner cases in XG3 still did
come up.

One issue that I didn't address in my last breaking change was the inconsistencies of the compare instructions. I may need to address this
at some point.


Could add some new ones with a more consistent scheme, but would then
end up deprecating the old ones, and presumably needing to remove them
at some point. And it is annoying to have a situation where the same instruction exists in multiple places in the ISA.


Would want, say:
Compare instructions to be consistent between 3R and 3RI-Imm6 forms, and between signed and unsigned. Can patch around it in the assembler, but
yeah (went and did a listing-driven assembler for the new compiler, and
the hair is much more obvious in this case).

Still better IMHO than RV64G, which as like "Well, how about just having
SLT and SLTU?", so every other case needs multiple ops.

Granted, SLT has a bigger baseline Imm form (Imm6 is lacking, only able
to encode -32..31). But, not heavily used enough to justify larger
immediate (even if they could be nicer and more useful if the immediate
forms could natively cover ASCII range).

In a listing-driven assembler, places where one has to add special cases
to deal with ISA quirks is a lot more obvious.



Well, and for the GLSL compiler sub-project:
AST format: cons lists with 16-bit tagrefs;
xxx0: Cons cell
xx01: External Obj (escape to 64-bit tagref)
0011: Symbol
1011: Keyword
0111: Fixnum
1111: -
Tokenizer/Parser: Derived from my 2.5 kLOC mimi JS insterpreter.
GLSL mostly similar enough to JavaScript syntax-wise.
Mostly just needs the vaguely C-like declaration syntax.
Type system is much simpler than C in some areas.
No pointers, function pointers, multidimensional arrays, ...
Could maybe extend to have pointer types, like a C lite, TBD.
Assembler:
Listing-driven design in this case;
Generates structs for now representing object files.
TBD how shader linking works, or deals with GL shader parameters.
Possible that shader dictates the layout of the uniforms/varying.
Since, one needs to bind shader before giving parameters.
Register allocator:
This time just uses a linear 1:1 mapping to the register space;
May handle static-assignment more as "pinned" registers;
General strategy will resemble that used in BGBCC.
Though, for now, uses an oldest-first eviction strategy.
No lifetime analysis/etc, just evict the oldest variable.
No SSA for now.
ABI:
Similar to the XG3 extended ABI;
X10..X17: First 8 arguments;
F10..F17: Next 8 arguments;
X8/X9, X18..X27, F4..F9, F18..F27: Callee Save
But:
Only register arguments (hard limit of 16 arguments).
Will re-add the use of stack-based spill space (128B).
Where:
All integer types passed as natively extended to 64 bits;
All scalar floating point types passed as Binary64;
128-bit Vectors passed in even-numbered registers;
Matrix types would need to be passed/returned by reference.
Though, mat2 could be fit into registers, it is rarely used.

Still TBD:
Whether I am going to need to add a 3AC IR stage, or if compiler can be
driven purely by ASTs.

Though, for now, the likely strategy is to make several passes over the function bodies:
First: Gathers up local variables and similar;
Second: Figures out which registers to reserve;
Third: Generate the code.
Sorta workable, luckily GLSL doesn't have nested functions or lambdas.

Goal here being to limit both memory footprint and code complexity.


There may need to be a runtime library of sorts, either as ASM or as
calls out into C land.

TKRA-GL runs in kernel space as XG1 for now, which does make an
annoyance for calls into native land. May make sense to keep the runtime internal to the shader space (maybe compile the runtime as a shader).
May need either a textual assembler, or a more C like superset, to deal
with this. But, TUs would need to be kept small due to the 32K cons-cell limit.


Why GLSL:
May make sense for TKRA-GL to be able to start expanding into OpenGL 2.x functionality, which will require a GLSL compiler. Granted, any shaders
would necessarily run in CPU space. It is unclear if shader driven
rendering will be all that practical either way.

I might also need to rework part of how the front-end stages work, which
may be related to figuring out how to best deal with shader "varying" parameters.

But, dunno... A 50MHz core isn't exactly going to be a shader powerhouse
in any case.



Then again, recently saw a video where they were talking to some guys
from "Bolt" who are apparently building GPUs from RV cores (though using RV-V). Ironically their claims are that they do good for raytracing, but
kinda suck for raster rendering.

I guess I could maybe experiment with raytracing as well (can't expect
much).

Almost kinda funny though that they are doing GPUs of sorts, and
actually using them for 3D rendering, as opposed to just going off and promptly chasing the LLM/AI thing...

I
came to the conclusion that seeking the absolute maximum of efficiency
was chimeric, and I had to give the ISA some semblance of order and
regularity for it to have any hope of acceptance.

How are you going to fit "seven 8 bit prefixes" which takes 7*8=56 bits
in the first 32 bits?

Oops. Obviously, three eight-bit prefixes in the first 32 bits, or, if
I have more 40-bit instructions in a group, up to seven eight-bit
prefixes in the first 64 bits.

Some might be inclined to say:
Just go with 32-bit instruction words or similar and call it done.

Main areas for debate being things like the sizes of register and
immediate fields.


Say:
zzzzoooooommmmmmzzzznnnnnnzzzzzz //XG3 3R
iiiiiiiiiimmmmmmzzzznnnnnnzzzzzz //XG3 3RI
zzzzzzzooooommmmmzzznnnnnzzzzzzz //RV 3R
iiiiiiiiiiiimmmmmzzznnnnnzzzzzzz //RV 3RI
...


--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.arch

On Tue, 30 Jun 2026 05:47:26 -0000 (UTC), Thomas Koenig
<tkoenig@netcologne.de> wrote:

John Savard <quadibloc@invalid.com> schrieb:

On Mon, 29 Jun 2026 17:41:20 GMT, MitchAlsup >><user5857@newsgrouper.org.invalid> wrote:

You seem to have a patent on "going around in circles".

I can't take credit for the invention of the wheel; that existed
before I was born.

Really? I would have guessed you were born before 2001.

See https://patents.google.com/patent/AU2001100012A4/en?oq=AU2001100012
where somebody patented a "Circular transportation facilitation device".

If you carefully word your application, it seems you can get almost
anything past (at least) the USPTO. This has been true for a long
time and the situation doesn't seem to be improving.

Except for in a few selected areas, USPTO examiners tend to be badly overworked. On average, the examiner will be able to spend only 3..4
hours to understand the "invention" and search for prior art. By law,
the application must be approved if /disqualifying/ prior art can't be
found.

There have been many ridiculous patents granted: e.g., for boiling an
egg, entertaining cats, covering the head with a hat, etc. You just
need to describe it appropriately.

Yes, many of the ridiculous patents were overturned and/or revoked ...
the point is that they made it past examination to be granted in the
first place. 8-(

So the Concertina II with block structure has been retained, as block
structure does allow greater space efficiency compared to having each
instruction indicate its length.

Again, grouping instructions will make the job of a compiler or
assembler very close to impossible.

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.arch


George Neuner <gneuner2@comcast.net> posted:

On Tue, 30 Jun 2026 05:47:26 -0000 (UTC), Thomas Koenig <tkoenig@netcologne.de> wrote:

John Savard <quadibloc@invalid.com> schrieb:

On Mon, 29 Jun 2026 17:41:20 GMT, MitchAlsup >><user5857@newsgrouper.org.invalid> wrote:

You seem to have a patent on "going around in circles".

I can't take credit for the invention of the wheel; that existed
before I was born.

Really? I would have guessed you were born before 2001.

See https://patents.google.com/patent/AU2001100012A4/en?oq=AU2001100012 >where somebody patented a "Circular transportation facilitation device".

If you carefully word your application, it seems you can get almost
anything past (at least) the USPTO. This has been true for a long
time and the situation doesn't seem to be improving.

Except for in a few selected areas, USPTO examiners tend to be badly overworked. On average, the examiner will be able to spend only 3..4
hours to understand the "invention" and search for prior art. By law,
the application must be approved if /disqualifying/ prior art can't be
found.

One way past this "issue" is to cite so much prior-art that the examiner's
time quanta is expired just looking at your application and chasing down
cited leads.

There have been many ridiculous patents granted: e.g., for boiling an
egg, entertaining cats, covering the head with a hat, etc. You just
need to describe it appropriately.

Yes, many of the ridiculous patents were overturned and/or revoked ...
the point is that they made it past examination to be granted in the
first place. 8-(

Adding years to the "grant" wait.

So the Concertina II with block structure has been retained, as block
structure does allow greater space efficiency compared to having each
instruction indicate its length.

Again, grouping instructions will make the job of a compiler or
assembler very close to impossible.

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.arch

George Neuner <gneuner2@comcast.net> schrieb:

On Tue, 30 Jun 2026 05:47:26 -0000 (UTC), Thomas Koenig
<tkoenig@netcologne.de> wrote:

John Savard <quadibloc@invalid.com> schrieb:

On Mon, 29 Jun 2026 17:41:20 GMT, MitchAlsup >>><user5857@newsgrouper.org.invalid> wrote:

You seem to have a patent on "going around in circles".

I can't take credit for the invention of the wheel; that existed
before I was born.

Really? I would have guessed you were born before 2001.

See https://patents.google.com/patent/AU2001100012A4/en?oq=AU2001100012 >>where somebody patented a "Circular transportation facilitation device".

If you carefully word your application, it seems you can get almost
anything past (at least) the USPTO.

This was actually a special case. In Australia, they introduce a
special kind of patent which was granted *without* examination.
The "inventor" in this case was a patent attorney who wanted to
game the system to draw attention to this.

But I loved the "Background of the invention" section. "In the past, transportation of goods and persons has been conducted in a number
of ways. The predominant means has been transport of persons on foot,
and carrying thereby of goods requiring transport."

And then he goes on about "skis, sleds, toboggans and the like", which
are not available in warmer climates because there is no ice or snow. Hilarious.

This has been true for a long
time and the situation doesn't seem to be improving.

Doesn't necessarily match my experience, but then I may be in the
wrong field :-)

Except for in a few selected areas, USPTO examiners tend to be badly overworked. On average, the examiner will be able to spend only 3..4
hours to understand the "invention" and search for prior art. By law,
the application must be approved if /disqualifying/ prior art can't be
found.

That is not the only criterion. A patent also has to have an
inventive step and be commercially applicable. Plus, you need
to describe your invention well enough that you do not need another
invention to use it.

There have been many ridiculous patents granted: e.g., for boiling an
egg, entertaining cats, covering the head with a hat, etc. You just
need to describe it appropriately.

Do you have any pointers to these? (Boiling an egg in a certain
way that saves energy, improves the quality, ... may actually
be patentable).

Yes, many of the ridiculous patents were overturned and/or revoked ...
the point is that they made it past examination to be granted in the
first place. 8-(

That is of course true.
--
This USENET posting was made without artificial intelligence,
artificial impertinence, artificial arrogance, artificial stupidity,
artificial flavorings or artificial colorants.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.arch

On Wed, 1 Jul 2026 05:19:51 -0000 (UTC), Thomas Koenig
<tkoenig@netcologne.de> wrote:

George Neuner <gneuner2@comcast.net> schrieb:

On Tue, 30 Jun 2026 05:47:26 -0000 (UTC), Thomas Koenig >><tkoenig@netcologne.de> wrote:

Except for in a few selected areas, USPTO examiners tend to be badly
overworked. On average, the examiner will be able to spend only 3..4
hours to understand the "invention" and search for prior art. By law,
the application must be approved if /disqualifying/ prior art can't be
found.

That is not the only criterion. A patent also has to have an
inventive step and be commercially applicable. Plus, you need
to describe your invention well enough that you do not need another
invention to use it.

There are conditions for the application, but the idea certainly does
/not/ have to be "commercially applicable". Nor, it seems, does it
actually have to work, although it must be, at least, theoretically
possible.

In the past an inventor had to have a functioning device, or a working demonstration of their process ... ie. something that /proved/ the
idea was sound. The examiner didn't necessarily need to see these
things, but under the rules they had to exist or the application could
not be filed in the first place.

It appears that this rule either is gone, or no longer is enforced.

There have been many ridiculous patents granted: e.g., for boiling an
egg, entertaining cats, covering the head with a hat, etc. You just
need to describe it appropriately.

Do you have any pointers to these? (Boiling an egg in a certain
way that saves energy, improves the quality, ... may actually
be patentable).

Sorry. There are a number of web sites that chronicle weird patents.

My father was a patent attorney - I used to follow the court decisions
and changes in (and proposals to change) the laws, but after he
retired I found that I didn't have as much interest in it.

Yes, many of the ridiculous patents were overturned and/or revoked ...
the point is that they made it past examination to be granted in the
first place. 8-(

That is of course true.

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.arch

George Neuner <gneuner2@comcast.net> schrieb:

On Wed, 1 Jul 2026 05:19:51 -0000 (UTC), Thomas Koenig
<tkoenig@netcologne.de> wrote:

George Neuner <gneuner2@comcast.net> schrieb:

On Tue, 30 Jun 2026 05:47:26 -0000 (UTC), Thomas Koenig >>><tkoenig@netcologne.de> wrote:

Except for in a few selected areas, USPTO examiners tend to be badly
overworked. On average, the examiner will be able to spend only 3..4
hours to understand the "invention" and search for prior art. By law,
the application must be approved if /disqualifying/ prior art can't be
found.

That is not the only criterion. A patent also has to have an
inventive step and be commercially applicable. Plus, you need
to describe your invention well enough that you do not need another >>invention to use it.

There are conditions for the application, but the idea certainly does
/not/ have to be "commercially applicable".

In Germany, it has to be: https://www.dpma.de/patente/pruefung_erteilung/index.html

For the EPO, it has to be "susceptible to industrial application, https://www.epo.org/en/legal/guidelines-epc/2026/g_i_1.html

In the US, it seems to be broader, there it just has to have
"utility":

https://www.law.cornell.edu/uscode/text/35/101

Nor, it seems, does it
actually have to work, although it must be, at least, theoretically
possible.

I think the US and Europe differ there, somewhat.

In the past an inventor had to have a functioning device, or a working demonstration of their process ... ie. something that /proved/ the
idea was sound. The examiner didn't necessarily need to see these
things, but under the rules they had to exist or the application could
not be filed in the first place.

It appears that this rule either is gone, or no longer is enforced.

You are still well advised to put examples into your patents :-)

There have been many ridiculous patents granted: e.g., for boiling an
egg, entertaining cats, covering the head with a hat, etc. You just
need to describe it appropriately.

Do you have any pointers to these? (Boiling an egg in a certain
way that saves energy, improves the quality, ... may actually
be patentable).

Sorry. There are a number of web sites that chronicle weird patents.

My father was a patent attorney - I used to follow the court decisions
and changes in (and proposals to change) the laws, but after he
retired I found that I didn't have as much interest in it.

I have a bit of a professional interest, I wrote a few (and it is
not very pleasant, I can assure you :-)
--
This USENET posting was made without artificial intelligence,
artificial impertinence, artificial arrogance, artificial stupidity,
artificial flavorings or artificial colorants.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.arch

On Wed, 1 Jul 2026 05:19:51 -0000 (UTC), Thomas Koenig
<tkoenig@netcologne.de> wrote:

This was actually a special case. In Australia, they introduce a
special kind of patent which was granted *without* examination.
The "inventor" in this case was a patent attorney who wanted to
game the system to draw attention to this.

And, of course, that sort of motivation is needed.

If I had gotten a patent for "Circular rotating device for the
reduction of friction" in the United States, citing such things as
ball bearings as prior art, because the patent examiner was
snoozing... I would just have wasted the money on the applications
process, given that I would not be able to get millions of dollars
from the automobile industry in Detroit by means of it, as it would
fall apart at the first legal challenge.

John Savard
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.arch


George Neuner <gneuner2@comcast.net> posted:

On Wed, 1 Jul 2026 05:19:51 -0000 (UTC), Thomas Koenig <tkoenig@netcologne.de> wrote:

George Neuner <gneuner2@comcast.net> schrieb:

On Tue, 30 Jun 2026 05:47:26 -0000 (UTC), Thomas Koenig >><tkoenig@netcologne.de> wrote:

Except for in a few selected areas, USPTO examiners tend to be badly
overworked. On average, the examiner will be able to spend only 3..4
hours to understand the "invention" and search for prior art. By law,
the application must be approved if /disqualifying/ prior art can't be
found.

That is not the only criterion. A patent also has to have an
inventive step and be commercially applicable. Plus, you need
to describe your invention well enough that you do not need another >invention to use it.

There are conditions for the application, but the idea certainly does
/not/ have to be "commercially applicable". Nor, it seems, does it
actually have to work, although it must be, at least, theoretically
possible.

In the past an inventor had to have a functioning device, or a working demonstration of their process ... ie. something that /proved/ the
idea was sound.

In my case, I cited J. M. Muller's textbook as evidence that the means
was sound. I did not claim anything the JMM book specified, but several
other ways of performing the polynomials involved, and a way that HW
could perform table lookup.

The examiner didn't necessarily need to see these
things, but under the rules they had to exist or the application could
not be filed in the first place.

It appears that this rule either is gone, or no longer is enforced.

There have been many ridiculous patents granted: e.g., for boiling an
egg, entertaining cats, covering the head with a hat, etc. You just
need to describe it appropriately.

Do you have any pointers to these? (Boiling an egg in a certain
way that saves energy, improves the quality, ... may actually
be patentable).

Sorry. There are a number of web sites that chronicle weird patents.

My father was a patent attorney - I used to follow the court decisions
and changes in (and proposals to change) the laws, but after he
retired I found that I didn't have as much interest in it.

Yes, many of the ridiculous patents were overturned and/or revoked ...
the point is that they made it past examination to be granted in the
first place. 8-(

That is of course true.

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.arch

MitchAlsup <user5857@newsgrouper.org.invalid> writes:

George Neuner <gneuner2@comcast.net> posted:

Except for in a few selected areas, USPTO examiners tend to be badly overworked. On average, the examiner will be able to spend only 3..4
hours to understand the "invention" and search for prior art. By law,
the application must be approved if /disqualifying/ prior art can't be found.

One way past this "issue" is to cite so much prior-art that the examiner's time quanta is expired just looking at your application and chasing down cited leads.

Let us agree to check back on this statement in, say, 5 years. I suspect
AI will have a dramatic impact on patent application reviews by then.

I'm no fan of AI in general, but this seems like an obvious and even appropriate application of it.

Andy Valencia
Home page: https://www.vsta.org/andy/
To contact me: https://www.vsta.org/contact/andy.html
No AI was used in the composition of this message
--- Synchronet 3.22a-Linux NewsLink 1.2