From Newsgroup: comp.arch

According to John Dallman <jgd@cix.co.uk>:

In article <10uks4f$1dqo$1@gal.iecc.com>, johnl@taugh.com (John Levine) >wrote:

Having looked into this in some detail, both when IBM used
bigendian order on S/360 and DEC used little-endian on the
PDP-11, neither documented the reasons for the byte order
choice at all. Not even a litle bit.

Brooks and Blaauw, two of the S/360 architects, consider the subject in
their much later book _Computer Architecture_, on p. 99:

"The more logical convention, the Big Endian, considers the whole
storage space as one steam of bits. Bits, bytes and words are
numbered from left to right, following the convention of writing
in Western culture."

I'd forgotten about that. Given who they were it's not surprising they found their preconceptions to be "more logical".

On the next page they said (written in 1997):

"Unlike Swift's, the computer Endian controversy is not pointless. The Little Endian design has many complications in use; we much prefer the
Big Endian. Having two active conventions is very painful. Several recent
Big Endian RISC computers., including the MIPS, the Motorola 88000, and
the Intel i860 provide a data-movement operation that can perform the Big Endian-Little Endian permuation [Hennesy and Patterson, 1990]. We predict
that Little Endian addressing will die out, just as decimal addressing did."

Uh huh.

A few years later IBM added LOAD REVERSED and STORE REVERSED to z/Architecture and retroactively to S/390 mode on Z machines.
--
Regards,
John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.arch

On Tue, 02 Jun 2026 22:00:06 +0000, John Levine wrote:

"We predict that Little Endian addressing will die out, just as
decimal addressing did."

Uh huh.

A few years later IBM added LOAD REVERSED and STORE REVERSED to z/Architecture and retroactively to S/390 mode on Z machines.

I certainly would not hazard such a bold prediction.

The prediction, though, is not hard to understand. If big-endian is more straightforward and easier to understand, but just costs an extra
transistor here and there, then in the age of billion-transistor chips,
why wouldn't it die out?

However, just because something is going to die out _eventually_ doesn't
mean it will do so any time soon. Interoperating and communicating with
that little-endian monster IBM created in 1981 is going to be important
for generating revenue for decades to come.

So the existence of load reversed and store reversed instructions doesn't prove they were wrong... even though I still would not dare to say they
are definitely right. I just think it's not unreasonable to think as they
did, provided you account for a sufficiently long timeframe.

Of course, given a sufficiently long timeframe, we might all be speaking Arabic, in which case little-endian would be the logical choice. Although
that would require fossil fuels being important for longer than the
climate could sustain it...

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

From Newsgroup: comp.arch

On Tue, 02 Jun 2026 15:59:33 +0000, Anton Ertl wrote:

My take is, that in a world with different access widths (e.g.,
accessing a register for a 32-bit value or a 64-bit value),
bit-big-endian is a bad idea.

There is an argument for that.

But if a computer does have bit-field instructions, I tend to consider it insane for it to number bits in the opposite direction of its endianness.

Even though the problem isn't necessarily all that bad; as long as the bit fields are genuinely contiguous, then only the names of the bits in a byte
are encoded funny.

So if a 32 bit number is stored in bytes 5001, 5000, 4999, and 4998, from
most significant byte to least significant, and you specify a 9-bit field starting in bit 6 of byte 4999... and the bits are numbered in big-endian order... the same thing should happen as if you specified bit 1 of byte
4999 on a little-endian machine with little-endian bit numbering. You get
nine bits, the seven least significant of which are bits 0 through 6 of
byte 4999, and the remaining two of which are bits 6 and 7 of byte 5000.

In the more common case, where the machine is big-endian, and it is the
bit numbering that's little-endian, specifying a nine-bit field starting
in bit 6 of byte 4999 would give you bits 6 through 0 of byte 4999,
followed by bits 7 and 6 of byte 5000. Here, though, you're going from
most significant to least significant, but in both cases you're moving
forward to higher addresses, just as you do when accessing multi-byte
numbers with a byte address.

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

From Newsgroup: comp.arch

On Wed, 20 May 2026 05:38:07 +0000, Anton Ertl wrote:

* The last descendent of the PDP-11 was canceled long before the most
prominent big-endien architecture (SPARC) was canceled, and long
before Power switched its Linux support to little-endian, so the
PDP-11 had little, if any, influence on the outcome.

The long decline of big-endian happened later.

But there wouldn't have _been_ little-endian architectures to out-compete big-endian if it hadn't been for the PDP-11. That was where the idea of little-endian got started.

It wasn't the first machine to store two-word numbers least-significant-
word first. But it was the first machine to be little-endian in any other
way but that. Little-endian, as something more than an ad-hoc way to
handle one case of double-precision integers, wasn't a thing until the
PDP-11 came along.

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

From Newsgroup: comp.arch


quadi <quadibloc@ca.invalid> posted:

On Tue, 02 Jun 2026 17:50:38 +0200, Terje Mathisen wrote:

In the current environment where every language is expected to be compatible with a generic IDE like Visual Studio Code, via open source interface specifications, having a proprietary debug format seems like a good way to strongly limit your potential customer base.

You appear to have understood his post in a different way than I did.

I wasn't thinking of the kind of debug information provided by a compiler.

I was thinking of leaving debug information in when one was distributing software to customers.

Yes, you the vendor do not want random customer debugging the code,
however, you want the ability to debug the code that was distributed
on whatever medium on customer's system(s)--

AND you want to debug one copy of the running code while others are using
other processes running the code under normal use.

John Savard

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.arch


quadi <quadibloc@ca.invalid> posted:

On Tue, 02 Jun 2026 22:00:06 +0000, John Levine wrote:

"We predict that Little Endian addressing will die out, just as
decimal addressing did."

Uh huh.

A few years later IBM added LOAD REVERSED and STORE REVERSED to z/Architecture and retroactively to S/390 mode on Z machines.

I certainly would not hazard such a bold prediction.

The prediction, though, is not hard to understand. If big-endian is more straightforward and easier to understand, but just costs an extra
transistor here and there, then in the age of billion-transistor chips,
why wouldn't it die out?

Linux has gone all in on LE. So, if you want to start a HW company,
you are forced to either choose LE or develop your own Operating
System (with all the accoutrement involved.)

However, just because something is going to die out _eventually_ doesn't mean it will do so any time soon. Interoperating and communicating with
that little-endian monster IBM created in 1981 is going to be important
for generating revenue for decades to come.

The whole internet is Dual-endian !! With part LE and other parts BE.

So the existence of load reversed and store reversed instructions doesn't prove they were wrong... even though I still would not dare to say they
are definitely right. I just think it's not unreasonable to think as they did, provided you account for a sufficiently long timeframe.

A byte reverse instruction will also work.

Of course, given a sufficiently long timeframe, we might all be speaking Arabic, in which case little-endian would be the logical choice. Although that would require fossil fuels being important for longer than the
climate could sustain it...

John Savard

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.arch

On Wed, 03 Jun 2026 01:03:26 +0000, MitchAlsup wrote:

Linux has gone all in on LE.

It's true that Linux doesn't support the big-endian version of RISC-V. But
it runs on other big-endian architectures.

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

From Newsgroup: comp.arch

On 2026-Jun-02 13:13, MitchAlsup wrote:

Middle endian!! Start in the middle and then one step left followed by
one step write--more or less like PDP-11 FP.

We're doing the time warp... again!


--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.arch

quadi <quadibloc@ca.invalid> schrieb:

On Tue, 02 Jun 2026 22:00:06 +0000, John Levine wrote:

"We predict that Little Endian addressing will die out, just as
decimal addressing did."

Uh huh.

A few years later IBM added LOAD REVERSED and STORE REVERSED to
z/Architecture and retroactively to S/390 mode on Z machines.

I certainly would not hazard such a bold prediction.

The prediction, though, is not hard to understand. If big-endian is more straightforward and easier to understand, but just costs an extra
transistor here and there, then in the age of billion-transistor chips,
why wouldn't it die out?

It causes problems with badly-written software.

Consider the following test program:

#include <stdio.h>

void printit(void *p)
{
char *c = p;
printf ("Value is: %d\n", *c);
}

int main()
{
int i = 42;
printit (&i);
return 0;
}

On a little-endian system, this prints
Value is: 42

On a big-endian system, this prints
Value is: 0

If software designers play games with this sort of thing
(knowingly or unknowingly), then software that will run
on a little-endian system will not run on a big-endian
system.
--
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, 03 Jun 2026 13:54:01 +0000, Thomas Koenig wrote:

It causes problems with badly-written software.

I don't see that as a fault of big-endian.

One has to exert oneself to write a program equivalent to

INTEGER*2 IP
EQUIVALENCE (I, IP)
I = 42
WRITE(6,11) IP
STOP
11 FORMAT(' ', 'VALUE IS: ', I3)
END

and so the fact that it will print

VALUE IS: 0

is not a bug, it's exactly what one should expect.

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

From Newsgroup: comp.arch

According to quadi <quadibloc@ca.invalid>:

