John Levine <johnl@taugh.com> writes:
>According to Scott Lurndal <slp53@pacbell.net>:
>>>> Look - we ran timesharing on a 8kw PDP-8 with up to 8 active dialup users
>>>> doing program development (basic, focal, assembler) and playing
>>>> games. This was in the 1970's.
>>>
>>>That's impressive. There would have to be bank switching for the
>>>machine to be able to address more than 4096 words, I guess.
>>>
>>>How was task switching accomplished? By swapping out each user's
>>>process?
>>
>>Effectively, yes. Each user got a 4kw field. A maxed out
>>PDP-8 had 8 fields; but TSS8 supported as few as two, which
>>meant that there was one for the monitor and one for user
>>code. ...
>
>There were 3-bit instruction field and data field registers, with the
>data field used for the target of indirectly addressed memory
>reference instructions. In principle you could have a program running
>code in one field and data in others. I am not aware of anyone doing
>that, but just using it for the monitor in one field to manage user
>programs in another.
>
>The PDP-8 was an amazing design that manged to hit a sweet spot of
>being complete enough to do serious work and simple enough to
>implement using individual transistors in 1965 for under $20K. The
>versions that ran TSS-8 were larger and more complicated, but not that
>much larger and only a little more complicated.

The micro-operate instructions were clever; each bit was a different
operation, often complementary. For example, one of the micro operate
groups had a CMA (ones-complement the accumulator) and IAC (Increment accumulator);
setting both would negate a twos complement value; used for subtraction
since there was no subtract instruction, so to subtract, you would add
the twos-complement negated augend to the addend.

scott@slp53.sl.home (Scott Lurndal) writes:
>anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
>>jgd@cix.co.uk (John Dallman) writes:
>>>MIPS belonged to SGI at the time. SGI believed in Itanium and halted MIPS
>>>development for several years. They realised in the end they were dead
>>>wrong, but were unable to catch up.
>>
>>It seems to me that they had trouble earlier. They just could not
>>compete in the GHz race like the others.
>
>I was there at the time. The R10k was as advanced as any competing
>CPU.

Yes, the R10K was fine. But after that, the others sped ahead, while
MIPS/SGI hardly advanced. According to
<https://en.wikipedia.org/wiki/R10000#R12000>, they cancelled a
project, and I remember news in this direction at the time, which is
what I meant with "trouble".

>It wasn't so much they believed in Itanium, rather at that
>time third party graphics for PC's were becoming competitive to
>SGI's bread-and-butter graphics workstations and the company
>was shifting towards the large origin systems. Itanium or
>an advanced version of the R14k were the choices and they
>chose the former (along with building an intel-based windows
>box).

Given the supercomputing-oriented nature of the Origins, the Itanium
may have provided ok performance. For a more general-purpose
workload, I wonder if an 800MHz R16000a was not faster than a 1GHz
Itanium II.

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

[Please do not mail me a copy of your followup]

John Levine <johnl@taugh.com> spake the secret code
<u1bqf3$2g9c$1@gal.iecc.com> thusly:

>The PDP-8 was an amazing design that manged to hit a sweet spot of
>being complete enough to do serious work and simple enough to
>implement using individual transistors in 1965 for under $20K. The
>versions that ran TSS-8 were larger and more complicated, but not that
>much larger and only a little more complicated.

For those interested in the evolution of the implementation of PDP
architectures, this book is online and is a great read:

"Computer Engineering: A DEC iew of Hardware Systems Design"
C. Gordon Bell, J. Craig Mudge, John E. McNamara
<https://bitsavers.org/pdf/dec/_Books/Bell-ComputerEngineering.pdf>
--
"The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline>
The Terminals Wiki <http://terminals-wiki.org>
The Computer Graphics Museum <http://computergraphicsmuseum.org>
Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com>

