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"

On Monday, April 3, 2023 at 1:39:14 PM UTC-5, Terje Mathisen wrote:
> https://queue.acm.org/detail.cfm?id=3588242
<
In my 38 years of writing C code, I, personally, have never used realloc()
(or calloc() BTW).
<
In all my future years of programming, I do not expect to compare pointers.
I haven't compared a pointer for the first 53 years of programming, why start
now ? Apparently I have a knack of writing code using pointers that does not
need pointer comparisons.
<
Also note: For the last 52 years I have not programmed a machine where
comparing pointers was "tricky"--I never used the segment stuff in x86-32.
{and thus remain un-brain-damaged or is that un-dame-bramaged.}
<
For the foreseeable future; I will not use machines that have tricky pointers.
The set of such machines are at least {x86-64, ARM, RISC-V, MIPS, VAX,
PDP-11, Nova, SPARC, IBM 360-3090, Mc 68K, Mc 88K, .....} It is not like you
are hurting your access to machines and architectures by making pointer
comparisons "easy".
<
Nor do I care if the C standards committee persists in seeing that C remains
compatible with architectures that are fundamentally against the large flat
linear address space.
<
Can we face facts: The large flat linear address space model has won--
Just like Little Endian has won--and that comparing pointers in a large
flat linear address space is "easy" and there is no reason to make the
language "special" in this way. Better to make the non LFLAS models
pay the cost (are there any left?? If there are, why can't they continue
to use C11 ??)
<
Now, I understand that languages have to evolve forward, And I, for one,
do not care that C23 is migrating even farther from C++, I might even
consider that a GOOD THING !!!
<
I still think in terms of K&R C, but have migrated to using the uinit46_t
spellings for typing.
>
> Terje
> --
> - <Terje.Mathisen at tmsw.no>
> "almost all programming can be viewed as an exercise in caching"

MitchAlsup <MitchAlsup@aol.com> writes:
>On Monday, April 3, 2023 at 1:39:14=E2=80=AFPM UTC-5, Terje Mathisen wrote:
>> https://queue.acm.org/detail.cfm?id=3D3588242=20
><
>In my 38 years of writing C code, I, personally, have never used realloc()
>(or calloc() BTW).

Likewise, albeit in 43 years of C programming.

><
>In all my future years of programming, I do not expect to compare pointers.

Except when comparing them to the null pointer (NULL), which technically
is 'comparing pointers' given the definition of NULL is usually (void *)0.

>I haven't compared a pointer for the first 53 years of programming, why sta=
>rt
>now ? Apparently I have a knack of writing code using pointers that does no=
>t
>need pointer comparisons.
><
>Also note: For the last 52 years I have not programmed a machine where
>comparing pointers was "tricky"--I never used the segment stuff in x86-32.
>{and thus remain un-brain-damaged or is that un-dame-bramaged.}