On Wed, 03 Jun 2026 13:54:01 +0000, Thomas Koenig wrote:

It causes problems with badly-written software.

I don't see that as a fault of big-endian.

Agreed. There were plenty of bugs porting BSD software from
the little-endian Vax to big-endian 68000 series. Buggy software
is buggy software.
--
Regards,
John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.arch

quadi <quadibloc@ca.invalid> writes:

But there wouldn't have _been_ little-endian architectures to out-compete >big-endian if it hadn't been for the PDP-11. That was where the idea of >little-endian got started.

The Datapoint 2200 would most likely have had the little-endian
encoding if the PDP-11 had been big-endian, because it was developed independently and in parallel. The 8080's call and ret instructions
were the first where little-endian extended beyond instruction
encoding, but I expect that, once you have jump instructions with
little-endian targets, you also want return addresses to be stored in little-endian byte order (simplifies implementation). And from there
it goes to the 8086 which has 16-bit data memory accesses, and where
you also stick with little-endian if you already have done so for jump
targets and return addresses. And following the
8086, IA-32 and AMD64 would have been little-endian, too.

The 6502 would have been little-endian if the PDP-11 had been
big-endian, for technical reasons. They ignored even the big-endian
byte order of its predecessor, the 6800. And following the 6502, the
ARM would have been little-endian even if the PDP-11 had been
big-endian.

So the architectures that dominate now would be little-endian even if
the PDP-11 had been big-endian. Would they have been less successful
if the PDP-11 had been big-endian? I doubt it. At a point around
1990, most of the Unix market was big-endian, based on the 68000 being big-endian, and it seemed that if any byte order would win, it would
be big-endian. IA-32 and VAX were expected to die because they were
CISCs, and ARM was just a minor player in the RISC market at the time.

And yet, IA-32/AMD64 and ARM's instruction sets outlived all the
highly successful RISCs of the time. This would also have happened if
the PDP-11 and the VAX would have been big-endian.

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

From Newsgroup: comp.arch

quadi <quadibloc@ca.invalid> writes:

On Tue, 02 Jun 2026 15:59:33 +0000, Anton Ertl wrote:

My take is, that in a world with different access widths (e.g.,
accessing a register for a 32-bit value or a 64-bit value),
bit-big-endian is a bad idea.

There is an argument for that.

But if a computer does have bit-field instructions, I tend to consider it >insane for it to number bits in the opposite direction of its endianness.

So if big-endian bit numbering is a bad idea (and it is), big endian
byte order is a bad idea, too.

In the more common case, where the machine is big-endian, and it is the
bit numbering that's little-endian, specifying a nine-bit field starting
in bit 6 of byte 4999 would give you bits 6 through 0 of byte 4999,
followed by bits 7 and 6 of byte 5000.

This does not make sense. You have the 32-bit word with address 4998.
If you access a 9-bit field at bit 6, it extends to bit 14, and these
bits will be in the bytes at addresses 5001 and 5000 on your
byte-big-endian machine. As long as you only access this bit field
through a 32-bit access at this address, the difference does not play
a role. But once you want to access it through an 32-bit access at
4999 (now it's bit 14 through 22), a 16-bit access at 5000 (bit 6
through 14 again), or a 32-bit access at 5000 (bit 22 through 30), the different orders become confusing.

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

From Newsgroup: comp.arch

Yes, you the vendor do not want random customer debugging the code,

I also want a pony, but that doesn't make it right.