>>The PDP-8 was an amazing design that manged to hit a sweet spot of
>>being complete enough to do serious work and simple enough to
>>implement using individual transistors in 1965 for under $20K. The
>>versions that ran TSS-8 were larger and more complicated, but not that
>>much larger and only a little more complicated.
>
>For those interested in the evolution of the implementation of PDP
>architectures, this book is online and is a great read:
>
>"Computer Engineering: A DEC iew of Hardware Systems Design"
>C. Gordon Bell, J. Craig Mudge, John E. McNamara
><https://bitsavers.org/pdf/dec/_Books/Bell-ComputerEngineering.pdf>

Yup, I have my well worn paper copy right here. But I actually
programmed a PDP-8, from the switches among other ways, over 50
years ago.

--
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

On Friday, April 14, 2023 at 3:16:30 PM UTC-5, John Levine wrote:
> >>The PDP-8 was an amazing design that manged to hit a sweet spot of
> >>being complete enough to do serious work and simple enough to
> >>implement using individual transistors in 1965 for under $20K. The
> >>versions that ran TSS-8 were larger and more complicated, but not that
> >>much larger and only a little more complicated.
> >
> >For those interested in the evolution of the implementation of PDP
> >architectures, this book is online and is a great read:
> >
> >"Computer Engineering: A DEC iew of Hardware Systems Design"
> >C. Gordon Bell, J. Craig Mudge, John E. McNamara
> ><https://bitsavers.org/pdf/dec/_Books/Bell-ComputerEngineering.pdf>
> Yup, I have my well worn paper copy right here. But I actually
> programmed a PDP-8, from the switches among other ways, over 50
> years ago.
<
Mine was 51 years ago (1972) Science hall (now Scaife) extension
behind the 360/67 and aside the PDP-9.
> --
> Regards,
> John Levine, jo...@taugh.com, Primary Perpetrator of "The Internet for Dummies",
> Please consider the environment before reading this e-mail. https://jl.ly

John Dallman <jgd@cix.co.uk> schrieb:
> In article <u15k4t$3oi33$2@newsreader4.netcologne.de>,
> tkoenig@netcologne.de (Thomas Koenig) wrote:
>
>> I don't understand the "VLAs are evil" attitude that some people
>> have. The low amount of stack available, especially for threads,
>> is a severe disadvantage for some systems; MacOS is particularly
>> evil in that respect. You can hardly run a decent pthreads (or
>> OMP-) based program there.
>
> The default thread stack sizes on macOS are pretty small. You have to set
> the thread stack sizes when you create the threads.

Hard to make a good choice when you're not running pthreads, but rather
implementing OpenMP via pthreads...

One of the things that would make sense to libgfortran is to add
reasonable behavior on stack overflow. There is also a PR about this.

On Friday, April 14, 2023 at 4:22:12 PM UTC-5, Thomas Koenig wrote:
> John Dallman <j...@cix.co.uk> schrieb:
> > In article <u15k4t$3oi33$2...@newsreader4.netcologne.de>,
> > tko...@netcologne.de (Thomas Koenig) wrote:
> >
> >> I don't understand the "VLAs are evil" attitude that some people
> >> have. The low amount of stack available, especially for threads,
> >> is a severe disadvantage for some systems; MacOS is particularly
> >> evil in that respect. You can hardly run a decent pthreads (or
> >> OMP-) based program there.
> >
> > The default thread stack sizes on macOS are pretty small. You have to set
> > the thread stack sizes when you create the threads.
> Hard to make a good choice when you're not running pthreads, but rather
> implementing OpenMP via pthreads...
>
> One of the things that would make sense to libgfortran is to add
> reasonable behavior on stack overflow. There is also a PR about this.
<
A cactus stack, or move the stack to a more free area ?
<
Is this a problem with a 64-bit virtual address space ??
You can fit 4 billion 4GB stacks in a 64-bit VaS.