Unfortunately, the Burroughs mainframes I programmed had an
odd segmentation scheme (designed to allow backward compatability
with 1,000,000 digit address space limits from the original early
60's design, so pointers were rather tricky).

On Monday, April 3, 2023 at 4:36:27 PM UTC-5, Scott Lurndal wrote:
> MitchAlsup <Mitch...@aol.com> writes:
> >On Monday, April 3, 2023 at 1:39:14=E2=80=AFPM UTC-5, Terje Mathisen wrote:
> >> https://queue.acm.org/detail.cfm?id=3D3588242=20
> ><
> >In my 38 years of writing C code, I, personally, have never used realloc()
> >(or calloc() BTW).
> Likewise, albeit in 43 years of C programming.
> ><
> >In all my future years of programming, I do not expect to compare pointers.
> Except when comparing them to the null pointer (NULL), which technically
> is 'comparing pointers' given the definition of NULL is usually (void *)0..
<
Yes, but when written::
<
if( p ) { dereference( p ); }
or
if( !p ) { avoid_dereferencing( p ); }
<
it is not a comparison !!
<
{{ I fully agree that it is TECHNICALLY and PEDANTICALLY a comparison;
but it does not have a comparison operator in the source............................}}
>
>
> >I haven't compared a pointer for the first 53 years of programming, why sta=
> >rt
> >now ? Apparently I have a knack of writing code using pointers that does no> >t
> >need pointer comparisons.
> ><
> >Also note: For the last 52 years I have not programmed a machine where
> >comparing pointers was "tricky"--I never used the segment stuff in x86-32.
> >{and thus remain un-brain-damaged or is that un-dame-bramaged.}
<
> Unfortunately, the Burroughs mainframes I programmed had an
> odd segmentation scheme (designed to allow backward compatability
> with 1,000,000 digit address space limits from the original early
> 60's design, so pointers were rather tricky).
<
Never programmed on one (except in algol60 which likely does not count ).

On 3 Apr 2023, MitchAlsup wrote
(in article<a533d5c4-8dca-44eb-ba43-bf38ab7f9f34n@googlegroups.com>):

> I still think in terms of K&R C, but have migrated to using the
> uinit46_t
> spellings for typing.

Is that one of Quadibloc's types? 8-)

--
Bill Findlay

On Monday, April 3, 2023 at 5:16:07 PM UTC-5, Bill Findlay wrote:
> On 3 Apr 2023, MitchAlsup wrote
> (in article<a533d5c4-8dca-44eb...@googlegroups.com>):
> > I still think in terms of K&R C, but have migrated to using the
> > uinit46_t
> > spellings for typing.
> Is that one of Quadibloc's types? 8-)
<
yes and Woops !!
>
> --
> Bill Findlay

MitchAlsup <MitchAlsup@aol.com> writes:
> In my 38 years of writing C code, I, personally, have never used realloc()
> (or calloc() BTW).

So if you have a list of, I don't know, int's, and you add one more to the
list. What do you do instead of realloc() it to make room for another
addition?

Andy Valencia
Home page: https://www.vsta.org/andy/
To contact me: https://www.vsta.org/contact/andy.html

Terje Mathisen <terje.mathisen@tmsw.no> schrieb:
> https://queue.acm.org/detail.cfm?id=3588242

While I agree C could be better (who doesn't?) there are some
points in the article that I disagree with, others I agree with.

Paywalls - yes, that's a nuisance. Fortunately, as the article
implies, draft copies exist. (Not of the IEEE 754 standard,
it appears).

New keywords outside of the reserved space (leading underscores)
in a language like C, which reserves keywords, are not a good
idea in general because they tend to break existing code. I like
Fortran's approach better in such a case.

unreachable - I don't see the problem here. Removing code that
is not reachable where one branch has unreachable and all other
branches before also do not return is fine. It seems the authors
do not expect programmers to read or understand the control flow
of their programs.

realloc of zero-sized objects: Arguments on both sides. Breaking
existing code is bad, but having zero-size objects is something
I like (cf. Fortran, where these are first-class citicens).
I'd probably come down on the "don't change" side.

On 4/3/2023 10:23 PM, Andy Valencia wrote:
> MitchAlsup <MitchAlsup@aol.com> writes:
>> In my 38 years of writing C code, I, personally, have never used realloc()
>> (or calloc() BTW).
>
> So if you have a list of, I don't know, int's, and you add one more to the
> list. What do you do instead of realloc() it to make room for another
> addition?
>

I use realloc() and pointer comparison fairly often, among other things.

Of course, I haven't been writing code for quite that long...

I didn't do a whole lot of coding in my early years, not really getting
much into programming until after I was in elementary school (originally
in QBasic during the MS-DOS and Win 3.x era; started learning C by late
elem...). Much before that, it was a chaotic time that I don't really
remember.

But, yeah, didn't really entirely switch over to C until roughly middle
school, then mostly using a computer set to dual boot Linux and Windows
NT4, using Cygwin on the latter (before then switching over to Win2K and
using this for pretty much all of high school; during the era where for
most people Win98 started to give way to WinXP).

Prior to Linux+NT4, had been using Win95, but a great HDD crash lost
everything I had prior to this point. I think I went over to NT4 mostly
because I didn't want to reinstall Win95, and Win98's instability didn't
exactly appeal to me much either (at the time, another PC in the house
had been running Win98, so was already familiar with it).

But, all this was many decades ago... (and I am much older now...).

So, say, maybe 25 years of C coding, +/- a little...

> Andy Valencia
> Home page: https://www.vsta.org/andy/
> To contact me: https://www.vsta.org/contact/andy.html

On Tuesday, April 4, 2023 at 1:53:55 AM UTC-4, BGB wrote:
> On 4/3/2023 10:23 PM, Andy Valencia wrote:
> > MitchAlsup <Mitch...@aol.com> writes:
> >> In my 38 years of writing C code, I, personally, have never used realloc()
> >> (or calloc() BTW).
> >
> > So if you have a list of, I don't know, int's, and you add one more to the
> > list. What do you do instead of realloc() it to make room for another
> > addition?
> >
> I use realloc() and pointer comparison fairly often, among other things.
>
> Of course, I haven't been writing code for quite that long...
>
>
> I didn't do a whole lot of coding in my early years, not really getting
> much into programming until after I was in elementary school (originally
> in QBasic during the MS-DOS and Win 3.x era; started learning C by late
> elem...). Much before that, it was a chaotic time that I don't really
> remember.
>
> But, yeah, didn't really entirely switch over to C until roughly middle
> school, then mostly using a computer set to dual boot Linux and Windows
> NT4, using Cygwin on the latter (before then switching over to Win2K and
> using this for pretty much all of high school; during the era where for
> most people Win98 started to give way to WinXP).
>
> Prior to Linux+NT4, had been using Win95, but a great HDD crash lost
> everything I had prior to this point. I think I went over to NT4 mostly
> because I didn't want to reinstall Win95, and Win98's instability didn't
> exactly appeal to me much either (at the time, another PC in the house
> had been running Win98, so was already familiar with it).
>
>
> But, all this was many decades ago... (and I am much older now...).
>
> So, say, maybe 25 years of C coding, +/- a little...
> > Andy Valencia
> > Home page: https://www.vsta.org/andy/
> > To contact me: https://www.vsta.org/contact/andy.html

I do not use pointer comparison at all AFAIK. I do check for NULL pointers though.
Quite often use comparisons of objects pointed to, as in. p1->object == p2->object.
Because one does not generally know where in the heap an allocated object is
going to end up, it is not that useful to compare pointers for most code. I think I
have seen some code for garbage collection that compares pointers, but that is
a rare case.

MitchAlsup <MitchAlsup@aol.com> writes:
>On Monday, April 3, 2023 at 1:39:14=E2=80=AFPM UTC-5, Terje Mathisen wrote:
>> https://queue.acm.org/detail.cfm?id=3D3588242=20
><
>In my 38 years of writing C code, I, personally, have never used realloc()
>(or calloc() BTW).

I have.

>In all my future years of programming, I do not expect to compare pointers.
>I haven't compared a pointer for the first 53 years of programming, why sta=
>rt
>now ?

One reason for comparing pointers is if you want to implement
memmove(), as discussed in the article.

Another one (this one within standard-C confines) is walking through
an array with an idiom like this:

for (p=start; p<end; p++)
... *p ...

Another one was when unifying two free logic variables in a Prolog
implementation. We do this by letting one logic variable point to the
other, but which should point to which? The newer one should point to
the older, because the newer one may be deallocated earlier. With
stack allocation, we can find out by pointer comparison which one may
be deallocated earlier. If the stack was a single object in standard
C terms, this might be within its confines, but of course the Prolog
implementation (like pretty much all other production programs)
contained other things that have not been standardized in C, but which
the compilers of the day used to compile as intended.

In another case I needed an arbitrary total order of the objects (I
don't remember for what purpose), and the addresses of the objects
conveniently provided an order while the contents didn't. I remember
that this was in a Forth program, and in standard Forth you can
compare addresses.

>For the foreseeable future; I will not use machines that have tricky pointe=
>rs.
>The set of such machines are at least {x86-64, ARM, RISC-V, MIPS, VAX,
>PDP-11, Nova, SPARC, IBM 360-3090, Mc 68K, Mc 88K, .....}

I think you mean that these are machines that do not have tricky
pointers.

You do not mention IA-32. Is there any OS that exposes the potential
tricky pointers of IA-32 to user-level code?

One interesting aspect of the way IA-32 was designed was that they had
the segments as potentially overlapping extents in a 32-bit linear
address space.

My current take would be to treat the segments like ASIDs, i.e.,
extend the 32-bit address with 13 additional bits from the segment and
have a paging system that maps these 45-bit addresses to physical
memory; i.e., segments would be non-overlapping in this 45-bit address
space (paging could result in several segments sharing pages, and a
Unix would use this to implement, e.g., COW). This might have made it
unnecessary to add the PCID later. I guess it would not have
precluded PAE, unless they had catered for longer physical addresses
from the start. I have not worked out the ramifications of this idea,
so I might change my opinion once I have.

>Can we face facts: The large flat linear address space model has won--
>Just like Little Endian has won--and that comparing pointers in a large
>flat linear address space is "easy" and there is no reason to make the
>language "special" in this way. Better to make the non LFLAS models
>pay the cost (are there any left?? If there are, why can't they continue=20
>to use C11 ??)

C11, C99, and C89 are not any better wrt. comparing pointers. If you
want a language that has a flat address space, use Forth.

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

MitchAlsup <MitchAlsup@aol.com> schrieb:
> On Monday, April 3, 2023 at 1:39:14 PM UTC-5, Terje Mathisen wrote:
>> https://queue.acm.org/detail.cfm?id=3588242
><
> In my 38 years of writing C code, I, personally, have never used realloc()
> (or calloc() BTW).

Reading a line of arbitrary length (getline) is the canonical example,
I think.

[...]

> Can we face facts: The large flat linear address space model has won--
> Just like Little Endian has won--

With the difference that there are no longer segmented machines on the
market, and big-endian machines are still being sold. Less than before,
sure (and I don't think we will ever see a little-endian zSystem).

[...]

> Now, I understand that languages have to evolve forward, And I, for one,
> do not care that C23 is migrating even farther from C++, I might even
> consider that a GOOD THING !!!

The common subset isn't bad. C++ has been suffering from feature
stampede for decades...

On 2023-04-04 8:39, Anton Ertl wrote:
> MitchAlsup <MitchAlsup@aol.com> writes:
>> On Monday, April 3, 2023 at 1:39:14=E2=80=AFPM UTC-5, Terje Mathisen wrote:
>>> https://queue.acm.org/detail.cfm?id=3D3588242=20

[ snip ]

> C11, C99, and C89 are not any better wrt. comparing pointers. If you
> want a language that has a flat address space, use Forth.

Or use Ada. While you can compare Ada pointers ("access values") only
for equality, you can take the address of any object and compare
addresses in any way you like (=, <, >, ...). You can also convert an
address to a (dedicated predefined) integer type, do arithmetic on it,
and then convert the result back to an address or a pointer.

On Tuesday, April 4, 2023 at 12:18:32 PM UTC+3, Niklas Holsti wrote:
> On 2023-04-04 8:39, Anton Ertl wrote:
> > MitchAlsup <Mitch...@aol.com> writes:
> >> On Monday, April 3, 2023 at 1:39:14=E2=80=AFPM UTC-5, Terje Mathisen wrote:
> >>> https://queue.acm.org/detail.cfm?id=3D3588242=20
> [ snip ]
> > C11, C99, and C89 are not any better wrt. comparing pointers. If you
> > want a language that has a flat address space, use Forth.
> Or use Ada. While you can compare Ada pointers ("access values") only
> for equality, you can take the address of any object and compare
> addresses in any way you like (=, <, >, ...). You can also convert an
> address to a (dedicated predefined) integer type, do arithmetic on it,
> and then convert the result back to an address or a pointer.

Does Ada language guarantees persistence of address comparison?
I.e if address of object A is smaller than address of object B at one
one point in the program then the same holds for whole duration of the lifetime
of A and B?
If it's true it effectively disallows any form of GC that does memory compaction.

On Tuesday, April 4, 2023 at 3:21:47 PM UTC+3, Michael S wrote:
> On Tuesday, April 4, 2023 at 12:18:32 PM UTC+3, Niklas Holsti wrote:
> > On 2023-04-04 8:39, Anton Ertl wrote:
> > > MitchAlsup <Mitch...@aol.com> writes:
> > >> On Monday, April 3, 2023 at 1:39:14=E2=80=AFPM UTC-5, Terje Mathisen wrote:
> > >>> https://queue.acm.org/detail.cfm?id=3D3588242=20
> > [ snip ]
> > > C11, C99, and C89 are not any better wrt. comparing pointers. If you
> > > want a language that has a flat address space, use Forth.
> > Or use Ada. While you can compare Ada pointers ("access values") only
> > for equality, you can take the address of any object and compare
> > addresses in any way you like (=, <, >, ...). You can also convert an
> > address to a (dedicated predefined) integer type, do arithmetic on it,
> > and then convert the result back to an address or a pointer.
> Does Ada language guarantees persistence of address comparison?
> I.e if address of object A is smaller than address of object B at one
> one point in the program then the same holds for whole duration of the lifetime
> of A and B?
> If it's true it effectively disallows any form of GC that does memory compaction.

Well, thinking about it, the statement above is incorrect.
Compaction without exchanging order of object in memory is perfectly possible.
Also, arbitrary compaction is possible if 'address of object'
returns address of object's descriptor which (descriptor) does not have
to be adjacent in memory to object's bulk.
Sometimes, before posting, I should remind to myself that there
is more than one way to skin a cat.

MitchAlsup <MitchAlsup@aol.com> writes:
>On Monday, April 3, 2023 at 4:36:27=E2=80=AFPM UTC-5, Scott Lurndal wrote:
>> MitchAlsup <Mitch...@aol.com> writes:=20
>> >On Monday, April 3, 2023 at 1:39:14=3DE2=3D80=3DAFPM UTC-5, Terje Mathis=
>en wrote:=20
>> >> https://queue.acm.org/detail.cfm?id=3D3D3588242=3D20
>> ><=20
>> >In my 38 years of writing C code, I, personally, have never used realloc=
>()=20
>> >(or calloc() BTW).
>> Likewise, albeit in 43 years of C programming.
>> ><=20
>> >In all my future years of programming, I do not expect to compare pointe=
>rs.
>> Except when comparing them to the null pointer (NULL), which technically=
>=20
>> is 'comparing pointers' given the definition of NULL is usually (void *)0=
>.=20
><
>Yes, but when written::
><
> if( p ) { dereference( p ); }
>or
> if( !p ) { avoid_dereferencing( p ); }

I personally never use that style, reserving it
for boolean (particularly in C++) comparisons, I always
explicitly check for "== NULL".

><
>> Unfortunately, the Burroughs mainframes I programmed had an=20
>> odd segmentation scheme (designed to allow backward compatability=20
>> with 1,000,000 digit address space limits from the original early=20
>> 60's design, so pointers were rather tricky).
><
>Never programmed on one (except in algol60 which likely does not count ).

ALGOL was on the large systems family (48-bit, stack architecture). I
worked on the medium systems family (addressible to the digit, no
binary arithmetic).

Andy Valencia <vandys@vsta.org> writes:
>MitchAlsup <MitchAlsup@aol.com> writes:
>> In my 38 years of writing C code, I, personally, have never used realloc()
>> (or calloc() BTW).
>
>So if you have a list of, I don't know, int's, and you add one more to the
>list. What do you do instead of realloc() it to make room for another
>addition?

I have never needed to have a variable sized table of ints in 43 years of C programming.

On 2023-04-04 15:21, Michael S wrote:
> On Tuesday, April 4, 2023 at 12:18:32 PM UTC+3, Niklas Holsti wrote:
>> On 2023-04-04 8:39, Anton Ertl wrote:
>>> MitchAlsup <Mitch...@aol.com> writes:
>>>> On Monday, April 3, 2023 at 1:39:14=E2=80=AFPM UTC-5, Terje Mathisen wrote:
>>>>> https://queue.acm.org/detail.cfm?id=3D3588242=20
>> [ snip ]
>>> C11, C99, and C89 are not any better wrt. comparing pointers. If you
>>> want a language that has a flat address space, use Forth.
>> Or use Ada. While you can compare Ada pointers ("access values") only
>> for equality, you can take the address of any object and compare
>> addresses in any way you like (=, <, >, ...). You can also convert an
>> address to a (dedicated predefined) integer type, do arithmetic on it,
>> and then convert the result back to an address or a pointer.
>
> Does Ada language guarantees persistence of address comparison?
> I.e if address of object A is smaller than address of object B at one
> one point in the program then the same holds for whole duration of the lifetime
> of A and B?

Those are good questions that I don't remember ever seeing discussed for
Ada. I'll post a question on comp.lang.ada and report back.

> If it's true it effectively disallows any form of GC that does
> memory compaction.

I don't know of any current Ada programming system that provides garbage
collection based on pointer tracing. The defunct port of the GNAT Ada
compiler to the Java Virtual Machine surely did that, but I don't know
in what form and how it would affect this question. There are reports
that the Boehm conservative collector has been used successfully for Ada
programs, but it is not clear to me if that collector does compaction.
It is said to have generational collection, which I believe does usually
involve copying (moving) objects, and that would change addresses.

On 2023-04-04 15:40, Michael S wrote:
> On Tuesday, April 4, 2023 at 3:21:47 PM UTC+3, Michael S wrote:
>> On Tuesday, April 4, 2023 at 12:18:32 PM UTC+3, Niklas Holsti wrote:
>>> On 2023-04-04 8:39, Anton Ertl wrote:
>>>> MitchAlsup <Mitch...@aol.com> writes:
>>>>> On Monday, April 3, 2023 at 1:39:14=E2=80=AFPM UTC-5, Terje Mathisen wrote:
>>>>>> https://queue.acm.org/detail.cfm?id=3D3588242=20
>>> [ snip ]
>>>> C11, C99, and C89 are not any better wrt. comparing pointers. If you
>>>> want a language that has a flat address space, use Forth.
>>> Or use Ada. While you can compare Ada pointers ("access values") only
>>> for equality, you can take the address of any object and compare
>>> addresses in any way you like (=, <, >, ...). You can also convert an
>>> address to a (dedicated predefined) integer type, do arithmetic on it,
>>> and then convert the result back to an address or a pointer.
>> Does Ada language guarantees persistence of address comparison?
>> I.e if address of object A is smaller than address of object B at one
>> one point in the program then the same holds for whole duration of the lifetime
>> of A and B?
>> If it's true it effectively disallows any form of GC that does memory compaction.
>
> Well, thinking about it, the statement above is incorrect.
> Compaction without exchanging order of object in memory is perfectly possible.

Yes, but if you have generational collection that moves objects between
generations and sometimes swaps the generation spaces, it seems
impossible to preserve the order in all cases.

> Also, arbitrary compaction is possible if 'address of object'
> returns address of object's descriptor which (descriptor) does not have
> to be adjacent in memory to object's bulk.

Right, but as one can take the address of any element of an array --
A(I)'Address -- that would require separate descriptors for each
element, which is not very practical. In fact, the Ada standard strongly
recommends that the address of an array -- A'Address -- should equal the
address of the first array element -- A(A'First)'Address) rather than
the address of the "array descriptor" (if there is one).

Niklas Holsti <niklas.holsti@tidorum.invalid> writes:

> There are reports that the
> Boehm conservative collector has been used successfully for Ada programs,
> but it is not clear to me if that collector does compaction.

A conservative collector can't do compaction, it doesn't know for sure if a
bit pattern is a pointer or not.

Yours,

--
Jean-Marc

Terje Mathisen wrote:
> https://queue.acm.org/detail.cfm?id=3588242
>
> Terje

I did not think the authors use of !!num idiom would produce optimal
code and was curious whether the optimizer would figure it out anyway
so I ran it through godbolt x86-64 gcc 12.2 -O3 (it did not)

// Authors version using !!num
typedef unsigned long Num_t;
Num_t Foo (Num_t ndogs, Num_t ncats, Num_t nfish)
{ Num_t petFee;

petFee =
!!ndogs * (10 + (ndogs-1) * 5)
+ !!ncats * ( 7 + (ncats-1) * 3)
+ !!nfish * (47 + (nfish-1) * 1);

return petFee;
}

// My no !!num version
Num_t Bar (Num_t ndogs, Num_t ncats, Num_t nfish)
{ Num_t petFee;

petFee =
(ndogs ? ndogs*5 + 5 : 0) +
(ncats ? ncats*3 + 4 : 0) +
(nfish ? nfish + 46 : 0);

return petFee;
}

# Compilation provided by Compiler Explorer at https://godbolt.org/
Foo(unsigned long, unsigned long, unsigned long):
xor ecx, ecx
test rsi, rsi
lea rax, [rsi+4+rsi*2]
setne cl
imul rax, rcx
xor ecx, ecx
test rdx, rdx
setne cl
add rdx, 46
imul rdx, rcx
xor ecx, ecx
add rax, rdx
test rdi, rdi
lea rdx, [rdi+1]
setne cl
imul rdx, rcx
lea rdx, [rdx+rdx*4]
add rax, rdx
ret

Bar(unsigned long, unsigned long, unsigned long):
mov rax, rdi
test rdi, rdi
je .L4
lea rax, [rdi+5+rdi*4]
..L4:
test rsi, rsi
je .L5
lea rcx, [rsi+4+rsi*2]
add rax, rcx
..L5:
lea rcx, [rax+46+rdx]
test rdx, rdx
cmovne rax, rcx
ret

I could not get gcc to generate a non-branching
version using CMOVs, for example:

// My non-branching version
Bar(unsigned long, unsigned long, unsigned long):
// ndogs: rdi ncats: rsi nfish: rdx
lea rax, [rdi+rdi*4+5]
test rdi, rdi
cmove rax, rdi // if rdi==0 we can use it to source 0
lea rcx, [rsi+rsi*2+4]
add rcx, rax
test rsi, rsi
cmovne rax, rcx
lea rcx, [rax+rdx+46]
test rdx, rdx
cmovne rax, rcx
ret

On 4/4/2023 8:42 AM, Scott Lurndal wrote:
> Andy Valencia <vandys@vsta.org> writes:
>> MitchAlsup <MitchAlsup@aol.com> writes:
>>> In my 38 years of writing C code, I, personally, have never used realloc()
>>> (or calloc() BTW).
>>
>> So if you have a list of, I don't know, int's, and you add one more to the
>> list. What do you do instead of realloc() it to make room for another
>> addition?
>
> I have never needed to have a variable sized table of ints in 43 years of C programming.

Sometimes they are a better option than a linked list or tree structure...

So, I consider "realloc()" to be a reasonably useful feature.

I also consider relative comparison between arbitrary unrelated pointers
as a "this needs to work as usually expected" feature (comparison based
on address). Albeit in BGBCC with bounds-checks or similar enabled, this
does mean that internally the pointers need to have their tag bits
stripped off for the comparison to work correctly (though, could maybe
consider a "SUBA" instruction or similar, which subtracts two pointers
and also sign-extends over the tag bits as-if both pointers had their
tag bits set to zero).

....

In some contexts, a tree-like structure for arrays does have the
advantage that it can support creation and destruction of potentially
dynamically-sized arrays without leading to excessive memory
fragmentation, which is one potential downside of resizing things with
realloc.

Granted, in cases where I had used realloc() for dynamically sized
arrays, they had usually followed an "sz1=sz0+(sz0>>1);" pattern.

For some other contexts, I have used microfloats. Also my memory
managers often use microfloats for representing object sizes internally
(often E5.F3 or similar).

Albeit with the allocation strategy varying some based on object size, say:
Under 512B: Series of 16-byte cells managed by a bitmap;
512B..128K: Use variable-sized memory blocks within a larger region;
128K+: Use memory pages for the allocation.

....

BGB <cr88192@gmail.com> writes:
>On 4/4/2023 8:42 AM, Scott Lurndal wrote:
>> Andy Valencia <vandys@vsta.org> writes:
>>> MitchAlsup <MitchAlsup@aol.com> writes:
>>>> In my 38 years of writing C code, I, personally, have never used realloc()
>>>> (or calloc() BTW).
>>>
>>> So if you have a list of, I don't know, int's, and you add one more to the
>>> list. What do you do instead of realloc() it to make room for another
>>> addition?
>>
>> I have never needed to have a variable sized table of ints in 43 years of C programming.
>
>Sometimes they are a better option than a linked list or tree structure...

Examples would be useful, other than academic exercises.

>
>So, I consider "realloc()" to be a reasonably useful feature.

It is used under-the-covers in C code generated by lex(1), I've noticed
(albeit wrapped by yyrealloc) when parsing.

>
>I also consider relative comparison between arbitrary unrelated pointers
>as a "this needs to work as usually expected" feature (comparison based
>on address).

Seems prone to error. If your pointers reference elements in a contiguous array, that's
one thing. If they're allocated via some allocator, that's a case prone to
fail eventually. Comparing for equality or NULL is the only nonproblematic usage.

On Monday, April 3, 2023 at 10:24:41 PM UTC-5, Andy Valencia wrote:
> MitchAlsup <Mitch...@aol.com> writes:
> > In my 38 years of writing C code, I, personally, have never used realloc()
> > (or calloc() BTW).
> So if you have a list of, I don't know, int's, and you add one more to the
> list. What do you do instead of realloc() it to make room for another
> addition?
<
Malloc and linked lists.
<
I never use vectors of structs unless the length of the vector is fixed
at compile time. When unbounded or unknown, I use pointers lnked
lists.
>
> Andy Valencia
> Home page: https://www.vsta.org/andy/
> To contact me: https://www.vsta.org/contact/andy.html

On Tuesday, April 4, 2023 at 1:29:19 AM UTC-5, Anton Ertl wrote:
> MitchAlsup <Mitch...@aol.com> writes:
> >On Monday, April 3, 2023 at 1:39:14=E2=80=AFPM UTC-5, Terje Mathisen wrote:
> >> https://queue.acm.org/detail.cfm?id=3D3588242=20
> ><
> >In my 38 years of writing C code, I, personally, have never used realloc()
> >(or calloc() BTW).
> I have.
> >In all my future years of programming, I do not expect to compare pointers.
> >I haven't compared a pointer for the first 53 years of programming, why sta=
> >rt
> >now ?
>
> One reason for comparing pointers is if you want to implement
> memmove(), as discussed in the article.
<
Memmove() is free to implement pointer comparison, and I can use
memmove (but mainly I use struct assignment and let the compiler
figure it out.) But I did not write memmove(), but in my ISA there is
an MM instruction where HW does the pointer compares.
<
In my uses of memmove() it is structurally equal to memcpy().
>
> Another one (this one within standard-C confines) is walking through
> an array with an idiom like this:
>
> for (p=start; p<end; p++)
> ... *p ...
<
for( i = 0; i<max; i++ )
array[i] ...
<
I actually write array code that looks like array code.
>
> Another one was when unifying two free logic variables in a Prolog
> implementation. We do this by letting one logic variable point to the
> other, but which should point to which? The newer one should point to
> the older, because the newer one may be deallocated earlier. With
> stack allocation, we can find out by pointer comparison which one may
> be deallocated earlier. If the stack was a single object in standard
> C terms, this might be within its confines, but of course the Prolog
> implementation (like pretty much all other production programs)
> contained other things that have not been standardized in C, but which
> the compilers of the day used to compile as intended.
>
> In another case I needed an arbitrary total order of the objects (I
> don't remember for what purpose), and the addresses of the objects
> conveniently provided an order while the contents didn't. I remember
> that this was in a Forth program, and in standard Forth you can
> compare addresses.
<
Remember, I do not ever expect to use a machine where pointer
comparisons are tricky, nor do I even expect to create sell or give
away code that will be run on such a machine.
>
> >For the foreseeable future; I will not use machines that have tricky pointe> >rs.
> >The set of such machines are at least {x86-64, ARM, RISC-V, MIPS, VAX,
> >PDP-11, Nova, SPARC, IBM 360-3090, Mc 68K, Mc 88K, .....}
> I think you mean that these are machines that do not have tricky
> pointers.
>
> You do not mention IA-32. Is there any OS that exposes the potential
> tricky pointers of IA-32 to user-level code?
<
Not that I would be using.
>
> One interesting aspect of the way IA-32 was designed was that they had
> the segments as potentially overlapping extents in a 32-bit linear
> address space.
<
A poor feature that causes dame-branage.
>
> My current take would be to treat the segments like ASIDs, i.e.,
> extend the 32-bit address with 13 additional bits from the segment and
> have a paging system that maps these 45-bit addresses to physical
> memory; i.e., segments would be non-overlapping in this 45-bit address
> space (paging could result in several segments sharing pages, and a
> Unix would use this to implement, e.g., COW). This might have made it
> unnecessary to add the PCID later. I guess it would not have
> precluded PAE, unless they had catered for longer physical addresses
> from the start. I have not worked out the ramifications of this idea,
> so I might change my opinion once I have.
<
> >Can we face facts: The large flat linear address space model has won--
> >Just like Little Endian has won--and that comparing pointers in a large
> >flat linear address space is "easy" and there is no reason to make the
> >language "special" in this way. Better to make the non LFLAS models
> >pay the cost (are there any left?? If there are, why can't they continue=20
> >to use C11 ??)
>
> C11, C99, and C89 are not any better wrt. comparing pointers. If you
> want a language that has a flat address space, use Forth.
<
Yeah, lets see you write 8-wide BGOoO simulators in forth.
>
> - anton
> --
> 'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
> Mitch Alsup, <c17fcd89-f024-40e7...@googlegroups.com>