The customer will usually not want to debug your code, but sometimes
they will have to (e.g. because you the vendor don't exist any more or
don't find that product of commercial value any more, ...).

The customer deserves to be able to debug the code it's paid for.


=== Stefan
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.arch

Stefan Monnier <monnier@iro.umontreal.ca> writes:

<snip discussion of including debug data in distributed software>

Yes, you the vendor do not want random customer debugging the code,

I also want a pony, but that doesn't make it right.

The customer will usually not want to debug your code, but sometimes
they will have to (e.g. because you the vendor don't exist any more or
don't find that product of commercial value any more, ...).

The customer deserves to be able to debug the code it's paid for.

There are several reasons that a vendor may wish to refrain from
distributing the DWARF (or windows equiv) data with a software
package. For example, program identifiers may inadvertently
identify other customers, internal proprietary
information or internal codenames.

Being able to debug code without the source code doesn't seem
a particulary common use case, nor would it be a viable way
to continue to use orphaned software, other than to, perhaps,
get it working sufficient to export any application
data in an interchange form (e.g. csv or xml if supported
by the application). I would certainly not recommend
that it be used for production.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.arch

quadi <quadibloc@ca.invalid> schrieb:

On Wed, 03 Jun 2026 13:54:01 +0000, Thomas Koenig wrote:

[big-endian]

It causes problems with badly-written software.

I don't see that as a fault of big-endian.

Neither do I. I am glad I still have access to a few big-endian
machines. For example:

$ lscpu
Architecture: ppc64
CPU op-mode(s): 32-bit, 64-bit
Byte Order: Big Endian
CPU(s): 64
On-line CPU(s) list: 0-63
Model name: POWER10 (architected), altivec supported
[...]

(which shows that big-endian Linux is still supported).

But if the software you are targeting is primarily written on,
and for, little-endian systems like x86, then the little-endian
assumption will tend to creep in - certain things like writing
an int to memory and reading back a char will "just work", and
programmers may not know or care that they are violating language
standards; they very rarely do.

So what to do? Submit bug reports and patches and hoped they are
integrated, or just bite the bullet and offer a little-endian
version as well? IBM chose the latter.

And refering to the point above, the code

One has to exert oneself to write a program equivalent to

INTEGER*2 IP
EQUIVALENCE (I, IP)
I = 42
WRITE(6,11) IP
STOP
11 FORMAT(' ', 'VALUE IS: ', I3)
END

also violates the FORTRAN standard going back to Fortran 66.
After the "I = 42" statement, IP becomes undefined according to
the language definition.

and so the fact that it will print

VALUE IS: 0

is not a bug, it's exactly what one should expect.

It could also launch World War III, provided the right operational
hardware has been installed.
--
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


Stefan Monnier <monnier@iro.umontreal.ca> posted:

Yes, you the vendor do not want random customer debugging the code,

I also want a pony, but that doesn't make it right.

The customer will usually not want to debug your code, but sometimes
they will have to (e.g. because you the vendor don't exist any more or
don't find that product of commercial value any more, ...).

The customer deserves to be able to debug the code it's paid for.

Does MS allow you to debug W11 or Office ...
Does Corel allow you to debug Draw ...
Does Adobe allow you to debug PDF reader ...

Which is why, sooner or later, open source should win.

=== Stefan

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.arch

On Tue, 02 Jun 2026 15:59:33 GMT, anton@mips.complang.tuwien.ac.at
(Anton Ertl) wrote:

The 68020 is bit-little-endian and byte-big-endian, and it has
bitfield instructions, and from what I have read, this has led to
problems (e.g., consider what to do if you have an array of 17-bit
fields: how do you access the nth element of the array?

<array>[n] ?

In C the default would be an aligned array of 32-bit containers each
of which stored a 17-bit field.

If you mean a /packed/ array in which the 17-bit fields are stored bit contiguously ... well that could get interesting.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.arch

On Mon, 01 Jun 2026 19:56:38 +0000, quadi wrote:

I wasn't happy. So I noticed that I actually had some unused space that
I could squeeze out. So now the 24-bit short instructions have 1/2 as
much space as they used to, which meant the only thing I had to give up
was the ability to change the condition codes.

I found that I had some unused space within the 80-bit instructions, and
that was enough to let me restore the 24-bit short instructions to their former glory.

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

From Newsgroup: comp.arch

On Thu, 04 Jun 2026 04:06:45 +0000, quadi wrote:

I found that I had some unused space within the 80-bit instructions, and
that was enough to let me restore the 24-bit short instructions to their former glory.

Then another crazy idea came into my head. The 16-bit short instructions
are limited to operating on the first eight registers. Some believe that
this limitation will make them essentially useless.

They have a lot more opcode space allocated to them than the 24-bit short instructions. If I took that space, and gave it to the 24-bit short instructions, I could perhaps add a 24-bit memory-reference instruction!

Well, I tried, and found out that I could indeed almost do that, with, of course, a restriction to 12-bit displacements... but, at best, I could
only use two registers as destination registers for those memory-reference instructions!

So that idea had to be discarded.

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

From Newsgroup: comp.arch

George Neuner <gneuner2@comcast.net> writes:

On Tue, 02 Jun 2026 15:59:33 GMT, anton@mips.complang.tuwien.ac.at
(Anton Ertl) wrote:

The 68020 is bit-little-endian and byte-big-endian, and it has
bitfield instructions, and from what I have read, this has led to
problems (e.g., consider what to do if you have an array of 17-bit
fields: how do you access the nth element of the array?

[...]

If you mean a /packed/ array in which the 17-bit fields are stored bit >contiguously ... well that could get interesting.

For a consistently little-endian architecture that has no alignment requirements, the access is relativelysimple:

nbit = n*17
nbyte = nbit/8
bitoffset = nbit%8
tmp = load32b(array+nbyte)
element = ext(tmp,bitoffset,17)

(ext extracts the bitfield with length 17 at bitoffset from tmp; 88000
and MIPS64r2 have such instructions).

I leave the consistently big-endian version and the byte-big-endian bit-little-endian version as exercise to those who think that these
are good ideas. I guess, for consistent big-endian, given an
appropriate definition of ext, it's pretty similar, if not the same as
above. The inconsistent variants (e.g., 68020, 88000, MIPS64r2) are
not so easy, however.

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

From Newsgroup: comp.arch

On 6/3/26 12:36 PM, John Levine wrote:

According to quadi <quadibloc@ca.invalid>:

On Wed, 03 Jun 2026 13:54:01 +0000, Thomas Koenig wrote:

It causes problems with badly-written software.

I don't see that as a fault of big-endian.

Agreed. There were plenty of bugs porting BSD software from
the little-endian Vax to big-endian 68000 series. Buggy software
is buggy software.

That followed the port to the Interdata 7/32 which was big-endian,
so BSD must not have learned from that.

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.arch

Scott Lurndal [2026-06-03 18:36:51] wrote:

Being able to debug code without the source code doesn't seem
a particulary common use case,

Indeed, the source code should also be available, of course.
I started this thread by mentioning Free Software. 🙂


=== Stefan
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.arch

Stefan Monnier <monnier@iro.umontreal.ca> schrieb:

Scott Lurndal [2026-06-03 18:36:51] wrote:

Being able to debug code without the source code doesn't seem
a particulary common use case,

Indeed, the source code should also be available, of course.
I started this thread by mentioning Free Software. 🙂

I am a big proponent of free software, but it has a basic problem:
Getting developers paid is not easy.

An example is OpenFOAM. This is a very widely used CFD package,
both in academia (because it costs nothing, and ANSYS is very
expensive, also for universities) and also now in industry because
people who come in from university have learned this during their
PhDs (you need quite some time to learn).

Funding? They want 500 k€ in 2026, which is far from excessive,
see https://openfoam.org/news/funding-2026/ , both compared to
commercial CFD companies and the value that OpenFOAM provides.
--
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, 03 Jun 2026 00:55:35 GMT, MitchAlsup
<user5857@newsgrouper.org.invalid> wrote:

quadi <quadibloc@ca.invalid> posted:

On Tue, 02 Jun 2026 17:50:38 +0200, Terje Mathisen wrote:

In the current environment where every language is expected to be
compatible with a generic IDE like Visual Studio Code, via open source
interface specifications, having a proprietary debug format seems like a >> > good way to strongly limit your potential customer base.

You appear to have understood his post in a different way than I did.

I wasn't thinking of the kind of debug information provided by a compiler. >>
I was thinking of leaving debug information in when one was distributing
software to customers.

Yes, you the vendor do not want random customer debugging the code,
however, you want the ability to debug the code that was distributed
on whatever medium on customer's system(s)--

AND you want to debug one copy of the running code while others are using >other processes running the code under normal use.

That is true, but the issue at hand is how to achieve that. Leaving
debug information /in/ the executable, I think, is a bad idea.

However, many (most?) toolchains provide a way to separate debug
symbols from the executable - either by generating a separate symbol
database in the 1st place, or by allowing debug data to be stripped
from the executables. If you have to debug at the client site, you
simply take the symbol database with you.

Another useful method is to write out debug information as the program
executes and arrange that it either is suppressed or (alternatively)
goes to /dev/null unless some undocumented flag is given.
[Obviously where speed is paramount you can't be generating
unnecessary output, so the utility of this method is situation
dependent.]


I have used both of these methods in the past.
YMMV.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.arch

Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:

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

anton@mips.complang.tuwien.ac.at (Anton Ertl) posted:

long bar(long x, long y)
{
return x/2+y/2;
}

...

Trying the same on a MIPS64 machine with gcc-8.3 (which apparently
produces ILP32 code) produces a call to __addvsi3 instead of the
expected add instruction:

gcc -O3 -ftrapv gcc -O3
lui gp,0x0 srl v0,a0,0x1f
addiu gp,gp,0 srl v1,a1,0x1f
addu gp,gp,t9 addu v0,v0,a0
srl v1,a0,0x1f addu a1,v1,a1
lw t9,__addvsi3(gp) sra v0,v0,0x1
srl v0,a1,0x1f sra a1,a1,0x1
addiu sp,sp,-32 jr ra
addu a0,v1,a0 addu v0,v0,a1
addu a1,v0,a1
sra a0,a0,0x1
sw ra,28(sp)
sw gp,16(sp)
jalr t9
sra a1,a1,0x1
lw ra,28(sp)
jr ra
addiu sp,sp,32

The call costs a lot of overhead.

Architectures without overflow traps are notorious for excess instruction >>count when overflow detection is desired or mandated.

MIPS' add traps on overflow. gcc could have emitted almost the same
code for gcc -O3 -trapv as for gcc -O3, except that the last
instruction would be an add, not an addu. But apparently nobody gives
a damn about the efficiency of -trapv, possibly rightly so.

My guess is that GCC developers care more about -trapv than about
MIPS. AFAICS several architectures officialy supported by GCC
struggle to work at all. I suspect that maintainers of MIPS
backend are happy that -trapv works and do not have resources
to make it efficient.
--
Waldek Hebisch
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.arch

Waldek Hebisch <antispam@fricas.org> schrieb:

Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:

MIPS' add traps on overflow. gcc could have emitted almost the same
code for gcc -O3 -trapv as for gcc -O3, except that the last
instruction would be an add, not an addu. But apparently nobody gives
a damn about the efficiency of -trapv, possibly rightly so.

My guess is that GCC developers care more about -trapv than about
MIPS.

It is a common misconception to treat GCC developers as a
monolithic group. There are hobbyists (such as myself) but
I would guess only a small minority of work is done by them,
with the notable exception of some front ends such as Fortran or
(the most recent example) Algol 68. There are employees by
different companies: Linux distributors like RedHat or Suse,
Large software companies like Google, hardware vendors like
IBM, Intel or Qualcomm, ...

For MIPS, there are not so many active people and commits.
mips64-linux-gnu is a secondary platform, so if it fails
bootstrap, a release would be held up, but a wrong-code
regression will not.

Counting changes since 2025-01-01 in the gcc/config directories
can give a good idea of the relative activity for different
subdirectories; I cut this off below 7, where the PDP-11 is (note
that architecture names are often historical, so i386 includes
x86_64, s390 includes Z, rs6000 includes POWER and so on).

539 ./riscv
435 ./i386
432 ./aarch64
177 ./loongarch
100 ./arm
85 ./s390
75 ./avr
72 ./xtensa
60 ./rs6000
51 ./gcn
39 ./nvptx
25 ./sparc
25 ./mips
20 ./arc
19 ./pa
19 ./bpf
19 ./alpha
18 ./pru
15 ./sh
13 ./rx
13 ./cris
12 ./or1k
12 ./microblaze
12 ./m68k
11 ./lm32
11 ./ia64
11 ./h8300
9 ./vax
9 ./nds32
8 ./mcore
8 ./epiphany
8 ./c6x
7 ./visium
7 ./rl78
7 ./pdp11
7 ./frv
7 ./csky

AFAICS several architectures officialy supported by GCC
struggle to work at all. I suspect that maintainers of MIPS
backend are happy that -trapv works and do not have resources
to make it efficient.

First, they would need to know about this, which requires a PR,
but resources may well be lacking.

There are currently 28 open "missed-optimization" bugs with mips
in their target field. Looking at a few architectures above,
RISC-V has 118, x86 has 943, aarch64 has 305, power has 133.
(Some bugs affect more than one architecture, of course).

But it is worth submitting a PR nonetheless, if anybody cares enough :-)
--
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

George Neuner <gneuner2@comcast.net> writes:

That is true, but the issue at hand is how to achieve that. Leaving
debug information /in/ the executable, I think, is a bad idea.

On the contrary, it's an excellent idea. It means that the debug
information goes with the code. No chance of confusing yourself by inadvertantly associating the wrong debugging information with the
code, and much less chance of not finding the correct debug
information.

Best of all, of course, is to deliver the source code.

Another useful method is to write out debug information as the program >executes and arrange that it either is suppressed or (alternatively)
goes to /dev/null unless some undocumented flag is given.

Undocumented features are forgotten and reimplemented. There's the
story of Microsoft embedding some watermark into Microsoft BASIC
twice, the second time apparently because they had forgotten about the
first time.

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

From Newsgroup: comp.arch

George Neuner <gneuner2@comcast.net> writes:

On Wed, 03 Jun 2026 00:55:35 GMT, MitchAlsup ><user5857@newsgrouper.org.invalid> wrote:

quadi <quadibloc@ca.invalid> posted:

On Tue, 02 Jun 2026 17:50:38 +0200, Terje Mathisen wrote:

In the current environment where every language is expected to be
compatible with a generic IDE like Visual Studio Code, via open source >>> > interface specifications, having a proprietary debug format seems like a >>> > good way to strongly limit your potential customer base.

You appear to have understood his post in a different way than I did.

I wasn't thinking of the kind of debug information provided by a compiler. >>>
I was thinking of leaving debug information in when one was distributing >>> software to customers.

Yes, you the vendor do not want random customer debugging the code, >>however, you want the ability to debug the code that was distributed
on whatever medium on customer's system(s)--

AND you want to debug one copy of the running code while others are using >>other processes running the code under normal use.

That is true, but the issue at hand is how to achieve that. Leaving
debug information /in/ the executable, I think, is a bad idea.

However, many (most?) toolchains provide a way to separate debug
symbols from the executable - either by generating a separate symbol
database in the 1st place, or by allowing debug data to be stripped
from the executables. If you have to debug at the client site, you
simply take the symbol database with you.

Indeed, and that's been the common paradigm at my employers

I'll also note that many linux distributions include the debug
symbols for the distribution in optionally loaded packages.

Another useful method is to write out debug information as the program >executes and arrange that it either is suppressed or (alternatively)
goes to /dev/null unless some undocumented flag is given.

We arrange for the application to be able to be configured
(both statically before startup and dynamically during
runtime) to produce additional debug logging. Generally
arranged in the code to avoid significant impact to non-debug
performance (e.g. using __builtin_expect with GCC toolchains).

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.arch

On 6/4/2026 8:46 PM, Stefan Monnier wrote:

Scott Lurndal [2026-06-03 18:36:51] wrote:

Being able to debug code without the source code doesn't seem
a particulary common use case,

Indeed, the source code should also be available, of course.
I started this thread by mentioning Free Software. 🙂

Note that free does not equal open source. There is a fair amount of
software that is freely available for which the source is not. Many of
these are reduced functionality versions of paid for software, e.g.
Adobe PDF reader, but there are others.
--
- Stephen Fuld
(e-mail address disguised to prevent spam)
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.arch

On Sun, 07 Jun 2026 15:05:24 -0700, Stephen Fuld wrote:

Note that free does not equal open source. There is a fair amount of software that is freely available for which the source is not. Many of
these are reduced functionality versions of paid for software, e.g.
Adobe PDF reader, but there are others.

Commonly, when this distinction is discussed in the open-source community,
the phrases "free as in beer" and "free as in freedom" are used to
distinguish between freeware that remains proprietary versus true open-
source software under the GPL.

John Savard

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.arch

Stephen Fuld <sfuld@alumni.cmu.edu.invalid> writes:

On 6/4/2026 8:46 PM, Stefan Monnier wrote:

I started this thread by mentioning Free Software. 🙂

Note that free does not equal open source. There is a fair amount of >software that is freely available for which the source is not. Many of >these are reduced functionality versions of paid for software, e.g.
Adobe PDF reader, but there are others.

The Adobe PDF reader is chained software (aka proprietary software),
not free software.

In the appendix of "1984" George Orwell wrote:

|To give a single example, the word free still existed in Newspeak, but
|could only be used in such statements as "The dog is free from lice"
|or "This field is free from weeds." It could not be used in its old
|sense of "politically free" or "intellectually free," since political
|and intellectual freedom no longer existed even as concepts, and were |therefore of necessity nameless.

Some of us obviously already write and think in Newspeak.

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

From Newsgroup: comp.arch

On Mon, 8 Jun 2026 01:19:17 -0000 (UTC)
quadi <quadibloc@ca.invalid> wrote:

On Sun, 07 Jun 2026 15:05:24 -0700, Stephen Fuld wrote:

Note that free does not equal open source. There is a fair amount
of software that is freely available for which the source is not.
Many of these are reduced functionality versions of paid for
software, e.g. Adobe PDF reader, but there are others.

Commonly, when this distinction is discussed in the open-source
community, the phrases "free as in beer" and "free as in freedom" are
used to distinguish between freeware that remains proprietary versus
true open- source software under the GPL.

John Savard

I strongly disagree with statement that true open source software is
equivalent of GPL.

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.arch

Michael S wrote:

On Mon, 8 Jun 2026 01:19:17 -0000 (UTC)
quadi <quadibloc@ca.invalid> wrote:

On Sun, 07 Jun 2026 15:05:24 -0700, Stephen Fuld wrote:

Note that free does not equal open source. There is a fair amount
of software that is freely available for which the source is not.
Many of these are reduced functionality versions of paid for
software, e.g. Adobe PDF reader, but there are others.

Commonly, when this distinction is discussed in the open-source
community, the phrases "free as in beer" and "free as in freedom" are
used to distinguish between freeware that remains proprietary versus
true open- source software under the GPL.

John Savard

I strongly disagree with statement that true open source software is equivalent of GPL.

The obviously "most free" sw must be public domain, right?

Followed by free use but attribution required/requested?

Terje
--
- <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.arch

On 6/7/2026 11:05 PM, Anton Ertl wrote:

Stephen Fuld <sfuld@alumni.cmu.edu.invalid> writes:

On 6/4/2026 8:46 PM, Stefan Monnier wrote:

I started this thread by mentioning Free Software. 🙂

Note that free does not equal open source. There is a fair amount of
software that is freely available for which the source is not. Many of
these are reduced functionality versions of paid for software, e.g.
Adobe PDF reader, but there are others.

The Adobe PDF reader is chained software (aka proprietary software),
not free software.

I don't want to get into a semantic argument here. I don't know what
you mean by the term "chained software". I only meant that anyone
could use it without paying anything to anyone. In the sense that John
talked about, it is free beer.

If I misinterpreted Stefan's use of the word free, then I apologize.

In the appendix of "1984" George Orwell wrote:

|To give a single example, the word free still existed in Newspeak, but |could only be used in such statements as "The dog is free from lice"
|or "This field is free from weeds." It could not be used in its old
|sense of "politically free" or "intellectually free," since political
|and intellectual freedom no longer existed even as concepts, and were |therefore of necessity nameless.

Some of us obviously already write and think in Newspeak.

I hardly think that using the word free to mean "you don't have to pay
for it" is Newspeak.
--
- Stephen Fuld
(e-mail address disguised to prevent spam)
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.arch

Stephen Fuld <sfuld@alumni.cmu.edu.invalid> writes:

On 6/7/2026 11:05 PM, Anton Ertl wrote:

Stephen Fuld <sfuld@alumni.cmu.edu.invalid> writes:

On 6/4/2026 8:46 PM, Stefan Monnier wrote:

I started this thread by mentioning Free Software. 🙂

Note that free does not equal open source. There is a fair amount of
software that is freely available for which the source is not. Many of
these are reduced functionality versions of paid for software, e.g.
Adobe PDF reader, but there are others.

The Adobe PDF reader is chained software (aka proprietary software),
not free software.

I don't want to get into a semantic argument here. I don't know what
you mean by the term "chained software". I only meant that anyone
could use it without paying anything to anyone. In the sense that John >talked about, it is free beer.

Acroread sends basic telemetry to Adobe every time you use it,
so in a sense, it's not exactly free.

xpdf on the other hand....

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.arch

Stephen Fuld <sfuld@alumni.cmu.edu.invalid> writes:

On 6/7/2026 11:05 PM, Anton Ertl wrote:

Stephen Fuld <sfuld@alumni.cmu.edu.invalid> writes:

On 6/4/2026 8:46 PM, Stefan Monnier wrote:

I started this thread by mentioning Free Software. 🙂

Note that free does not equal open source. There is a fair amount of
software that is freely available for which the source is not. Many of
these are reduced functionality versions of paid for software, e.g.
Adobe PDF reader, but there are others.

The Adobe PDF reader is chained software (aka proprietary software),
not free software.

I don't want to get into a semantic argument here. I don't know what
you mean by the term "chained software".

Non-free software. I put the more commonly used term in parentheses.

I only meant that anyone
could use it without paying anything to anyone.

That's not what "free software" means. The four essential freedoms of
software are
<https://www.gnu.org/philosophy/free-sw.en.html#fs-definition>:

|* The freedom to run the program as you wish, for any purpose (freedom 0).
|
|* The freedom to study how the program works, and change it so it does
| your computing as you wish (freedom 1). Access to the source code is
| a precondition for this.
|
|* The freedom to redistribute copies so you can help others (freedom 2).
|
|* The freedom to distribute copies of your modified versions to others
| (freedom 3). By doing this you can give the whole community a chance
| to benefit from your changes. Access to the source code is a
| precondition for this.
|
|A program is free software if it gives users adequately all of these |freedoms. Otherwise, it is nonfree.

In the appendix of "1984" George Orwell wrote:

|To give a single example, the word free still existed in Newspeak, but
|could only be used in such statements as "The dog is free from lice"
|or "This field is free from weeds." It could not be used in its old
|sense of "politically free" or "intellectually free," since political
|and intellectual freedom no longer existed even as concepts, and were
|therefore of necessity nameless.

Some of us obviously already write and think in Newspeak.

I hardly think that using the word free to mean "you don't have to pay
for it" is Newspeak.

Orwell did not think about that meaning when he gave an example of
Newspeak use of "free", so if the meaning "gratis" for "free" existed
when he wrote the book in 1949, it was not widely-enough used to make
it into the book. In any case, the meaning "free from lice" existed
when Orwell wrote the book and still exists in Newspeak. Newspeak
does not introduce new meanings, but the elimines the "freedom"
meaning. And in your case, Newspeak obviously has been successful
(not the Ingsoc variant ("free from lice"), but the surveillance
capitalism variant ("you don't pay [money] for it")).

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

From Newsgroup: comp.arch

On Mon, 08 Jun 2026 09:25:32 +0300, Michael S wrote:

On Mon, 8 Jun 2026 01:19:17 -0000 (UTC)
quadi <quadibloc@ca.invalid> wrote:

On Sun, 07 Jun 2026 15:05:24 -0700, Stephen Fuld wrote:

Note that free does not equal open source. There is a fair amount of
software that is freely available for which the source is not. Many
of these are reduced functionality versions of paid for software,
e.g. Adobe PDF reader, but there are others.

Commonly, when this distinction is discussed in the open-source
community, the phrases "free as in beer" and "free as in freedom" are
used to distinguish between freeware that remains proprietary versus
true open- source software under the GPL.

I strongly disagree with statement that true open source software is equivalent of GPL.

I did not mean to imply that _only_ GPL-licensed software is truly open source. The GPL license is only the most common example. There is, as
another reply has already noted, also MIT-licensed software and public
domain software.

And the term "open source", of course, is broader than this, as well. It
isn't incorrect to use that term for any software the source code of which
is open to inspection, even if the software itself is proprietary.

John Savard

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.arch

On 6/8/2026 9:18 AM, Anton Ertl wrote:

Stephen Fuld <sfuld@alumni.cmu.edu.invalid> writes:

On 6/7/2026 11:05 PM, Anton Ertl wrote:

Stephen Fuld <sfuld@alumni.cmu.edu.invalid> writes:

On 6/4/2026 8:46 PM, Stefan Monnier wrote:

I started this thread by mentioning Free Software. 🙂

Note that free does not equal open source. There is a fair amount of
software that is freely available for which the source is not. Many of >>>> these are reduced functionality versions of paid for software, e.g.
Adobe PDF reader, but there are others.

The Adobe PDF reader is chained software (aka proprietary software),
not free software.

I don't want to get into a semantic argument here. I don't know what
you mean by the term "chained software".

Non-free software. I put the more commonly used term in parentheses.

OK.

I only meant that anyone
could use it without paying anything to anyone.

That's not what "free software" means. The four essential freedoms of software are
<https://www.gnu.org/philosophy/free-sw.en.html#fs-definition>:

|* The freedom to run the program as you wish, for any purpose (freedom 0).
|
|* The freedom to study how the program works, and change it so it does
| your computing as you wish (freedom 1). Access to the source code is
| a precondition for this.
|
|* The freedom to redistribute copies so you can help others (freedom 2).
|
|* The freedom to distribute copies of your modified versions to others
| (freedom 3). By doing this you can give the whole community a chance
| to benefit from your changes. Access to the source code is a
| precondition for this.
|
|A program is free software if it gives users adequately all of these |freedoms. Otherwise, it is nonfree.

That is certainly *a* definition. It is obviously your preferred
definition. But there are others.

snipped the Orwell quotation.

Can you accept that others might have a different definition without
insulting them? (I take the assertion that I am using Newspeak as an
insult.)
--
- Stephen Fuld
(e-mail address disguised to prevent spam)
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.arch

Indeed, the source code should also be available, of course.
I started this thread by mentioning Free Software. 🙂

Note that free does not equal open source. There is a fair amount of software that is freely available for which the source is not. Many of
these are reduced functionality versions of paid for software, e.g. Adobe
PDF reader, but there are others.

You may want to check on Wikipedia what is [Free Software](https://en.wikipedia.org/wiki/Free_software) before jumping
to conclusions.

I capitalized "Free Software" for a reason.


=== Stefan
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.arch

On Mon, 08 Jun 2026 16:18:37 GMT
anton@mips.complang.tuwien.ac.at (Anton Ertl) wrote:

Stephen Fuld <sfuld@alumni.cmu.edu.invalid> writes:

On 6/7/2026 11:05 PM, Anton Ertl wrote:

Stephen Fuld <sfuld@alumni.cmu.edu.invalid> writes:

On 6/4/2026 8:46 PM, Stefan Monnier wrote:

I started this thread by mentioning Free Software. 🙂

Note that free does not equal open source. There is a fair
amount of software that is freely available for which the source
is not. Many of these are reduced functionality versions of paid
for software, e.g. Adobe PDF reader, but there are others.

The Adobe PDF reader is chained software (aka proprietary
software), not free software.

I don't want to get into a semantic argument here. I don't know
what you mean by the term "chained software".

Non-free software. I put the more commonly used term in parentheses.

I only meant that anyone
could use it without paying anything to anyone.

That's not what "free software" means. The four essential freedoms of software are
<https://www.gnu.org/philosophy/free-sw.en.html#fs-definition>:

|* The freedom to run the program as you wish, for any purpose
(freedom 0). |
|* The freedom to study how the program works, and change it so it
does | your computing as you wish (freedom 1). Access to the source
code is | a precondition for this.
|
|* The freedom to redistribute copies so you can help others (freedom
2). |
|* The freedom to distribute copies of your modified versions to
others | (freedom 3). By doing this you can give the whole community
a chance | to benefit from your changes. Access to the source code
is a | precondition for this.
|
|A program is free software if it gives users adequately all of these |freedoms. Otherwise, it is nonfree.

In the appendix of "1984" George Orwell wrote:

|To give a single example, the word free still existed in
Newspeak, but |could only be used in such statements as "The dog
is free from lice" |or "This field is free from weeds." It could
not be used in its old |sense of "politically free" or
"intellectually free," since political |and intellectual freedom
no longer existed even as concepts, and were |therefore of
necessity nameless.

Some of us obviously already write and think in Newspeak.

I hardly think that using the word free to mean "you don't have to
pay for it" is Newspeak.

Orwell did not think about that meaning when he gave an example of
Newspeak use of "free", so if the meaning "gratis" for "free" existed
when he wrote the book in 1949, it was not widely-enough used to make
it into the book. In any case, the meaning "free from lice" existed
when Orwell wrote the book and still exists in Newspeak. Newspeak
does not introduce new meanings, but the elimines the "freedom"
meaning. And in your case, Newspeak obviously has been successful
(not the Ingsoc variant ("free from lice"), but the surveillance
capitalism variant ("you don't pay [money] for it")).

- anton

I tend to think that it was the other way around.
RMS invented a new meaning of the term "free software" and then he and
his devotees started to insist that it the the only correct meaning.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.arch

On Mon, 08 Jun 2026 15:19:57 GMT
scott@slp53.sl.home (Scott Lurndal) wrote:

Stephen Fuld <sfuld@alumni.cmu.edu.invalid> writes:

On 6/7/2026 11:05 PM, Anton Ertl wrote:

Stephen Fuld <sfuld@alumni.cmu.edu.invalid> writes:

On 6/4/2026 8:46 PM, Stefan Monnier wrote:

I started this thread by mentioning Free Software. 🙂

Note that free does not equal open source. There is a fair
amount of software that is freely available for which the source
is not. Many of these are reduced functionality versions of paid
for software, e.g. Adobe PDF reader, but there are others.

The Adobe PDF reader is chained software (aka proprietary
software), not free software.

I don't want to get into a semantic argument here. I don't know
what you mean by the term "chained software". I only meant that
anyone could use it without paying anything to anyone. In the sense
that John talked about, it is free beer.

Acroread sends basic telemetry to Adobe every time you use it,
so in a sense, it's not exactly free.

xpdf on the other hand....

I prefer SumatraPdf. GPL3, but not avalable outside Windows.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.arch

Anton Ertl [2026-06-08 16:18:37] wrote:

Stephen Fuld <sfuld@alumni.cmu.edu.invalid> writes:

I hardly think that using the word free to mean "you don't have to pay
for it" is Newspeak.

Orwell did not think about that meaning when he gave an example of
Newspeak use of "free", so if the meaning "gratis" for "free" existed
when he wrote the book in 1949, it was not widely-enough used to make
it into the book. In any case, the meaning "free from lice" existed
when Orwell wrote the book and still exists in Newspeak. Newspeak
does not introduce new meanings, but the elimines the "freedom"
meaning. And in your case, Newspeak obviously has been successful
(not the Ingsoc variant ("free from lice"), but the surveillance
capitalism variant ("you don't pay [money] for it")).

Well, Stephen is hardly using a recent meaning of the word "free".
According to the OED, "free" as in "free of charge" traces back to the
13th century, so it clearly existed in Orwell's time.

But yes, I find it demoralizing that people within the computer world
are still making this mistake, after more than 40 years of FSF.


=== Stefan
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.arch

Terje Mathisen [2026-06-08 11:45:51] wrote:

Michael S wrote:
The obviously "most free" sw must be public domain, right?

As with most things related to freedom ... it depends.

Public domain offers "more freedom" when you consider the point of view
of the developers, who can use that software any way they want with no restrictions at all.

But not when you consider the point of view of the end-users who may
receive code compiled/derived from that public domain source code with
no way to recover that public domain source code, or to change or fix
it. It may even be illegal to try to recover it (since the DMCA
disallows several forms of reverse engineering).

From that end-user point of view, the GPL arguably ensures "more
freedom" than public domain.


=== Stefan
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.arch

On 09/06/2026 00:03, Stefan Monnier wrote:

Anton Ertl [2026-06-08 16:18:37] wrote:

Stephen Fuld <sfuld@alumni.cmu.edu.invalid> writes:

I hardly think that using the word free to mean "you don't have to pay
for it" is Newspeak.

Orwell did not think about that meaning when he gave an example of
Newspeak use of "free", so if the meaning "gratis" for "free" existed
when he wrote the book in 1949, it was not widely-enough used to make
it into the book. In any case, the meaning "free from lice" existed
when Orwell wrote the book and still exists in Newspeak. Newspeak
does not introduce new meanings, but the elimines the "freedom"
meaning. And in your case, Newspeak obviously has been successful
(not the Ingsoc variant ("free from lice"), but the surveillance
capitalism variant ("you don't pay [money] for it")).

Well, Stephen is hardly using a recent meaning of the word "free".
According to the OED, "free" as in "free of charge" traces back to the
13th century, so it clearly existed in Orwell's time.

But yes, I find it demoralizing that people within the computer world
are still making this mistake, after more than 40 years of FSF.

It is not a mistake - it is merely a different but perfectly reasonable
use of the same word. The FSF has done (and continues to do) wonderful
things that are of huge benefit to the computing world, and I am a big
fan of what they term "Free Software". But they do not own the word
"free", nor do they have rights to determine the definition of the
phrase "free software". People can, and do, use the phrase meaning
"gratis software". In any discussion on the topic, it is good to be
entirely clear on the intended meanings - but that applies equally to
those who write "free software" meaning "libre software" and "free
software" meaning "gratis software". Neither are "mistaken", and both
can cause confusion. (In longer phrases, acronyms, or proper names of organisations, there should be no confusion - FOSS or FSF should be
clear to all.)

(As for the discussion about what is the most "free", or "libre",
licensing model - you can argue about it until you are blue in the face,
but no conclusion can be reached because it depends on the point of
view. Freedoms are always a balance and a tradeoff to some extent.)

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.arch

Michael S <already5chosen@yahoo.com> writes:

On Mon, 08 Jun 2026 16:18:37 GMT
anton@mips.complang.tuwien.ac.at (Anton Ertl) wrote:

Orwell did not think about that meaning when he gave an example of
Newspeak use of "free", so if the meaning "gratis" for "free" existed
when he wrote the book in 1949, it was not widely-enough used to make
it into the book. In any case, the meaning "free from lice" existed
when Orwell wrote the book and still exists in Newspeak. Newspeak
does not introduce new meanings, but the elimines the "freedom"
meaning. And in your case, Newspeak obviously has been successful
(not the Ingsoc variant ("free from lice"), but the surveillance
capitalism variant ("you don't pay [money] for it")).
=20
- anton

I tend to think that it was the other way around.
RMS invented a new meaning of the term "free software"

The story that I read was that all software originally was free in the
FSF sense (i.e., provided the four freedoms).[1] Then some people
removed some or all freedoms from some software, typically with the
goal of making money from the software. Removing the freedoms and yet
not asking for money is a later development; this has often been
called shareware or freeware, but Stephen Fuld is the first one I have
seen who has called it "free software", and actually misunderstood a
reference to "Free Software" (capitalized).

[1] As an example, <https://en.wikipedia.org/wiki/SHARE_(computing)>
states:

|Originally, IBM distributed what software it provided in source
|form[2][3][4] and systems programmers commonly made small local
|additions or modifications and exchanged them with other users.

All four freedoms were exercised here, more than two decades before
the Free Software Foundation.

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

From Newsgroup: comp.arch

Anton Ertl wrote:

Michael S <already5chosen@yahoo.com> writes:

On Mon, 08 Jun 2026 16:18:37 GMT
anton@mips.complang.tuwien.ac.at (Anton Ertl) wrote:

Orwell did not think about that meaning when he gave an example of
Newspeak use of "free", so if the meaning "gratis" for "free" existed
when he wrote the book in 1949, it was not widely-enough used to make
it into the book. In any case, the meaning "free from lice" existed
when Orwell wrote the book and still exists in Newspeak. Newspeak
does not introduce new meanings, but the elimines the "freedom"
meaning. And in your case, Newspeak obviously has been successful
(not the Ingsoc variant ("free from lice"), but the surveillance
capitalism variant ("you don't pay [money] for it")).
=20
- anton

I tend to think that it was the other way around.
RMS invented a new meaning of the term "free software"

The story that I read was that all software originally was free in the
FSF sense (i.e., provided the four freedoms).[1] Then some people
removed some or all freedoms from some software, typically with the
goal of making money from the software. Removing the freedoms and yet
not asking for money is a later development; this has often been
called shareware or freeware, but Stephen Fuld is the first one I have
seen who has called it "free software", and actually misunderstood a reference to "Free Software" (capitalized).

[1] As an example, <https://en.wikipedia.org/wiki/SHARE_(computing)>
states:

|Originally, IBM distributed what software it provided in source |form[2][3][4] and systems programmers commonly made small local
|additions or modifications and exchanged them with other users.

All four freedoms were exercised here, more than two decades before
the Free Software Foundation.

Yes, with one importnt restriction:

The software was free, but you could not use it except on IBM hardware,
which was quite expensive.

When clones started to appear (Amdahl?) I believe the free sw
disappeared, now it was explicitly licensed to only run on "real" IBM hardware?

Terje
--
- <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.arch

On 6/9/2026 12:15 PM, Terje Mathisen wrote:

Anton Ertl wrote:

Michael S <already5chosen@yahoo.com> writes:

On Mon, 08 Jun 2026 16:18:37 GMT
anton@mips.complang.tuwien.ac.at (Anton Ertl) wrote:

Orwell did not think about that meaning when he gave an example of
Newspeak use of "free", so if the meaning "gratis" for "free" existed
when he wrote the book in 1949, it was not widely-enough used to make
it into the book.  In any case, the meaning "free from lice" existed
when Orwell wrote the book and still exists in Newspeak.  Newspeak
does not introduce new meanings, but the elimines the "freedom"
meaning.  And in your case, Newspeak obviously has been successful
(not the Ingsoc variant ("free from lice"), but the surveillance
capitalism variant ("you don't pay [money] for it")).
=20
- anton

I tend to think that it was the other way around.
RMS invented a new meaning of the term "free software"

The story that I read was that all software originally was free in the
FSF sense (i.e., provided the four freedoms).[1] Then some people
removed some or all freedoms from some software, typically with the
goal of making money from the software.  Removing the freedoms and yet
not asking for money is a later development; this has often been
called shareware or freeware, but Stephen Fuld is the first one I have
seen who has called it "free software", and actually misunderstood a
reference to "Free Software" (capitalized).

[1] As an example, <https://en.wikipedia.org/wiki/SHARE_(computing)>
states:

|Originally, IBM distributed what software it provided in source
|form[2][3][4] and systems programmers commonly made small local
|additions or modifications and exchanged them with other users.

All four freedoms were exercised here, more than two decades before
the Free Software Foundation.

Yes, with one importnt restriction:

The software was free, but you could not use it except on IBM hardware, which was quite expensive.

When clones started to appear (Amdahl?) I believe the free sw
disappeared, now it was explicitly licensed to only run on "real" IBM hardware?

Sort of, but it was more complicated than that. In the 1960s (and
before), IBM "bundled" (i.e. it was freely included) all software with
the hardware. In 1969, the US government filed an anti-trust case
against IBM, claiming, among other things, monopolization of the
software market. One of the Government's goals was to support an
independent software market (which couldn't exist if IBM gave everything
away for free). The suit dragged on for years and was ultimately
withdrawn, but IBM was scared about what the suit could do. So it
initiated "unbundling" of software (and other things like education
classes), now charging separately for each software product the customer wanted. This was ultimately successful for the government, leading to
the success of companies like Syncsort (1971), and later several
competitive database systems (e.g Total, IDMS, etc.) But it also
allowed Amdahl (in 1971), and later other PCM hardware companies, to
sell competitive CPUs with the assurance that they could license the OS,
etc. from IBM.
--
- Stephen Fuld
(e-mail address disguised to prevent spam)
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.arch

Anton Ertl <anton@mips.complang.tuwien.ac.at> schrieb:

The story that I read was that all software originally was free in the
FSF sense (i.e., provided the four freedoms).[1]

There is an anecdote in "Abstracting Away the Machine".
IBM supplied a customer with its Fortran compiler (Fortran I at
the time). The customer noted that tape use was inefficient,
leading to longer than necessary compile times, and asked for
the source to improve it. Somebody at IBM refused, quipping "IBM
does not supply source code". So the customer went ahead, reverse
engieered the compiler and added the improvements anyway (which
were huge). When IBM noticed that, they asked for the improvement,
and the customer uipped back "$COMPANY does not supply object code",
and refused.

I'd have to search for the anecdote in the book to get the details
exactly right.
--
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

According to Stefan Monnier <monnier@iro.umontreal.ca>:

But not when you consider the point of view of the end-users who may
receive code compiled/derived from that public domain source code with
no way to recover that public domain source code, or to change or fix
it. It may even be illegal to try to recover it (since the DMCA
disallows several forms of reverse engineering).

If it's really public domain, there is no bar to reverse engineering
since there is nobody who can complain about it. I agree there are
other kinds of software where the executable is freely available but
the authors choose not to provide source and could use the DMCA
against people who reverse engineer.

From that end-user point of view, the GPL arguably ensures "more
freedom" than public domain.

I definitely agree with "arguably".

Speaking of the DMCA, the US Copyright Office is starting its tenth proceeding to update the list of exemptions to the DMCA for research, analysis and other non-infringing uses. Worth a look if you're interested in the topic.

https://www.copyright.gov/1201/2027/
--
Regards,
John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.arch

On Mon, 08 Jun 2026 17:44:59 -0400, Stefan Monnier
<monnier@iro.umontreal.ca> wrote:

Terje Mathisen [2026-06-08 11:45:51] wrote:

Michael S wrote:
The obviously "most free" sw must be public domain, right?

As with most things related to freedom ... it depends.

Public domain offers "more freedom" when you consider the point of view
of the developers, who can use that software any way they want with no >restrictions at all.

But not when you consider the point of view of the end-users who may
receive code compiled/derived from that public domain source code with
no way to recover that public domain source code, or to change or fix
it. It may even be illegal to try to recover it (since the DMCA
disallows several forms of reverse engineering).

From that end-user point of view, the GPL arguably ensures "more
freedom" than public domain.

=== Stefan

Not to mention that there are many countries that do not recognize
public domain. And even where it technically is recognized, some
countries have legal procedures that must be followed to relinquish
your rights and so complicate actually putting something into public
domain.

Putting <whatever> under some kind of license - regardless of how
permissive it is - actually is easier to do in many places, and is
recognized in more places.

MMV.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.arch

Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:

David Brown <david.brown@hesbynett.no> writes:

On 25/05/2026 16:28, Anton Ertl wrote:

Despite their eagerness to "optimize" based on the assumption
that signed integer overflow does not happen, the GCC developers have
avoided making -ftrap the default, even on platforms like MIPS and
Alpha where the implementation of -ftrapv just means to use different
instructions (e.g., add instead of addu on MIPS, and addv instead of
add on Alpha).

An awkward thing about using trap on overflow is determining how
precisely it is defined. Supposing you have the expression "a + b - a".
Perhaps "a + b" overflows. I would hope than when using debug-related >>compiler flags such as "-fsanitize=signed-integer-overflow", a compiler >>would check for overflow on "a + b", and report it at runtime. >>(Unfortunately, gcc does not do that unless the partial expression is >>assigned to a variable.) But in "normal" usage, I'd expect the
expression to be simplified, resulting in just "b" and no overflow.

OTOH, cases like a+b+c where the result is in range, while an
intermediate result is out of range are one of the reasons why I
prefer -fwrapv over -ftrapv. As for your preference of nasal demons,
given enough information, the compiler might "optimize" "a+b-a" into,
e.g., 0.

Anyway, the definition of -ftrapv is not very precise; for gcc-12.2:

|'-ftrapv'
| This option generates traps for signed overflow on addition,
| subtraction, multiplication operations.

As for what gcc-12.2 does for your example on AMD64:

long foo(long a, long b)
{
return a+b-a;
}

is compiled with gcc -O3 -ftrapv to:

0: 48 89 f0 mov %rsi,%rax
3: c3 ret

That is what I expect from '-ftrapv': running code should deliver
result as if using infinite precision arithmetic or overflow trap.
More tight specification could be that optimized code should not
generate overflow trap in cases when computing naively using C
semantics does not lead to overflow. Since the result above
agrees with result obtained using infinite precision arithmetic,
the code is fine and there is no need for runtime checks.

Of course, languages like C++ which turn traps into exceptions
and allow to use this as part of computations may have problem
here. More precisely, if they specify that overflow exception
must happen at given computational step, then optimizer may be
forced to generate code which is ther only to generate trap
and serves no other purpose. But the orignal intent of
overflow trap is to signal that real machine using fixed size
numbers can not deliver the same result as ideal machine
using infinte precion. If a language respects the intent,
then compiler can do a lot of optimizations.
--
Waldek Hebisch
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.arch

Thomas Koenig <tkoenig@netcologne.de> wrote:

Waldek Hebisch <antispam@fricas.org> schrieb:

Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:

MIPS' add traps on overflow. gcc could have emitted almost the same
code for gcc -O3 -trapv as for gcc -O3, except that the last
instruction would be an add, not an addu. But apparently nobody gives
a damn about the efficiency of -trapv, possibly rightly so.

My guess is that GCC developers care more about -trapv than about
MIPS.

It is a common misconception to treat GCC developers as a
monolithic group. There are hobbyists (such as myself) but
I would guess only a small minority of work is done by them,
with the notable exception of some front ends such as Fortran or
(the most recent example) Algol 68. There are employees by
different companies: Linux distributors like RedHat or Suse,
Large software companies like Google, hardware vendors like
IBM, Intel or Qualcomm, ...

Well, normal employees care about things that their employer
tells them to do. Whatever the reason GCC developers
(that is people contributing to GCC) each have their agenda,
care more about some things and less about other.

For MIPS, there are not so many active people and commits.
mips64-linux-gnu is a secondary platform, so if it fails
bootstrap, a release would be held up, but a wrong-code
regression will not.

Counting changes since 2025-01-01 in the gcc/config directories
can give a good idea of the relative activity for different
subdirectories; I cut this off below 7, where the PDP-11 is (note
that architecture names are often historical, so i386 includes
x86_64, s390 includes Z, rs6000 includes POWER and so on).

539 ./riscv
435 ./i386
432 ./aarch64
177 ./loongarch
100 ./arm
85 ./s390
75 ./avr
72 ./xtensa
60 ./rs6000
51 ./gcn
39 ./nvptx
25 ./sparc
25 ./mips
20 ./arc
19 ./pa
19 ./bpf
19 ./alpha
18 ./pru
15 ./sh
13 ./rx
13 ./cris
12 ./or1k
12 ./microblaze
12 ./m68k
11 ./lm32
11 ./ia64
11 ./h8300
9 ./vax
9 ./nds32
8 ./mcore
8 ./epiphany
8 ./c6x
7 ./visium
7 ./rl78
7 ./pdp11
7 ./frv
7 ./csky

AFAICS several architectures officialy supported by GCC
struggle to work at all. I suspect that maintainers of MIPS
backend are happy that -trapv works and do not have resources
to make it efficient.

First, they would need to know about this, which requires a PR,
but resources may well be lacking.

There are currently 28 open "missed-optimization" bugs with mips
in their target field. Looking at a few architectures above,
RISC-V has 118, x86 has 943, aarch64 has 305, power has 133.
(Some bugs affect more than one architecture, of course).

But it is worth submitting a PR nonetheless, if anybody cares enough :-)

Frankly, I do not care enough. I mean, I like fact that GCC
supports several architectures. But I have use of x86_64, arm (both
32 bit and 64-bit one), RISC-V and few embedded processors, that is
I have processors and can run GCC outout on them. I even have some
use of s390/z, that is I have emulator (Hercules) and have some
interst in software running inside emulator. But I have essentially
no use of MIPS.

And in slightly different spirit, IIRC there were cases when bug
reports caused reaction of sort "Yes, it is buggy. It would be
too much effort to fix it, so we will just remove support".
I support is removed, then work needed to revive an architecture
is likely to be significantly larger than in case of bitrotten,
but still in-tree architecture.
--
Waldek Hebisch
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.arch

David Brown [2026-06-09 10:06:48] wrote:

On 09/06/2026 00:03, Stefan Monnier wrote:

Well, Stephen is hardly using a recent meaning of the word "free".
According to the OED, "free" as in "free of charge" traces back to the
13th century, so it clearly existed in Orwell's time.
But yes, I find it demoralizing that people within the computer world
are still making this mistake, after more than 40 years of FSF.

It is not a mistake - it is merely a different but perfectly reasonable use of the same word.

In an arbitrary context, I could agree, but here we're talking about
a subthread that started with:

On Wed, 27 May 2026 10:59:31 -0400, Stefan Monnier wrote:
> MitchAlsup [2026-05-26 20:54:30] wrote:
>> Encrypt the debug information (and put it in a
>> {1234-5678-9101-1121-...} folder) so that only the owner (not
>> licensee) of the code can debug it.
> I resent that. All code should be Free Software.

I think there is no ambiguity here.

Treating this "Free Software" to refer to price rather than to freedom
is an error that can be explained only by a lack of familiarity with the
idea of software freedom.


=== Stefan
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.arch

On 11/06/2026 21:21, Stefan Monnier wrote:

David Brown [2026-06-09 10:06:48] wrote:

On 09/06/2026 00:03, Stefan Monnier wrote:

Well, Stephen is hardly using a recent meaning of the word "free".
According to the OED, "free" as in "free of charge" traces back to the
13th century, so it clearly existed in Orwell's time.
But yes, I find it demoralizing that people within the computer world
are still making this mistake, after more than 40 years of FSF.

It is not a mistake - it is merely a different but perfectly reasonable use >> of the same word.

In an arbitrary context, I could agree, but here we're talking about
a subthread that started with:

On Wed, 27 May 2026 10:59:31 -0400, Stefan Monnier wrote:
> MitchAlsup [2026-05-26 20:54:30] wrote:
>> Encrypt the debug information (and put it in a
>> {1234-5678-9101-1121-...} folder) so that only the owner (not
>> licensee) of the code can debug it.
> I resent that. All code should be Free Software.

I think there is no ambiguity here.

Treating this "Free Software" to refer to price rather than to freedom
is an error that can be explained only by a lack of familiarity with the
idea of software freedom.

Fair enough - I agree that in that context, the term "Free Software" is unambiguous. The capitalisation is important, and that was lost by the
post to which I replied. (There are a /lot/ of posts in this thread,
and when switching between two computers I have undoubtedly skipped many
of them.)

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.arch

According to George Neuner <gneuner2@comcast.net>:

As with most things related to freedom ... it depends.

Not to mention that there are many countries that do not recognize
public domain. And even where it technically is recognized, some
countries have legal procedures that must be followed to relinquish
your rights and so complicate actually putting something into public
domain.

I am not aware of any countries that do not have the public domain for
material whose copyright has expired, or for whatever reason was not
eligible for copyright in the first place. But you're right, in some
places it is impossible or at least impractical to relinquish your
rights and put something in the P.D. before it would get there anyway.

Putting <whatever> under some kind of license - regardless of how
permissive it is - actually is easier to do in many places, and is
recognized in more places.

Agreed. There are lots of licenses other than the GPL that are
used successfully for open source software.

R's,
John
--
Regards,
John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.arch

On Sat, 13 Jun 2026 03:01:00 -0000 (UTC), John Levine
<johnl@taugh.com> wrote:

According to George Neuner <gneuner2@comcast.net>:

As with most things related to freedom ... it depends.

Not to mention that there are many countries that do not recognize
public domain. And even where it technically is recognized, some
countries have legal procedures that must be followed to relinquish
your rights and so complicate actually putting something into public >>domain.

I am not aware of any countries that do not have the public domain for >material whose copyright has expired, or for whatever reason was not
eligible for copyright in the first place. But you're right, in some
places it is impossible or at least impractical to relinquish your
rights and put something in the P.D. before it would get there anyway.

The Berne convention defined an implicit copyright that exists by
virtue of authorship and persists until the author's death. Though
the US does not recognize or enforce these implicit copyrights, most signatories to either Berne (1886) or UCC (1952) conventions do
recognize and enforce Berne copyrights.

Explicit copyrights - filed with Copyright offices - can be
voluntarily surrendered at any time. It is giving up the implicit
copyright that is the problem with public domain.

Putting <whatever> under some kind of license - regardless of how >>permissive it is - actually is easier to do in many places, and is >>recognized in more places.

Agreed. There are lots of licenses other than the GPL that are
used successfully for open source software.

R's,
John

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.arch

George Neuner <gneuner2@comcast.net> writes:

The Berne convention defined an implicit copyright that exists by
virtue of authorship and persists until the author's death. Though
the US does not recognize or enforce these implicit copyrights, most >signatories to either Berne (1886) or UCC (1952) conventions do
recognize and enforce Berne copyrights.

According to <https://en.wikipedia.org/wiki/Berne_convention>:

|The United States acceded to the convention on 16 November 1988, and
|the convention entered into force for the United States on 1 March
|1989.

How can the convention have entered into force in the US without the
US recognizing or enforcing implicit copyrights?

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

From Newsgroup: comp.arch

On Sat, 13 Jun 2026 10:52:08 GMT, anton@mips.complang.tuwien.ac.at
(Anton Ertl) wrote:

George Neuner <gneuner2@comcast.net> writes:

The Berne convention defined an implicit copyright that exists by
virtue of authorship and persists until the author's death. Though
the US does not recognize or enforce these implicit copyrights, most >>signatories to either Berne (1886) or UCC (1952) conventions do
recognize and enforce Berne copyrights.

According to <https://en.wikipedia.org/wiki/Berne_convention>:

|The United States acceded to the convention on 16 November 1988, and
|the convention entered into force for the United States on 1 March
|1989.

How can the convention have entered into force in the US without the
US recognizing or enforcing implicit copyrights?

Implicit copyrights do exist now in the U.S. because of its
ratification of the Berne convention.

But there are some limitations.

Nothing that entered the public domain prior to this ratification
became copyrighted again; there was no retroactive effect.

Also, U.S. parties are still incentivized to register their
copyrights, because this is necessary to recieve statutory damages and attorney's fees from a copyright lawsuit.

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

From Newsgroup: comp.arch

John Levine <johnl@taugh.com> wrote:

According to George Neuner <gneuner2@comcast.net>:

As with most things related to freedom ... it depends.

Not to mention that there are many countries that do not recognize
public domain. And even where it technically is recognized, some
countries have legal procedures that must be followed to relinquish
your rights and so complicate actually putting something into public >>domain.

I am not aware of any countries that do not have the public domain for material whose copyright has expired,

My country (Poland) has a rule that once copyright has expired
distributior of work should pay royalites to the state. In
am not sure how it works in "interesting" case, but clearly
this is quite different from US/UK meaning of public domain.

Also, law of my country declares some author right as
untransfreable. Basically, author can sue if he/she/it
thinks that artistic integrity of the work is violated.
Theoretically, one could imagine some old, not longer commercialy
viable program to be released as public domain, new people fixing
old bugs and original developers suing that bug fixes deprive
users of orignal experience and hence violate artistic integrity.
Probably not going to work in court, but we had case when
sensible improvements to buildings were blocked by architects.

BTW. Our copyright law has notion of "area of exploration" and
states that copyright transfer is effective only for explicitely
transferred rights. All right in "areas of exploration" which
are not explicitely transferred stay with autors. I guess that
training LLM would count as new "area of exploration"...
--
Waldek Hebisch
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.arch

According to Waldek Hebisch <antispam@fricas.org>:

My country (Poland) has a rule that once copyright has expired
distributior of work should pay royalites to the state. In
am not sure how it works in "interesting" case, but clearly
this is quite different from US/UK meaning of public domain.

Do distributors pay state royalties on works of Shakespeare?
The Bible? Wow.

Also, law of my country declares some author right as
untransfreable. Basically, author can sue if he/she/it
thinks that artistic integrity of the work is violated.

Those are moral rights, introduced into Berne in the 1920s by
everyone's favorite copyright advocate, Benito Mussolini.

The US only recognizes moral rights for visual works like
paintings and sculpture. There was an interesting case in
2013 where the owner of a building containing artists' studios
who had allowed elaborate graffiti on the outside of the building
decided to tear it down, first whitewashing over the art. The
artists sued and won $6.7 million. https://en.wikipedia.org/wiki/5_Pointz

So don't let people doodle on your circuit boards, I guess.
--
Regards,
John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.arch

On Sat, 13 Jun 2026 15:07:00 -0000 (UTC), antispam@fricas.org (Waldek
Hebisch) wrote:

My country (Poland) has a rule that once copyright has expired
distributior of work should pay royalites to the state. In
am not sure how it works in "interesting" case, but clearly
this is quite different from US/UK meaning of public domain.

I once read a science-fiction story in which, after Earth joined an interplanetary confederation, works that were in the public domain
became works for which the United Nations could charge royalties to
people from other planets.

The story was a detective story. It wasn't Shakespeare, but instead
Bollywood movies that a criminal was modifying and re-selling to a
planet to the culture of which those movies were well suited.

Also, law of my country declares some author right as
untransfreable. Basically, author can sue if he/she/it
thinks that artistic integrity of the work is violated.

Most European countries recognize the moral rights of authors.

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

From Newsgroup: comp.arch

John Levine <johnl@taugh.com> wrote:

According to Waldek Hebisch <antispam@fricas.org>:

My country (Poland) has a rule that once copyright has expired
distributior of work should pay royalites to the state. In
am not sure how it works in "interesting" case, but clearly
this is quite different from US/UK meaning of public domain.

Do distributors pay state royalties on works of Shakespeare?
The Bible? Wow.

I am not sure how they handle what in english zone is called
"derived works". If they reproduce first edition of Shakespeare
work or say Gutenberg Bible distributors are supposed to pay
(and I think that they do pay). Copyright to currently sold
Bible is attributed to translators.
--
Waldek Hebisch
--- Synchronet 3.22a-Linux NewsLink 1.2