MitchAlsup wrote:
> On Friday, April 14, 2023 at 4:22:12 PM UTC-5, Thomas Koenig wrote:
>> John Dallman <j...@cix.co.uk> schrieb:
>>> In article <u15k4t$3oi33$2...@newsreader4.netcologne.de>,
>>> tko...@netcologne.de (Thomas Koenig) wrote:
>>>
>>>> I don't understand the "VLAs are evil" attitude that some people
>>>> have. The low amount of stack available, especially for threads,
>>>> is a severe disadvantage for some systems; MacOS is particularly
>>>> evil in that respect. You can hardly run a decent pthreads (or
>>>> OMP-) based program there.
>>> The default thread stack sizes on macOS are pretty small. You have to set
>>> the thread stack sizes when you create the threads.
>> Hard to make a good choice when you're not running pthreads, but rather
>> implementing OpenMP via pthreads...
>>
>> One of the things that would make sense to libgfortran is to add
>> reasonable behavior on stack overflow. There is also a PR about this.
> <
> A cactus stack, or move the stack to a more free area ?
> <
> Is this a problem with a 64-bit virtual address space ??
> You can fit 4 billion 4GB stacks in a 64-bit VaS.

Move wouldn't work as the prior stack locations have references.

One could do stack chaining whereby a thread hops onto a new
stack allocation extent if it overflows the prior one.
There are some tricky bits, like if the overflow occurs
while constructing a new call frame, and exception stack
unwind handlers have to "do the right thing".

But yeah, with a 64 bit virtual space, or even the 48 bit subset,
4GB stacks is the simplest all around.

It requires the OS has memory sections which have both
reserved and committed ranges, as Windows does,
as you don't want to have to allocate the worst case amount
of resources for each stack. At startup the thread reserves
a 4GB stack address range but only commits a tiny fraction.
And all these stack limits need to be copied into the
user mode thread header so they can be quickly accessed.

EricP <ThatWouldBeTelling@thevillage.com> writes:
>MitchAlsup wrote:
>> On Friday, April 14, 2023 at 4:22:12 PM UTC-5, Thomas Koenig wrote:
>>> John Dallman <j...@cix.co.uk> schrieb:
>>>> In article <u15k4t$3oi33$2...@newsreader4.netcologne.de>,
>>>> tko...@netcologne.de (Thomas Koenig) wrote:
>>>>
>>>>> I don't understand the "VLAs are evil" attitude that some people
>>>>> have. The low amount of stack available, especially for threads,
>>>>> is a severe disadvantage for some systems; MacOS is particularly
>>>>> evil in that respect. You can hardly run a decent pthreads (or
>>>>> OMP-) based program there.
>>>> The default thread stack sizes on macOS are pretty small. You have to set
>>>> the thread stack sizes when you create the threads.
>>> Hard to make a good choice when you're not running pthreads, but rather
>>> implementing OpenMP via pthreads...
>>>
>>> One of the things that would make sense to libgfortran is to add
>>> reasonable behavior on stack overflow. There is also a PR about this.
>> <
>> A cactus stack, or move the stack to a more free area ?
>> <
>> Is this a problem with a 64-bit virtual address space ??
>> You can fit 4 billion 4GB stacks in a 64-bit VaS.
>
>Move wouldn't work as the prior stack locations have references.
>
>One could do stack chaining whereby a thread hops onto a new
>stack allocation extent if it overflows the prior one.
>There are some tricky bits, like if the overflow occurs
>while constructing a new call frame, and exception stack
>unwind handlers have to "do the right thing".
>
>But yeah, with a 64 bit virtual space, or even the 48 bit subset,
>4GB stacks is the simplest all around.
>
>It requires the OS has memory sections which have both
>reserved and committed ranges, as Windows does,

With Posix systems (UNIX, Linux), each process has a
set of resource limits, which include the stack size
for the primary thread in the process. The kernel
will reserve that amount of space in the Virtual Address
space for the stack (plus not-present guard pages to
trap underflow or overflow).

A system call (setrlimit()) allows a process to alter the
limit, subject to system-wide hard limits (which generally
default to 'unlimited'). The shells have a ulimit command
that sets the resource limits for the shell, which are
inherited by any children, grandchildren, etc.

>as you don't want to have to allocate the worst case amount
>of resources for each stack.

Physical pages are allocated on demand, not preallocated.

For pthreads, the master thread can specify the stack size
for each subsequently created thread.

This capability dates back to 1989/1990 with SVR4.

On Saturday, April 8, 2023 at 3:17:55 AM UTC+2, BGB wrote:
> I had noted (when targeting x86-64) that MSVC often seems to be a bit
> faster.
>
> Build times for a program (ROTT):
> GCC: 17.06 seconds
> MSVC: 4.76 seconds
> BGBCC: 31.30 seconds
>
> So, BGBCC is apparently the slowest of this group at present...

You should really try a few things:
1) WSL2
2) on a native ext4 filesystem
3) with all the non-native directories removed from your PATH

Windows is notoriously slow at files and directories... and gcc/clang open lots of files (or try to) behind the scenes.

Don't upgrade to Windows 11 unless you are certain your CPU is supported. You can perform various kinds of magic to upgrade to Win 11 anyway but it's not worth it these days.

There was a period where it was, due to sorely needed WSL2 features being in Win 11 and not Win 10. For a while they were only in in prerelease versions of Win 11...

4) winget works ok now.
5) Windows Terminal is pretty good now.
6) VS Code is pretty good (also for working with files in a container or inside a WSL2 system). It also has a decent built-in terminal + debugger. They also work for WSL2.
7) you should upgrade to something like Ubuntu 22.04LTS (cat /etc/lsb-release to see your current version)
That gives you gcc-12 and clang-15.
8) X Just Works (almost -- there are a few minor glitches here and there). You don't need to run Xming.
9) perf can be made to work, mostly...
performance counters are virtualized now (at least on the Win 11 I'm running).
The hard part is to find/install a perf that works with the kernel version.
perf doesn't work as well as it would on a true Linux install -- there are some events that aren't available + you can't sample as fast as you can on a real machine.
Still, perf alone is worth spending some time fiddling with upgrades...
10) virtualization -- WSL2 requires enabling some sort of virtualization which conflicts with apps that don't yet use the new(ish) API for virtualization.
VirtualBox 6.x, for example. Microsoft's Hyper-V works fine (but I don't like the GUI). The new VirtualBox 7.0 also works fine.

Worth looking into, I think. You will get faster compiles, faster file I/O, newer compilers, nicer X, nicer VS Code, and perf!

-Peter

PS: perhaps worth reading:
https://devblogs.microsoft.com/commandline/

On Monday, April 3, 2023 at 8:39:14 PM UTC+2, Terje Mathisen wrote:
> https://queue.acm.org/detail.cfm?id=3588242
>
> Terje
> --
> - <Terje.Mathisen at tmsw.no>
> "almost all programming can be viewed as an exercise in caching"

The author doesn't quite seem to have understood the topic...

unreachable() is a good thing:

#ifdef NDEBUG
# define ASSERT(x) do { if (!x) unreachable(); } while(0)
#else
# define ASSERT(x) assert(x)
#endif

We can use it to tell the compiler about things that definitely aren't going to be true (we hope), which often leads to better code.
(There is prior art in the form of __builtin_unreachable() in gcc/clang and __assume(0) in msvc.)

bool/true/false/etc are not going to become keywords. They are going to become predefined macros -- so it is going to be easy to work with legacy code.

You in particular should really like _BitInt(n) and #embed and constexpr and '= {}'!

The only real issue is realloc(p, 0) which some people apparently liked. The example code is pretty crappy because it does far too much resizing. At least do doubling/halving! However, it turns out to be implementation-defined behaviour -- and implementations really did differ. I think C23 does the right thing here by closing that hole.

https://www.open-std.org/jtc1/sc22/wg14/www/docs/summary.htm#dr_400

https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2464.pdf

This blog by JeanHeyd Meneide is a wonderful source for C standards info -- he is the editor of the C23 standard:

https://thephd.dev/

In my opinion, C23 looks like a huge step forward :)

-Peter

Thanks Peter!

I can easily live with the realloc change, seeing that I have done
approximately 0 realloc() calls in my entire programming lifetime.

Terje

Peter Lund wrote:
> On Monday, April 3, 2023 at 8:39:14 PM UTC+2, Terje Mathisen wrote:
>> https://queue.acm.org/detail.cfm?id=3588242
>>
>> Terje
>> --
>> - <Terje.Mathisen at tmsw.no>
>> "almost all programming can be viewed as an exercise in caching"
>
> The author doesn't quite seem to have understood the topic...
>
> unreachable() is a good thing:
>
> #ifdef NDEBUG
> # define ASSERT(x) do { if (!x) unreachable(); } while(0)
> #else
> # define ASSERT(x) assert(x)
> #endif
>
> We can use it to tell the compiler about things that definitely aren't going to be true (we hope), which often leads to better code.
> (There is prior art in the form of __builtin_unreachable() in gcc/clang and __assume(0) in msvc.)
>
>
> bool/true/false/etc are not going to become keywords. They are going to become predefined macros -- so it is going to be easy to work with legacy code.
>
> You in particular should really like _BitInt(n) and #embed and constexpr and '= {}'!
>
> The only real issue is realloc(p, 0) which some people apparently liked. The example code is pretty crappy because it does far too much resizing. At least do doubling/halving! However, it turns out to be implementation-defined behaviour -- and implementations really did differ. I think C23 does the right thing here by closing that hole.
>
> https://www.open-std.org/jtc1/sc22/wg14/www/docs/summary.htm#dr_400
>
> https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2464.pdf
>
> This blog by JeanHeyd Meneide is a wonderful source for C standards info -- he is the editor of the C23 standard:
>
> https://thephd.dev/
>
> In my opinion, C23 looks like a huge step forward :)
>
> -Peter
>

--
- <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"

Scott Lurndal wrote:
> EricP <ThatWouldBeTelling@thevillage.com> writes:
>> MitchAlsup wrote:
>>> On Friday, April 14, 2023 at 4:22:12 PM UTC-5, Thomas Koenig wrote:
>>>> John Dallman <j...@cix.co.uk> schrieb:
>>>>> In article <u15k4t$3oi33$2...@newsreader4.netcologne.de>,
>>>>> tko...@netcologne.de (Thomas Koenig) wrote:
>>>>>
>>>>>> I don't understand the "VLAs are evil" attitude that some people
>>>>>> have. The low amount of stack available, especially for threads,
>>>>>> is a severe disadvantage for some systems; MacOS is particularly
>>>>>> evil in that respect. You can hardly run a decent pthreads (or
>>>>>> OMP-) based program there.
>>>>> The default thread stack sizes on macOS are pretty small. You have to set
>>>>> the thread stack sizes when you create the threads.
>>>> Hard to make a good choice when you're not running pthreads, but rather
>>>> implementing OpenMP via pthreads...
>>>>
>>>> One of the things that would make sense to libgfortran is to add
>>>> reasonable behavior on stack overflow. There is also a PR about this.
>>> <
>>> A cactus stack, or move the stack to a more free area ?
>>> <
>>> Is this a problem with a 64-bit virtual address space ??
>>> You can fit 4 billion 4GB stacks in a 64-bit VaS.
>> Move wouldn't work as the prior stack locations have references.
>>
>> One could do stack chaining whereby a thread hops onto a new
>> stack allocation extent if it overflows the prior one.
>> There are some tricky bits, like if the overflow occurs
>> while constructing a new call frame, and exception stack
>> unwind handlers have to "do the right thing".
>>
>> But yeah, with a 64 bit virtual space, or even the 48 bit subset,
>> 4GB stacks is the simplest all around.
>>
>> It requires the OS has memory sections which have both
>> reserved and committed ranges, as Windows does,
>
> With Posix systems (UNIX, Linux), each process has a
> set of resource limits, which include the stack size
> for the primary thread in the process. The kernel
> will reserve that amount of space in the Virtual Address
> space for the stack (plus not-present guard pages to
> trap underflow or overflow).
>
> A system call (setrlimit()) allows a process to alter the
> limit, subject to system-wide hard limits (which generally
> default to 'unlimited'). The shells have a ulimit command
> that sets the resource limits for the shell, which are
> inherited by any children, grandchildren, etc.
>
>> as you don't want to have to allocate the worst case amount
>> of resources for each stack.
>
> Physical pages are allocated on demand, not preallocated.

Right but certain resource availability should be checked
when an address range changes from reserve to commit.
E.g. we don't want to reserve page file space based on the
memory section reserve ranges but do so for the commit range.
There may be other such resources reserved or allocated
based on section commit range.

> For pthreads, the master thread can specify the stack size
> for each subsequently created thread.
>
> This capability dates back to 1989/1990 with SVR4.

EricP <ThatWouldBeTelling@thevillage.com> writes:
>Scott Lurndal wrote:
>> EricP <ThatWouldBeTelling@thevillage.com> writes:

>>
>> A system call (setrlimit()) allows a process to alter the
>> limit, subject to system-wide hard limits (which generally
>> default to 'unlimited'). The shells have a ulimit command
>> that sets the resource limits for the shell, which are
>> inherited by any children, grandchildren, etc.
>>
>>> as you don't want to have to allocate the worst case amount
>>> of resources for each stack.
>>
>> Physical pages are allocated on demand, not preallocated.
>
>Right but certain resource availability should be checked
>when an address range changes from reserve to commit.
>E.g. we don't want to reserve page file space based on the
>memory section reserve ranges but do so for the commit range.
>There may be other such resources reserved or allocated
>based on section commit range.

That depends. Some operating systems (AIX, if I recall
correctly, and Linux if configured) will overcommit memory
and produce a fault (SIGSEGV/SIGBUS) via the OOM killer
if a physical pageisn't available. This allows for large sparse
virtual address spaces.

On my system, I allow moderate overcommit:

$ cat /proc/sys/vm/overcommit_memory
0

Setting that variable to '2' will disable overcommit.

In article <2023Apr10.175439@mips.complang.tuwien.ac.at>,
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>David Brown <david.brown@hesbynett.no> writes:
>>On 10/04/2023 14:36, Anton Ertl wrote:
>>> David Brown <david.brown@hesbynett.no> writes:
>>>> On 04/04/2023 07:39, Anton Ertl wrote:
>[...]
>>#include <string.h>
>>
>>void * my_memmove(void * s1, const void * s2, size_t n) {
>> return memmove(s1, s2, n);
>>}
>>
>>There. Finished.
>
>Well done. Next:

:-)

>vadd(double *a, double *b, double c, size_t n)
>{
>/* write the equivalent of the Fortran a(1:n)=b(1:n)+c; note that the
> parameters are passed according to C rules, so a and b may or may
> not be pointers into the same array */
>}
>
>>As with any language, there are always things
>>that people would like to do in the language, but can't - the
>>alternative is that people will complain that the language (and/or
>>standard library) is too big.
>
>C already includes pointer comparison. Making it undefined for
>certain cases increases the things a programmer has to remember in
>order to use C, i.e., the language the programmer experiences becomes
>bigger.
>
>>(See C++ for evidence of that!)
>
>Does C++ define pointer comparison? I don't think so.

Why would you think that? Yes, it is unspecified and that is how we
read C and we saw the utility of doing better with the wording.

But, that is enough as one can then reliably do the pointer
comparisons necessary to ensure the memmove can be written, cleanly
and directly.

The entire point about C is a bit silly, only a hater of C could worry
about it as there are no implementations anywhere that anyone uses
that have a C compiler in which it would have given them a hard time
over this point. True today, true tomorrow, true for all future C
language standards, true for all future implementations that run C.

Only a historian with deep knowledge of the sins of the past might be
able to name an implementation for which there was ever any
complexity. Such a system might have once been rumored to exist, but
even the rumors fade with time.

Now, you willl come back that a person is free to create something
that claims to be C that breaks pointer comparisons, this is true, but
as irrelevant as that implementation.

But, I do agree with you. C should have always precisely and exactly
defined this in the language standard. They continue to fail us by
not improving the theoretic deficiency in the standard. But, as a
practicle matter, their failing is irrelevant, no one cares and it
doesn't matter to anyone. The standard should be read as the C++
language standard is read, at a minimum.

scott@slp53.sl.home (Scott Lurndal) writes:

[...]

> An array object that encompasses the entire virtual address space
> is easily defined on modern (nonsegmented) processors, in which case
> ptrdiff_t is defined for subtraction of any two virtual addresses.

The ISO C standard does not make that guarantee. A value of
type ptrdiff_t must be at least 17 bits, including the sign
bit. If subtraction of two pointers gives a value outside
the range of ptrdiff_t, the behavior is undefined.

scott@slp53.sl.home (Scott Lurndal) writes:

> Intel 4004 in 1971 was the first microprocessor.

Actually the first microprocessor was done in the
late 1960s, for military hardware (fighter jets IIRC)
but was classified until recently.

Terje Mathisen <terje.mathisen@tmsw.no> writes:

> David Brown wrote:
>
>> On 04/04/2023 07:39, Anton Ertl wrote:
>>
>>> One reason for comparing pointers is if you want to implement
>>> memmove(), as discussed in the article.
>>
>> memmove(), and other standard library functions, are part of the
>> implementation. They were traditionally implemented in assembly,
>> and only later in C. But as part of the implementation, they can
>> use features that are implementation-specific - there was never any
>> need or intention that such functions should be implementable in
>> portable standards-compliant C. The language never had any need to
>> support writing an efficient memmove() in C - it gave you a
>> ready-made memmove() function so that implementing it yourself is
>> not necessary.
>
> Is pointer comparison implementation defined (ID) or UB?

Any two pointers (including null pointers) may be compared for
equality or inequality. The result is well defined: either
they are the same, or they aren't, and the implementation has
nothing to say about it.

For relational comparisons, the two pointers must be pointers into
(or one past) the same array object. All other pointer pairs
(including either or both being a null pointer) fall into UB
if relationally compared.

> If it is ID, then I can write my own version of memmove() (or similar
> ops) on any given compiler, as long as I do it the way that particular
> compiler have defined it, right?
>
> If it is UB, then that's impossible, you have to step outside of the C
> standard to implement it, and do so in a way that makes it impossible
> for the compiler to discover that you have done so. :-)

This conclusion is wrong. It is possible to implement memmove() in
standard C using only well-defined comparisons. (I suppose I should
add that some people would object based on the belief that the means
of doing so is horrible, which I don't necessarily share, but either
way I still think it's worth pointing out that it's possible, and
even feasible.)

On 7/20/23 19:18, Tim Rentsch wrote:
> scott@slp53.sl.home (Scott Lurndal) writes:
>
>> Intel 4004 in 1971 was the first microprocessor.
>
> Actually the first microprocessor was done in the
> late 1960s, for military hardware (fighter jets IIRC)
> but was classified until recently.

Once owned a Honeywell mainframe terminal, poll / select type, that
had a set of 40 pin packages by Fairchild, called the "Basic Logic
Unit". Perhaps a for runner of the F8 series, but never found
anymore info on the set at the time. Date code 1969, but the earliest
Intel efforts were not single chip designs, and this preceded such by
quite wide margin...

Chris

On 7/20/23 21:50, Tim Rentsch wrote:
> Terje Mathisen <terje.mathisen@tmsw.no> writes:
>
>> David Brown wrote:
>>
>>> On 04/04/2023 07:39, Anton Ertl wrote:
>>>
>>>> One reason for comparing pointers is if you want to implement
>>>> memmove(), as discussed in the article.
>>>
>>> memmove(), and other standard library functions, are part of the
>>> implementation. They were traditionally implemented in assembly,
>>> and only later in C. But as part of the implementation, they can
>>> use features that are implementation-specific - there was never any
>>> need or intention that such functions should be implementable in
>>> portable standards-compliant C. The language never had any need to
>>> support writing an efficient memmove() in C - it gave you a
>>> ready-made memmove() function so that implementing it yourself is
>>> not necessary.
>>
>> Is pointer comparison implementation defined (ID) or UB?
>
> Any two pointers (including null pointers) may be compared for
> equality or inequality. The result is well defined: either
> they are the same, or they aren't, and the implementation has
> nothing to say about it.
>
> For relational comparisons, the two pointers must be pointers into
> (or one past) the same array object. All other pointer pairs
> (including either or both being a null pointer) fall into UB
> if relationally compared.
>
>> If it is ID, then I can write my own version of memmove() (or similar
>> ops) on any given compiler, as long as I do it the way that particular
>> compiler have defined it, right?
>>
>> If it is UB, then that's impossible, you have to step outside of the C
>> standard to implement it, and do so in a way that makes it impossible
>> for the compiler to discover that you have done so. :-)
>
> This conclusion is wrong. It is possible to implement memmove() in
> standard C using only well-defined comparisons. (I suppose I should
> add that some people would object based on the belief that the means
> of doing so is horrible, which I don't necessarily share, but either
> way I still think it's worth pointing out that it's possible, and
> even feasible.)

Programming in C or speaking natural language is fundamentally
about communication. If you want to be sure that the receiver
understands what you are saying, speak clearly and make no
assumptions about the receiver's knowledge.

Always program a strict subset of C here, no clever stuff
and most of it works first time, apart from typos. Saves
so much time in the long run. Can't be bothered doing
it right to start is the reason why we have so much bad code
to put up with...

Chris

Peter Lund <peterfirefly@gmail.com> writes:

> bool/true/false/etc are not going to become keywords.

In C23 they are.

> In my opinion, C23 looks like a huge step forward :)

I have no argument about it being a huge step. Which
direction the step is going is another matter.

Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>scott@slp53.sl.home (Scott Lurndal) writes:
>
>[...]
>
>> An array object that encompasses the entire virtual address space
>> is easily defined on modern (nonsegmented) processors, in which case
>> ptrdiff_t is defined for subtraction of any two virtual addresses.
>
>The ISO C standard does not make that guarantee.

I never made such a claim. This isn't comp.lang.c

scott@slp53.sl.home (Scott Lurndal) writes:

> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>
>> scott@slp53.sl.home (Scott Lurndal) writes:
>>
>> [...]
>>
>>> An array object that encompasses the entire virtual address space
>>> is easily defined on modern (nonsegmented) processors, in which case
>>> ptrdiff_t is defined for subtraction of any two virtual addresses.
>>
>> The ISO C standard does not make that guarantee.
>
> I never made such a claim.

I didn't say you did.

> This isn't comp.lang.c

I'm not trying to start a debate. My comment was offered
for the benefit of people who are interested in knowing
the facts. I believe that such people participate in this
newsgroup, and some of those may not read comp.lang.c.

chrisq <devzero@nospam.com> writes:

> On 7/20/23 21:50, Tim Rentsch wrote:

[regarding pointer comparison and memmove()]

>> It is possible to implement memmove() in standard C using only
>> well-defined comparisons. (I suppose I should add that some
>> people would object based on the belief that the means of doing
>> so is horrible, which I don't necessarily share, but either way I
>> still think it's worth pointing out that it's possible, and even
>> feasible.)
>
> Programming in C or speaking natural language is fundamentally
> about communication. If you want to be sure that the receiver
> understands what you are saying, speak clearly and make no
> assumptions about the receiver's knowledge.
>
> Always program a strict subset of C here, no clever stuff
> and most of it works first time, apart from typos. Saves
> so much time in the long run. Can't be bothered doing
> it right to start is the reason why we have so much bad code
> to put up with...

I don't necessarily agree with your advice, but whether
I do or not has no bearing on my comments.