On Wed, 13 Oct 2021 16:39:25 -0500, BGB <cr88192@gmail.com> wrote:

>Mark has to touch nearly every byte of every live object.

Only when the language is uncooperative or relies on values being
somehow type tagged [which is old school].

The compiler knows the structure of the objects it manipulates and
often needs to store meta information about them anyway, e.g., to
implement OO features. With a little extra effort, the location of
pointers (if any) within objects can be communicated to the GC so it
only ever looks at relevant fields.

This can be done for stack frames also ... treating them like user
defined objects ... and it can be done regardless of what other
methods are used by the GC.

George

On Friday, October 15, 2021 at 3:15:03 PM UTC-5, victor....@gmail.com wrote:
> On Friday, October 15, 2021 at 2:27:20 PM UTC-5, MitchAlsup wrote:
>
> > You two have discussed this and that up and down without touching HW
<
> 1. Why do I have to pay the price of snooping cache everywhere when programs don't
> usually share much memory?
<
Because the price in HW is a lot lower than the cost in SW !
<
> 2. with the increasing numbers of registers, shouldn't we have a dirty bit so
> a process can save register state more efficiently with a "save-dirty-registers"
> instruction and a "fetch bitmap; load-saved-registers" instruction? Or otherwise reduce
> the expense of context switch?
<
a) Registers are supposed to be "sufficient", sufficient to get the job done with
minimal spillage. Thus the typical program in every context switch should touch
just about every register.
b) Improperly architected machines have too many registers (or files of register).
c) Properly designed machines have negligible overhead in managing registers.
d) if there is a register dirty bit it can be completely hidden in HW, alleviating SW
from needing to knowing anything about it.
<
> 3. Why is device IO so effin complex if devices are getting smarter.
<
Mostly because putting the tiniest coherent implementation of the processor of your
choice is not being places in a position where it can access the device in a nanosecond
but utilizes the big central processor that is milliseconds away from the I/O device.
<
That is, your ISA should enable a processor that is so small it can be put on every
southbridge chip and run the device driver "down there" and then coherently add
the cleanup driver to the run list and signal an IPI to the main stuff.
<
This processor runs the exact same code as if the driver was positioned in the central
complex, but is it topologically adjacent to the device itself saving millisecond after
millisecond of latency for each request.
<
> 4. why is virtualization such a kludge and why can't a supervisory core safely
> and efficiently sandbox other cores?
<
My 66000 ISA directly supports virtualization where VMs can efficiently support
VMs and VMs can efficiently support both paravirtualized and native OSs. This
was designed in from the start.
<
Much of the problem is that the major ISAs of today were born in the era of the
single CPU, and took on operating principles from that era. These operating
principles are not very "good" when the system is composed of inherently
parallel devices, CPU, OSs, and VMs. Inherent parallelism should be the mantra
of any (ANY) modern ISA (and whole machine architecture.)
<
In addition, because of the era from whence they were born was "I'm the guy"
context switching takes 1000's of cycles rather than 10's, and is performed
by morphing from one context into another using a series of instructions that
slowly convert whatever-I'm-doing into whatever-I-should-be-doing; where each
step along the way has be be recoverable from interrupts and exceptions.
<
This is a BAD model.
<
> 5. Pipelined systems should be able to peg memory bandwidth with a simple loop
>
> x: load (R1) to R2
> store R2,(R3)
> add 8,R1
> add 8, R3
> cmp R1, R5
> ble x
>
Bad ISA::
<
VEC
LDD R2,[R1+Ri<<3]
STD R2,[R3+Ri<<3]
LOOP Ri,#1,R5
<
3 instructions in the loop instead of 7 !
<
Plus, the loop executes at the WIDTH of the cache interface not the width of the
registers in the file--even when the data ends up misaligned.
>
> But they can't. Instead compilers screw around with vector registers clumsily
<
As I said:: bad ISA.
<
> 6. why is it so hard to delegate simple computations to gpus? Why can't the main OS
> simply dynamically compile and load simple loops for the GPUs ?
<
A GPU is a device capable of running trillions of ops per second.
a) you don't want to send it less than a billion units of work (millisecond)
b) you don't want it to send interrupts back more often than about 1 millisecond
c) you probably don't have a cache coherent memory interface to the GPU
<
> 7. Can't we get rid of interrupts?
<
No, but you can (CAN) eliminate the overhead of receiving an interrupt.
{This falls into Ivan's category of NYF -- not yet filed.}
So, would you still want to get rid of interrupts if their cost was 12 cycles rather
than 1,000-10,000 cycles ?
<
Back in the PDP-11 days, one could "service" an interrupt by running a single
instruction out of line at the cost of ~4 cycles.
<
The PDP-10 had something similar, but I forgot .....
<
> > in the last week; except to point out that all HW is not the same with respect
> > to; exceptions, shifts, overflow, variable shift direction,... That is NOT about
> > but about how some ancient piece of HW that still exists BLEW IT. IT is
> > fine to dwell on this for a short moment and reiterate that they BLEW IT
> > so to edumacate others in "Don't Do That". But you can't change C towards
> > what a well designed architecture will do without any provocation because
> > there are so many poor architectures out there that still exist (x86 being
> > one of them; with ARM not that far behind).
> > >
> > > Take C's 'char' type for instance - the standard defines it as being
> > > distinct from both unsigned and signed chars, why? I have no clue (just
> > > guesses) (POC being unsigned on PPC made for a some interesting
> > > surprises)
> > <
> > It is distinct because "char" is supposed to be an efficient container of
> > characters (of whatever encoding). S/360 has unsigned bytes, as do
> > several (now defunct) minicomputers, while others had signed bytes.
> > It seems to me that the proper course of any modern architecture is
> > to provide BOTH signed and unsigned bytes; and let the compiler
> > choose which one to use.
> > <
> > Another rational is that characters are not manipulated in ways where
> > being signed or unsigned is of an advantage. They are range checked
> > 'a'..'z' ,... '0'..'9',..., but quite often they are universally compared using
> > table[c] & StartsAlphanumeric,...
> > >
> > > What possessed creators of AIX to make address zero readable and thus
> > > completely breaking the expectations of Mono? (Some insights into this
> > > were, if my memory serves, provided on LKML and it might have been more
> > > widespread in the past not limeted to AIX/PPC)
> > <
> > Does AIX exist is enough implementations that its existence is relevant to a
> > long discussion of C.
> > > >
> > > > This, however, is a NG devoted to architectures that can run C and
> > > > all sorts of other languages. Architectures and implementations of
> > > > those architectures.
> > > >
> > > > It should a design goal of any architect to provide an efficient and
> > > > straightforward instruction set that enables compilers to produce
> > > > small, efficient, correct applications from a given set of source code.
> > > >
> > > > The past has taught us that a deft hand is required to put in enough
> > > > "stuff" to make the expression of the compiler efficient, and leave
> > > > out enough "stuff" to allow the implementations to be fast and
> > > > efficient. This paragraph should be what a discussion of what C in
> > > > this NG should be is about--what goes in ISA to make the compiler's
> > > > expression efficient, and what stays out of ISA that makes the
> > > > implementations efficient.
> > > >
> > > > I would suggest what stays out and what goes ISA in has changed
> > > > "a bit" since the RISC revolution burst onto the scene and then withered.
> > <
> > > While the discussion certainly swayed more towards C in general it seems
> > > to me that is still topical here.
> > <
> > You two have spend nearly a week talking about stuff that properly done
> > HW does not need discussed. Properly done HW fully supports C and
> > enables efficient compilation--including all the type punning, parameter
> > passing punning, pointer punning, pointer aliasing,.....And while fully supporting
> > C there is nothing that prevents such HW from supporting FORTRAN, Ada,
> > Cobol, RPG, LISP, Snobol, Jovial, Smalltalk, Sisal, and many more.
> > <
> > But I guess I am biased in that when writing OS-like codes, the source code
> > should be written as if optimization was set to -O-99 (do absolutely no
> > optimization.) In these codes it is more important to never get in a position
> > where optimization crashes a system, than it is to achieve 180ps faster run
> > times.
> > <
> > So, you say (SAY) the discussion was pertinent to HW, I ask what nuance of
> > a typical function unit that could be modified such that your discussion would
> > have taken 10% the thread length it has currently taken--showing no sign of
> > abatement.
> > <
> > What could be changed in the FETCH unit to make those C un-specifications
> > better?
> > <
> > What could be changed in the DECODE unit to make those C un-specifications
> > better?
> > <
> > What could be changed in the EXECUTE unit to make those C un-specifications
> > better?
> > <
> > What could be changed in the AGEN unit to make those C un-specifications
> > better?
> > <
> > What could be changed in the LDALIGN unit to make those C un-specifications
> > better?
> > <
> > What could be changed in the FP-UNIT unit to make those C un-specifications
> > better?
> > <
> > What could be changed in either CACHE unit to make those C un-specifications
> > better?
> > <
> > What could be changed in the MMU unit to make those C un-specifications
> > better?
> > <
> > What could be changed in the L2 Cache unit to make those C un-specifications
> > better?
> > <
> > What could be changed in the Register File Organization to make those C un-specifications
> > better?
> > <
> > What could be changed in the Call-Return specification to make those C un-specifications
> > better?
> > <
> > What could be changed in the switch specification to make those C un-specifications
> > better?
> > <
> > What could be changed in the DRAM unit to make those C un-specifications
> > better?
> > <
> > What could be changed in the Exception specification to make those C un-specifications
> > better?
> > <
> > What could be changed in the ProgramStatusContainer to make those C un-specifications
> > better?
> > <
> > What could be changed in the MEMORY-Model to make those C un-specifications
> > better?
> > <
> > What could be changed in the Branch-Predictor to make those C un-specifications
> > better?
> > <
> > What could be changed in the Context-Switch to make those C un-specifications
> > better?
> > <
> > What could be changed in the PCIe-device-I/O to make those C un-specifications
> > better?
> > <
> > What could be changed in the Interrupt specification to make those C un-specifications
> > better?
> > <
> > Just what pieces of HW could be made better enough to make your discussion of
> > C (un)specified behavior take 10% as long as it has already taken ?
> > <
> > Where is the HW relevance ?? I don't see it !!--unless you can point at one of the 20
> > units mentioned above and make a concrete suggestion as to how does one make
> > one of those better, that makes the problems of C vanish !
> > <
> > Where is the architecture relevance ?? I don't see it either.
> > <
I see nothing where my HW centricism was illuminated...............

On 10/15/2021 12:54 PM, clamky@hotmail.com wrote:
> MitchAlsup <MitchAlsup@aol.com> writes:
>
>> You know, there is a very fine NG suited to discuss the nuances of C,
>> what it is, what it is not, and what has been left grey {intentionally,
>> or by omission}: comp.lan.c
>
> I don't think comp.lanG.c is a place to discuss this. comp.std.c might
> be a better choice, but it's not nearly as vibrant as comp.arch.
>

The c.l.c regulars are more likely to just get into an argument about
how all this falls outside of the scope of what is written about in the
text of the C standard, and thus OT for the newsgroup, which is more for
the purity of the C standards document and not for any banal concerns
like, say, people actually implementing or using the language.

Or, basically, the stuff that would presumably make more sense on
"comp.std.c"...

> People here might, and do!, provide insights ofter overlooked by
> regulars in more software oriented NGs.
>
> Much of what is being discussed in this thread is intertwined with
> hardware, some decisions that lead to certain things being UB were, I
> believe, made that way by the committee because there existed weird
> architectures that needed to have a working/able C implementation.
>

Pretty much.

But, ideally, limitations related to oddball or ancient hardware
shouldn't impact what one is allowed to do on mainline hardware.

Also doesn't mean that limitations of oddball hardware are license to
break existing code which is doing something which is otherwise sensible
for the target in question.

> Take C's 'char' type for instance - the standard defines it as being
> distinct from both unsigned and signed chars, why? I have no clue (just
> guesses) (POC being unsigned on PPC made for a some interesting
> surprises)
>

Yeah. I have also ran into a few fun bugs trying to port stuff to ARM
due to its use of char being unsigned rather than signed by default.

Like, I had a Doom port where:
The up arrow went forward;
The down arrow, also went forward, but at massive speed.

Granted, being able to rocket forward at sufficient speeds that they can
also potentially jump to the other side of a wall is, while potentially
useful, not exactly the intended behavior.

> What possessed creators of AIX to make address zero readable and thus
> completely breaking the expectations of Mono? (Some insights into this
> were, if my memory serves, provided on LKML and it might have been more
> widespread in the past not limeted to AIX/PPC)
>
>>
>> This, however, is a NG devoted to architectures that can run C and
>> all sorts of other languages. Architectures and implementations of
>> those architectures.
>>
>> It should a design goal of any architect to provide an efficient and
>> straightforward instruction set that enables compilers to produce
>> small, efficient, correct applications from a given set of source code.
>>
>> The past has taught us that a deft hand is required to put in enough
>> "stuff" to make the expression of the compiler efficient, and leave
>> out enough "stuff" to allow the implementations to be fast and
>> efficient. This paragraph should be what a discussion of what C in
>> this NG should be is about--what goes in ISA to make the compiler's
>> expression efficient, and what stays out of ISA that makes the
>> implementations efficient.
>>
>> I would suggest what stays out and what goes ISA in has changed
>> "a bit" since the RISC revolution burst onto the scene and then withered.
>
> While the discussion certainly swayed more towards C in general it seems
> to me that is still topical here.
>

Yeah.

Because it is mostly about how we might interpret C in a way that is
"actually useful", rather than a bunch of proof-texting based on the C
standards documents or debating about whether or not the OP is off-topic
or similar (since, by definition, what happens when UB happens falls
outside the scope of the C standard).

But, yeah, my stance still stands that there possibly needs to be some
sort of supplementary document, sorta like POSIX, but more in the
context of additional rules for how C might be implemented such that
most existing software keeps working and the behaviors "actually make
sense" (while still able to use many common optimizations).

The goal is not to obsess on what might have existed in some alternate
history where computers gone in some entirely different direction.

Then, someone could probably ignore this document and go back to the
plain C standard if in-fact they are implementing some sort of alien
alternate history computer.

As noted, there are limits to what is "reasonable" to support, hence:
Me not exactly jumping into working on a Duke3D port;
My current 64-bit ports of Quake3 Arena lacking QVM;
...

On Friday, October 15, 2021 at 3:49:42 PM UTC-5, BGB wrote:
> On 10/15/2021 12:54 PM, cla...@hotmail.com wrote:
> > MitchAlsup <Mitch...@aol.com> writes:
> >
> >> You know, there is a very fine NG suited to discuss the nuances of C,
> >> what it is, what it is not, and what has been left grey {intentionally,
> >> or by omission}: comp.lan.c
> >
> > I don't think comp.lanG.c is a place to discuss this. comp.std.c might
> > be a better choice, but it's not nearly as vibrant as comp.arch.
> >
> The c.l.c regulars are more likely to just get into an argument about
> how all this falls outside of the scope of what is written about in the
> text of the C standard, and thus OT for the newsgroup, which is more for
> the purity of the C standards document and not for any banal concerns
> like, say, people actually implementing or using the language.
>
> Or, basically, the stuff that would presumably make more sense on
> "comp.std.c"...
> > People here might, and do!, provide insights ofter overlooked by
> > regulars in more software oriented NGs.
> >
> > Much of what is being discussed in this thread is intertwined with
> > hardware, some decisions that lead to certain things being UB were, I
> > believe, made that way by the committee because there existed weird
> > architectures that needed to have a working/able C implementation.
> >
> Pretty much.
<
I fail to see how your discussion of the past week and ANYTHING to do with HW ?
It may have to do with ancient instruction sets,
It may have to do with misdesigned register files.
But is has next to nothing wrt modern HW !
>
> But, ideally, limitations related to oddball or ancient hardware
> shouldn't impact what one is allowed to do on mainline hardware.
>
> Also doesn't mean that limitations of oddball hardware are license to
> break existing code which is doing something which is otherwise sensible
> for the target in question.
> > Take C's 'char' type for instance - the standard defines it as being
> > distinct from both unsigned and signed chars, why? I have no clue (just
> > guesses) (POC being unsigned on PPC made for a some interesting
> > surprises)
> >
> Yeah. I have also ran into a few fun bugs trying to port stuff to ARM
> due to its use of char being unsigned rather than signed by default.
>
> Like, I had a Doom port where:
> The up arrow went forward;
> The down arrow, also went forward, but at massive speed.
>
> Granted, being able to rocket forward at sufficient speeds that they can
> also potentially jump to the other side of a wall is, while potentially
> useful, not exactly the intended behavior.
> > What possessed creators of AIX to make address zero readable and thus
> > completely breaking the expectations of Mono? (Some insights into this
> > were, if my memory serves, provided on LKML and it might have been more
> > widespread in the past not limeted to AIX/PPC)
> >
> >>
> >> This, however, is a NG devoted to architectures that can run C and
> >> all sorts of other languages. Architectures and implementations of
> >> those architectures.
> >>
> >> It should a design goal of any architect to provide an efficient and
> >> straightforward instruction set that enables compilers to produce
> >> small, efficient, correct applications from a given set of source code.
> >>
> >> The past has taught us that a deft hand is required to put in enough
> >> "stuff" to make the expression of the compiler efficient, and leave
> >> out enough "stuff" to allow the implementations to be fast and
> >> efficient. This paragraph should be what a discussion of what C in
> >> this NG should be is about--what goes in ISA to make the compiler's
> >> expression efficient, and what stays out of ISA that makes the
> >> implementations efficient.
> >>
> >> I would suggest what stays out and what goes ISA in has changed
> >> "a bit" since the RISC revolution burst onto the scene and then withered.
> >
> > While the discussion certainly swayed more towards C in general it seems
> > to me that is still topical here.
> >
> Yeah.
>
> Because it is mostly about how we might interpret C in a way that is
> "actually useful", rather than a bunch of proof-texting based on the C
> standards documents or debating about whether or not the OP is off-topic
> or similar (since, by definition, what happens when UB happens falls
> outside the scope of the C standard).
>
>
> But, yeah, my stance still stands that there possibly needs to be some
> sort of supplementary document, sorta like POSIX, but more in the
> context of additional rules for how C might be implemented such that
> most existing software keeps working and the behaviors "actually make
> sense" (while still able to use many common optimizations).
>
> The goal is not to obsess on what might have existed in some alternate
> history where computers gone in some entirely different direction.
>
>
> Then, someone could probably ignore this document and go back to the
> plain C standard if in-fact they are implementing some sort of alien
> alternate history computer.
>
>
> As noted, there are limits to what is "reasonable" to support, hence:
> Me not exactly jumping into working on a Duke3D port;
> My current 64-bit ports of Quake3 Arena lacking QVM;
> ...

clamky@hotmail.com writes:
>What possessed creators of AIX to make address zero readable

Omagic (and IIRC the NMAGIC) a.out format starts at address 0; it took
until ZMAGIC to start elsewhere.

When Unix acquired virtual memory (on the VAX), there was no urgent
need to change the memory layout, so being able to access 0 is one of
the features that were denounced as Vaxocentrism.

It's not surprising that a commercial Unix like AIX also implemented
this feature. After all, they wanted to run the software available
for the mainstream of Unix.

What is more surprising is that the Unix community then switched to a
consensus that the first page is not accessible.

>and thus
>completely breaking the expectations of Mono?

Mono (2004) came several decades after Unix (1970), Unix on VAX
(~1980), and AIX (1986). Could it be that Mono is Linux-centric?

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

On 10/15/2021 3:53 PM, MitchAlsup wrote:
> On Friday, October 15, 2021 at 3:49:42 PM UTC-5, BGB wrote:
>> On 10/15/2021 12:54 PM, cla...@hotmail.com wrote:
>>> MitchAlsup <Mitch...@aol.com> writes:
>>>
>>>> You know, there is a very fine NG suited to discuss the nuances of C,
>>>> what it is, what it is not, and what has been left grey {intentionally,
>>>> or by omission}: comp.lan.c
>>>
>>> I don't think comp.lanG.c is a place to discuss this. comp.std.c might
>>> be a better choice, but it's not nearly as vibrant as comp.arch.
>>>
>> The c.l.c regulars are more likely to just get into an argument about
>> how all this falls outside of the scope of what is written about in the
>> text of the C standard, and thus OT for the newsgroup, which is more for
>> the purity of the C standards document and not for any banal concerns
>> like, say, people actually implementing or using the language.
>>
>> Or, basically, the stuff that would presumably make more sense on
>> "comp.std.c"...
>>> People here might, and do!, provide insights ofter overlooked by
>>> regulars in more software oriented NGs.
>>>
>>> Much of what is being discussed in this thread is intertwined with
>>> hardware, some decisions that lead to certain things being UB were, I
>>> believe, made that way by the committee because there existed weird
>>> architectures that needed to have a working/able C implementation.
>>>
>> Pretty much.
> <
> I fail to see how your discussion of the past week and ANYTHING to do with HW ?
> It may have to do with ancient instruction sets,
> It may have to do with misdesigned register files.
> But is has next to nothing wrt modern HW !

I have only been a minor poster in this thread though?...

You may be confusing me with someone else?...

Best I can tell, Thomas, Victor, and David, have been the main people in
this thread doing most the C semantics debate, oh well...

But, meh, I figured maybe people were getting tired about me going on
about BJX2 all the time, oh well.

Not much new in BJX2 news, mostly debugging more stuff.
Also battling with trying to find the "just right" adapter (eg, one that
"actually works") to connect an Ultra96 up to displays that only accept
HDMI, but alas...

Victor Yodaiken <victor.yodaiken@gmail.com> schrieb:
> On Friday, October 15, 2021 at 10:11:49 AM UTC-5, David Brown wrote:
>
>> In C, some people think wrapping signed integer overflow is a perfectly
>> reasonable choice of behaviour - that does not make it defined behaviour
>> in C, and it does not stop programs that rely on such behaviour from
>> being incorrect and program errors.
>
> When gcc/clang are used with the fwrapv flag, they define integer overflow to wrap
> as they are permitted to do by the C standard. Programs that rely on that behavior
> are not incorrect.
>
> There is nothing in the C standard that privileges one interpretation of C UB over
> another one.

It is "correct" in the sense that it works on a certain compiler
with a certain set of options.

The code is unportable and might trap or do other things, for
example with -ftrapv or with -fsanitize=undefined.

It also disables certain optimizations.

Finally, I still don't get it. C has perfectly defined operations
on modulo 2^n with its unsigned types. If that is what you want,
why use signed in the first place?

On Friday, October 15, 2021 at 4:55:25 PM UTC-5, Thomas Koenig wrote:
> Victor Yodaiken schrieb:
> > On Friday, October 15, 2021 at 10:11:49 AM UTC-5, David Brown wrote:
> >
> >> In C, some people think wrapping signed integer overflow is a perfectly
> >> reasonable choice of behaviour - that does not make it defined behaviour
> >> in C, and it does not stop programs that rely on such behaviour from
> >> being incorrect and program errors.
> >
> > When gcc/clang are used with the fwrapv flag, they define integer overflow to wrap
> > as they are permitted to do by the C standard. Programs that rely on that behavior
> > are not incorrect.
> >
> > There is nothing in the C standard that privileges one interpretation of C UB over
> > another one.
> It is "correct" in the sense that it works on a certain compiler
> with a certain set of options.
>

It is correct in the sense that it is correct and satisfies all the requirements
of ISO-C as much as the mathematically capricious semantics gcc/clang
optimizers produce without the flag.

> The code is unportable and might trap or do other things, for
> example with -ftrapv or with -fsanitize=undefined.

And similarly, without fwrapv, "correct"code may still trap with ftrapv
and may produce different results even on different versions of the same compiler -
non-portable with a star.

>
> It also disables certain optimizations.

Which are minimal value.

>
> Finally, I still don't get it. C has perfectly defined operations
> on modulo 2^n with its unsigned types. If that is what you want,
> why use signed in the first place?

Well, I might prefer the mathematical coherence of mod 2^k 2s complement
over "it depends" and I might want to be able to test for wrap.
If a pure expression E(x1,..., xn) has the same value every time you
run it in the ring Z/2^kZ but not in "let's pretend that some algebra rules
of integers apply sometimes even when we just have finite representations
of integers, not integers themselves". And I might have a legacy code
base that depends on the pre-"optimized" semantics.

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

> clamky@hotmail.com writes:
>>What possessed creators of AIX to make address zero readable
>
> Omagic (and IIRC the NMAGIC) a.out format starts at address 0; it took
> until ZMAGIC to start elsewhere.
>
> When Unix acquired virtual memory (on the VAX), there was no urgent
> need to change the memory layout, so being able to access 0 is one of
> the features that were denounced as Vaxocentrism.
>
> It's not surprising that a commercial Unix like AIX also implemented
> this feature. After all, they wanted to run the software available
> for the mainstream of Unix.
>
> What is more surprising is that the Unix community then switched to a
> consensus that the first page is not accessible.
>
>>and thus
>>completely breaking the expectations of Mono?
>
> Mono (2004) came several decades after Unix (1970), Unix on VAX
> (~1980), and AIX (1986). Could it be that Mono is Linux-centric?
>

Thank you. I was lucky to enough to locate LKML post from Linus Torvalds
that touches on this issue

https://yarchive.net/comp/linux/address_zero.html

The fact that zero was readable on AIX made us abandon the idea of
porting Mono to AIX back in the day, guess more resourceful people
managed to do it eventually. We only had time to fix, obvious, things so
that Linux PPC64 worked.

Plus, if memory serves, address zero on Power7 (6?)/AIX was made
readable not via paging but some segmentation mechanism, it was more
than a decade ago so my brain might be seriously distorting things.

clamky@hotmail.com writes:

> MitchAlsup <MitchAlsup@aol.com> writes:
>
>> You know, there is a very fine NG suited to discuss the nuances of C,
>> what it is, what it is not, and what has been left grey {intentionally,
>> or by omission}: comp.lan.c
>
> I don't think comp.lanG.c is a place to discuss this. comp.std.c might
> be a better choice, but it's not nearly as vibrant as comp.arch.
>
> People here might, and do!, provide insights ofter overlooked by
> regulars in more software oriented NGs.
>

[..]

I've never read the comp.arch's charter and have only vague idea what is
allowed here, the thread starter post (sorry for misspelling your name
there) was made because i really sought to learn your and Anton's
perspective on the topic, as, i have perceived, you both to be rather
critical of the current C situation. Don't think that i've seen either
of you active on C dedicated NGs.

In any case, for me, the thread was illuminating - some/many people have
expressed their positions in a simpler and more direct way.

On Friday, October 15, 2021 at 5:58:46 PM UTC-5, cla...@hotmail.com wrote:
> an...@mips.complang.tuwien.ac.at (Anton Ertl) writes:
>
> > cla...@hotmail.com writes:
> >>What possessed creators of AIX to make address zero readable
> >
> > Omagic (and IIRC the NMAGIC) a.out format starts at address 0; it took
> > until ZMAGIC to start elsewhere.
> >
> > When Unix acquired virtual memory (on the VAX), there was no urgent
> > need to change the memory layout, so being able to access 0 is one of
> > the features that were denounced as Vaxocentrism.
> >
> > It's not surprising that a commercial Unix like AIX also implemented
> > this feature. After all, they wanted to run the software available
> > for the mainstream of Unix.
> >
> > What is more surprising is that the Unix community then switched to a
> > consensus that the first page is not accessible.
<
As far as I see, it is only location zero that is not accessible.
<
However, almost all machines create that inaccessibility by making the
entire page containing location zero be inaccessible. Which, while simple
is entirely unnecessary.
<
{And no, My 66000 did nothing different here, either.}
> >
> >>and thus
> >>completely breaking the expectations of Mono?
> >
> > Mono (2004) came several decades after Unix (1970), Unix on VAX
> > (~1980), and AIX (1986). Could it be that Mono is Linux-centric?
> >
> Thank you. I was lucky to enough to locate LKML post from Linus Torvalds
> that touches on this issue
>
> https://yarchive.net/comp/linux/address_zero.html
>
> The fact that zero was readable on AIX made us abandon the idea of
> porting Mono to AIX back in the day, guess more resourceful people
> managed to do it eventually. We only had time to fix, obvious, things so
> that Linux PPC64 worked.
>
> Plus, if memory serves, address zero on Power7 (6?)/AIX was made
> readable not via paging but some segmentation mechanism, it was more
> than a decade ago so my brain might be seriously distorting things.

On Thu, 14 Oct 2021 15:19:28 -0400, Stefan Monnier
<monnier@iro.umontreal.ca> wrote:

>If you have more dead objects than live objects, it means your GC
>imposes an overhead of more than 100% (and if you have "far more" dead
>objects, than it's even "far worse"). As mentioned, for the nursery of
>a generational GC this is not a problem since the nursery is a small
>fraction of the total heap anyway, but such an overhead over the whole
>heap would be rather problematic (if it's not, then there's a high
>chance that your program doesn't actually care about performance at all
>anyway and any GC scheme would be fine as well).

If your memory is filled with long-lived objects, then any GC method
will have problems dealing with it.

>Don't get me wrong: I love copying schemes and I do think they work very
>well in most cases, but it doesn't come for free.

No GC comes for free. <grin>

>George Neuner [2021-10-13 14:26:18] wrote:
>
>> Again, the assumption is that the live set is much smaller than the
>> dead set. Which IS the case for most programs in GC'd languages.
>
>I think this is not inherently true. Rather, it needs to be true for
>the GC to work efficiently, so the GC itself is tweaked so as to try and
>make it true more often, e.g. by using generations (or other partitioned
>heap schemes) and using heuristics that try to guess which partition to
>GC this cycle (hoping it will hold the higher fraction of dead objects).

"Typical" allocation patterns are very different across the various
languages that employ GC. Many of the current crop of GC'd languages
really are fairly conventional imperative languages that use GC
/mostly/ as a programmer convenience. Many programs written in these
languages using GC could - almost[*] as easily - have been written in
C using malloc/free.
[*] I say "almost as easily" assuming a reasonably good programmer. I
realize that the skill level of the /average/ programmer now is not
much greater than "novice".

OTOH, consider more declarative/functional languages like Lisp, ML,
Prolog, etc., where RAII is the rule rather than simply good practice,
where data structures are more often constructed bottom up than top
down, and where data more often gets copied (or computed) into a new
version of an object rather than being updated in place. Idiomatic
code relies often on creation of ad-hoc closures with (largely)
indeterminate lifetimes. Object mortality rates tend to be much
higher than in imperative languages.

Manual memory management in such languages lies somewhere between
"really inconvenient" and "near intractable" - even for good
programmers. These language don't simply /use/ GC, they /depend/ on
GC because without it they largely would be impractical to use.

A person whose exposure to GC comes mainly from languages such as
these may develop a somewhat skewed perspective on how GC fits (or
should fit) into program operation.
[I say this without accusation: I know nothing of your background.
It's just an observation from experience talking to people about the
merits of various programming languages.]

>But over the whole heap, we still want to try and minimize the
>proportion of dead objects, since they are an undesirable overhead
>(that may increase VM or cache pressure).

The idea /should/ be to minimize the address space consumed by live
objects so as to lower pressure on VMM translation and cache.

Anticipating the day I can buy a Mill.

George

BGB <cr88192@gmail.com> writes:

>>> Eg:
>>> Signed right shift;
>>> Signed integer overflow;
>>
>> That is something that I do not understand.
>>
>> C has perfectly good unsigned integers. Instead of (assuming 32-bit
>> ints here)
>>
>> int i;
>> ...
>> i = i >> 1;
>>
>> what's wrong with
>>
>> i = ((unsigned int) i) >> 1;
>>
>> or
>>
>> i = (((unsigned int) i) >> 1) | (((unsigned int) i) & (1u << 31));
>>
>> thus telling the compiler exactly what it should do with the sign
>> bit, and being portable at the same time? If you don't like to
>> write it out, put it in a macro or a static inline function in a
>> header somewhere (better type-safety that way), and you're done.
>>
>
> This requires heavy lifting from the compiler to realize that this
> convoluted mess represents an arithmetic shift.
>
> It is easier, for both normal programmers and the compiler
> implementers, to declare that signed right shift is an arithmetic
> shift.
>
>
> It is like asking people to use byte operations and shifts to read
> values. Some compilers can figure it out (and turn it into a plain
> load), while some others will give byte operations and shifts.

In Javascript they have what they call "polyfill" that implements new
functions for older interpreters. This would be a nice thing to have in
C. So if you wanted an arithmetic shift, you could use the standard
body approved polyfill function and know that the compiler will have the
best chance to recognize the pattern and it'll at least still work if it
doesn't.

On 10/15/2021 7:00 PM, George Neuner wrote:
> On Thu, 14 Oct 2021 15:19:28 -0400, Stefan Monnier
> <monnier@iro.umontreal.ca> wrote:
>
>
>> If you have more dead objects than live objects, it means your GC
>> imposes an overhead of more than 100% (and if you have "far more"
>> dead objects, than it's even "far worse"). As mentioned, for the
>> nursery of a generational GC this is not a problem since the
>> nursery is a small fraction of the total heap anyway, but such an
>> overhead over the whole heap would be rather problematic (if it's
>> not, then there's a high chance that your program doesn't actually
>> care about performance at all anyway and any GC scheme would be
>> fine as well).
>
> If your memory is filled with long-lived objects, then any GC method
> will have problems dealing with it.
>

My last major project which used GC (BGBTech Engine) had a lot of large
long-lived structures, namely "voxel chunks", each of which represented
a 16x16x16 cube of blocks. In this particular engine, each chunk needed
about 32K, and there were 8 such chunks in a column.

For a draw distance of ~ 384 meters, there could be ~ 15,000 chunks
loaded into memory, or ~ 500MB of chunk data.

This was combined with another ~ 1GB or so of vertex arrays, ... Overall
heap size was ~ several GB or so with these sorts of draw distances.

This was one of my first major project to move over to primarily 64 bit
builds (*1). Performance was also a long standing issue with this
project (as-in, its performance was generally pretty awful).

*1: I first started hearing about x86-64 when I was in High-School, and
not long after graduation I was able to get a Athlon 64 system put
together, but it had a lot of reliability problems (it was very crash
prone).

Later I got an Athlon X2, which was a considerable improvement in terms
of stability. Was generally running XP X64 on it up until later
switching to Windows 7 (because Vista was "kinda crap").

So, this was the original kind of hardware I started developing the 3D
engine on.

Around this time, I had also switched from Cygwin and MinGW to MSVC via
the Platform SDK; as it could build 64-bit programs and was free (this
being back in the days when Visual Studio still cost money; then there
was VS Express but it only supported 32-bit x86).

GC stalls were annoying, and trying to move around would cause chunks to
load and unload, which didn't help.

I generally also ended up putting up a wall around the world at 1km from
the origin. It was possible to go beyond the wall, but doing so had a
non-zero risk. IIRC, it would also not save chunks past the 1km mark to
the HDD (since the on-disk format also ate a lot of space).

Chunks were also stored on-disk using the same RLE scheme as Wolf3D and
ROTT (with the voxel data laid out in a "planar" ordering).

But, the RLE scheme is fairly weak:
Raw Byte (00..FF, as long as Byte!=RLEBTAG)
RLEBTAG LenByte ValueByte

RLEBTAG would be chosen such that it was "unlikely", and if it occurred
as a literal byte it would need to be escaped as a 1B RLE run.

For the follow-on engine (BGBTech2) I switched over to more compact
chunk formats:
16x16x16, with a 4 or 8 bit index (16 or 256 unique blocks)
Each block was 32 bits.
These chunks would each use around 2K or 5K.
16x16x16, 4096x 32-bits (16K)

Since most chunks could use the 2K or 5K formats, there was a
considerable memory saving (most chunks would have a fairly modest
number of "unique" blocks).

Also generally the vertex arrays used mostly 16-bit coordinates,
typically region-local, and also using QUADS, generally somewhat
reducing the sizes of the vertex arrays.

Chunks were also stored using an LZ + SMTF/AdRice scheme (also less HDD
bloat than RLEB), ...

This engine also abandoned the use of garbage collection (though, IIRC,
I think I still used a custom allocator, as MSVCRT's malloc starts
having performance problems with large heaps).

Generally, performance for BGBTech2 was a little better than Minecraft,
and I could run it effectively on some hardware which was unable to run
Minecraft effectively (namely, XP and Vista era laptops).

I also had a build of it that ran on WASM in a browser:
https://cr88192.github.io/bgbtech_html/deeptail0.html

(Small draw distance mostly to save on memory, ... This seemingly a
mostly forgotten relic from a time known as 5 years ago...).

Still a bit too heavyweight to port to BJX2, but I have some ideas that
could possibly allow for a smaller cheaper engine along similar lines.

I also mostly dropped 3D models in favor of sprites, but this was more
for aesthetic reasons. Also, sprites are easier to draw than it is to 3D
model and animate stuff (3D modeling and skeletal animation is a PITA).

I am not sure if my gamedev efforts are dead at this point, or just in
hibernation. I was admittedly always more interested in tinkering with
technology, and my "game" projects were generally lacking something (and
generally no one seemed all that interested).

>
>> Don't get me wrong: I love copying schemes and I do think they work
>> very well in most cases, but it doesn't come for free.
>
> No GC comes for free. <grin>
>
>
>> George Neuner [2021-10-13 14:26:18] wrote:
>>
>>> Again, the assumption is that the live set is much smaller than
>>> the dead set. Which IS the case for most programs in GC'd
>>> languages.
>>
>> I think this is not inherently true. Rather, it needs to be true
>> for the GC to work efficiently, so the GC itself is tweaked so as
>> to try and make it true more often, e.g. by using generations (or
>> other partitioned heap schemes) and using heuristics that try to
>> guess which partition to GC this cycle (hoping it will hold the
>> higher fraction of dead objects).
>
>
> "Typical" allocation patterns are very different across the various
> languages that employ GC. Many of the current crop of GC'd
> languages really are fairly conventional imperative languages that
> use GC /mostly/ as a programmer convenience. Many programs written
> in these languages using GC could - almost[*] as easily - have been
> written in C using malloc/free. [*] I say "almost as easily" assuming
> a reasonably good programmer. I realize that the skill level of the
> /average/ programmer now is not much greater than "novice".
>

Yeah. In my case, GC was kinda debatable.

It isn't too much of a stretch to move JavaScript style language over to
manual memory management, and then one basically has ActionScript.

A language design like Scheme can gave a much higher garbage-generation
rate, but when working with a conservative GC, a lot of effort went into
minimizing the garbage generation rate however possible (to delay GC
cycles as long as possible).

>
> OTOH, consider more declarative/functional languages like Lisp, ML,
> Prolog, etc., where RAII is the rule rather than simply good
> practice, where data structures are more often constructed bottom up
> than top down, and where data more often gets copied (or computed)
> into a new version of an object rather than being updated in place.
> Idiomatic code relies often on creation of ad-hoc closures with
> (largely) indeterminate lifetimes. Object mortality rates tend to be
> much higher than in imperative languages.
>
> Manual memory management in such languages lies somewhere between
> "really inconvenient" and "near intractable" - even for good
> programmers. These language don't simply /use/ GC, they /depend/ on
> GC because without it they largely would be impractical to use.
>
>
> A person whose exposure to GC comes mainly from languages such as
> these may develop a somewhat skewed perspective on how GC fits (or
> should fit) into program operation. [I say this without accusation: I
> know nothing of your background. It's just an observation from
> experience talking to people about the merits of various programming
> languages.]
>

In my case:
My first 3D engine was C + BGBScript.

BGBScript was, in-turn, started out as essentially JavaScript clone, but
also borrowing syntax and features from ActionScript, and some elements
from Scheme.

Some things from JavaScript did not carry over, for example, "a==b" was
a lot more strict, and would not try to auto-convert between dissimilar
types.

The BGBTech2 engine was C + BGBScript2, where BGBScript2 was a
redesigned language which had a lot more common with Java and C#, but
went over to manual memory management (new/delete + automatic lifetimes).

My C compiler (BGBCC) was originally a fork off of an earlier version of
the first BGBScript VM (it was first written back when I was working on
my original BGBTech Engine project).

Victor Yodaiken <victor.yodaiken@gmail.com> schrieb:
> On Friday, October 15, 2021 at 10:38:52 AM UTC-5, David Brown wrote:
>> On 14/10/2021 21:34, Stefan Monnier wrote:
>> > David Brown [2021-10-14 16:24:40] wrote:
>
>> High level languages - and C is a high level language - are defined in
>> terms of abstract machines, not the hardware.
>
> That is certainly a view, but it's more than debatable.

Says so in the standard, which I quoted.

Thomas Koenig <tkoenig@netcologne.de> writes:
>C has perfectly defined operations
>on modulo 2^n with its unsigned types. If that is what you want,
>why use signed in the first place?

E.g., widening, <, > and / deliver different results for unsigned
numbers than for signed numbers. Many library functions expect or
deliver signed numbers.

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

> This, however, is a NG devoted to architectures that can run C and
> all sorts of other languages. Architectures and implementations of
> those architectures.
>
> It should a design goal of any architect to provide an efficient and
> straightforward instruction set that enables compilers to produce
> small, efficient, correct applications from a given set of source code.

You are, of course, correct.

There is another goal, which is to have zero or low overhead for
error checking. If I may quote C.A.R. Hoare:

# Finally, it is absurd to make elaborate security checks on debugging
# runs, when no trust is put in the results, and then remove them
# in production runs, when an erroneous result could be expensive
# or disastrous. What would we think of a sailing enthusiast who
# wears his lifejacket when training on dry land, but takes it off
# as soon as he goes to sea?

The reason for this is that some languages like C make error
checking very difficult (for example, finding out the valid range
for pointer arithmetic in a function needs information from the
caller, which is not available via the standard language).

There are languages where the necessary info is provided, Ada
and Fortran among them. However, that there is a rather large
overhead in code size and, more importantly, execution time.
IIRC (but correct me if I'm wrong) even gnat comes which range
checking switched off by default.

To extend the metaphor above, the lifejacket comes combined with
a sea anchor, which is not good if you want to go somewhere.

There are a couple of notorious bug classes which surface again
and again. Buffer overruns are a classic, as are "use after free"
errors and signed overruns.

First, buffer overruns. Compilers need to become better at moving
checking code out of loops. One idea that could help (with compiler
support, of course) is to define a valid range for a register
(which could hold an address to an array or an index) to be in
for a certain amount of instructions, trapping if it is outside.
Maybe a few "range registers" with a way to associate a certain
register with them, to allow spill / restore.

Signed overruns - the very topic we are discussing here. Integer
arithmetic could (optionally) trap on a 64-bit overflow, a 32-bit
overflow, a 16-bit overflow and an 8-bit overflow.

Use after free - much more difficult. It might be possible to
have a hardware list of "poisoned" address ranges from which it is
not permitted to load. Very expensive (comparable to
cache) and would probably cache only the most recently freed
memory blocks. Not sure if this is worth it.

Ideas? Comments?

On Saturday, October 16, 2021 at 4:19:11 AM UTC-5, Thomas Koenig wrote:
> Victor Yodaiken <victor....@gmail.com> schrieb:
> > On Friday, October 15, 2021 at 10:38:52 AM UTC-5, David Brown wrote:
> >> On 14/10/2021 21:34, Stefan Monnier wrote:
> >> > David Brown [2021-10-14 16:24:40] wrote:
> >
> >> High level languages - and C is a high level language - are defined in
> >> terms of abstract machines, not the hardware.
> >
> > That is certainly a view, but it's more than debatable.
> Says so in the standard, which I quoted.

Cat: while( (n = read(0,buf))>0)write(1,buf,n);

Neither read nor write are defined in the C Standard, in fact calling them is
C-Standard UB. There is no specification of what happens in the abstract machine
on those calls. QED.

The distinctive feature of the C Standard is that it depends so much on what it
purposefully does not define.

On Friday, October 15, 2021 at 3:45:42 PM UTC-5, MitchAlsup wrote:

> > 3. Why is device IO so effin complex if devices are getting smarter.
> <
> Mostly because putting the tiniest coherent implementation of the processor of your
> choice is not being places in a position where it can access the device in a nanosecond
> but utilizes the big central processor that is milliseconds away from the I/O device.
> <

current generation x86 servers are 2 or 3 microseconds from i/o devices - without
tuning.

I don't know how you are going to give me 12 cycle interrupts with a 9 stage pipeline.
Just resolving the pipeline will take most of that. But I look forward to learning
more.

MitchAlsup <MitchAlsup@aol.com> writes:
>On Friday, October 15, 2021 at 5:58:46 PM UTC-5, cla...@hotmail.com wrote:
>> an...@mips.complang.tuwien.ac.at (Anton Ertl) writes:
>> > What is more surprising is that the Unix community then switched to a
>> > consensus that the first page is not accessible.
><
>As far as I see, it is only location zero that is not accessible.

On what system?

>However, almost all machines create that inaccessibility by making the
>entire page containing location zero be inaccessible. Which, while simple
>is entirely unnecessary.

Unnecessary for what?

It's obvious from Vaxocentrism and AIX that systems can make address 0
accessible.

It is convenient for detecting unintended p==NULL for *p if address 0
is unaccessible (if you are not on one of the fortunately no longer
relevant systems where the C pointer 0 is not represented by machine
address 0). It is convenient for detecting that for p->foo and
p[smallint] if the first page is unaccessible. It is convenient for
detecting that for larger arrays and structures if more is not
accessible. In Linux 5.10 on AMD64 the default for
/proc/sys/vm/mmap_min_addr is 65536.

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

Thomas Koenig <tkoenig@netcologne.de> writes:

[...]

> There is also the restriction on the complexity, which makes
>
> #! /bin/sh
> echo "Program to complex, aborting" 1>&2
>
> a valid C compiler according to the standard.

Not true. Feel free to ask in comp.std.c if you want
to understand why.

On 10/15/21 22:35, Anton Ertl wrote:
> clamky@hotmail.com writes:
>> What possessed creators of AIX to make address zero readable
>
> Omagic (and IIRC the NMAGIC) a.out format starts at address 0; it took
> until ZMAGIC to start elsewhere.
>
> When Unix acquired virtual memory (on the VAX), there was no urgent
> need to change the memory layout, so being able to access 0 is one of
> the features that were denounced as Vaxocentrism.

Well, address zero is the start of the interrupt vector table. On
pdp11 as well and early 68K, though later 68K had a register to
point to the start. Perhaps not so unusual after all...

>
> It's not surprising that a commercial Unix like AIX also implemented
> this feature. After all, they wanted to run the software available
> for the mainstream of Unix.
>
> What is more surprising is that the Unix community then switched to a
> consensus that the first page is not accessible.
>
>> and thus
>> completely breaking the expectations of Mono?
>
> Mono (2004) came several decades after Unix (1970), Unix on VAX
> (~1980), and AIX (1986). Could it be that Mono is Linux-centric?
>
> - anton

Thomas Koenig <tkoenig@netcologne.de> writes:

> Tim Rentsch <tr.17687@z991.linuxsc.com> schrieb:
>
>> AFAIAA none of flags used in compiling programs like the Linux
>> kernel render the implementation non-conforming, and if the
>> implementation is conforming then by definition the language
>> being compiled is C.
>
> One of the weaker points of the C standard.
>
> I can with some justification claim that gfortran is a conforming
> C implementation. Let's test:
>
> $ cat hello.c
> #include <stdio.h>
>
> int main()
> {
> printf ("Hello, world!\n");
> return 0;
> }
> $ gfortran hello.c
> $ ./a.out
> Hello, world!
>
> Yet, gfortran also compiles this:
>
> $ cat hello.f
> PROGRAMME MAIN
> WRITE (*,1000)
> 1000 FORMAT (11HHELLO WORLD)
> END
> $ gfortran hello.f
> $ ./a.out
> HELLO WORLD
> $
>
> So, is the program hello.f C?

This is a silly question.

$ cat xx.f
int
main(){
}
$ gfortran xx.f
xx.f:1:1:

int
1
Error: Non-numeric character in statement label at (1)
xx.f:1:1:

int
1
Error: Unclassifiable statement at (1)
xx.f:2:1:

main(){
1
Error: Non-numeric character in statement label at (1)
xx.f:2:1:

main(){
1
Error: Unclassifiable statement at (1)
xx.f:3:1:

}
1
Error: Non-numeric character in statement label at (1)
$

Without further information or restrictions gfortran is neither a
C compiler nor a Fortran compiler. Moreover a compiler is only
one part of what makes up a conforming C implementation.

Victor Yodaiken <victor.yodaiken@gmail.com> writes:
>1. Why do I have to pay the price of snooping cache everywhere when programs don't
>usually share much memory?

I think there has been hardware without any cache consistency. This
has pretty much died out. Apparently it's cheap enough to provide
cache consistency (through snooping or other techniques, such as
directories) for the number of CPUs available in shared-memory
machines, and too hard for software to deal with total lack of cache
consistency.

But it seems to me the more common approach of those who shied away
from cache consistency has been to use private memory and message
passing. This may be ok for some supercomputer applications, but is
not particularly useful in general; IBM and Sony tried it with the
Cell architecture, but game programmers found it too hard to use.

But on another level your wish has been granted. Hardware people
don't give us sequential consistency between cores, but more or less
weaker memory models, and instructions for achieving more consistency
(up to sequential consistency) where needed.

Unfortunately, these instructions are quite slow, which results in a
bad situation for programmers: They should at the same time minimize
the use as many of these instructions as necessary while minimizing
their use in order to avoid slowdowns; and the bad thing about that
situation is that it is hard to tell if you have used enough of these
instructions in the right places if you try to minimize them. So the
situation is:

* If you want to be sure that you have enough of these instructions,
just put them everywhere in your shared-memory access code; as a
result, your program will crawl if it accesses the shared-memory
stuff with any frequency at all.

* Or you try to minimize the use of these instructions, and risk that
you opened up your program to some inconsistency, which is hard to
test for and debug.

There has been some work on sequential consistency in hardware
[daya+14], but my impression is that we will not such features in
commercial hardware unless this becomes a sellable feature. For now
they seem to be content with the situation that a few specialists
puzzle out the problem described above, and the masses program
sequentially or at best by calling libraries written be the
specialists.

Of course, one might provide other features rather than sequential
consistency, and Intel made a go at it with TSX. But unfortunately
that seems to be too hard to implement. E.g., it is disabled in the
1135G7 CPU of my laptop and is not even mentioned on
<https://ark.intel.com/content/www/us/en/ark/products/208658/intel-core-i5-1135g7-processor-8m-cache-up-to-4-20-ghz.html>;
it's at least mentioned on
<https://ark.intel.com/content/www/us/en/ark/products/212261/intel-xeon-e2378-processor-16m-cache-2-60-ghz.html>,
but disabled.

@InProceedings{daya+14,
author = {Bhavya K. Daya and Chia-Hsin Owen Chen and Suvinay
Subramanian and Woo-Cheol Kwon and Sunghyun Park and
Tushar Krishna and Jim Holt and Anantha
P. Chandrakasan and L-Shiuan Peh},
title = {{SCORPIO}: A 36-Core Research-Chip Demonstrating
Snoopy Coherence on a Scalable Mesh {NoC} with
In-Network Ordering},
crossref = {isca14},
OPTpages = {},
url = {http://projects.csail.mit.edu/wiki/pub/LSPgroup/PublicationList/scorpio_isca2014.pdf},
annote = {The cores on the chip described in this paper access
their shared memory in a sequentially consistent
manner; what's more, the chip provides a significant
speedup in comparison to the distributed directory
and HyperTransport coherence protocols. The main
idea is to deal with the ordering separately from
the data, in a distributed way. The ordering
messages are relatively small (one bit per core).
For details see the paper.}
}

>2. with the increasing numbers of registers, shouldn't we have a dirty bit so
>a process can save register state more efficiently with a "save-dirty-registers"
>instruction and a "fetch bitmap; load-saved-registers" instruction? Or otherwise reduce
>the expense of context switch?

Did not work well for the VAX call instruction, why should it work
better now? CPUs have become better since that time at processing
blocks of data unconditionally, but not so much better at doing it
conditionally: a VAX instruction typically took 10 cycles; store and
load throughput currently typically is at 1-3 per cycle, while a
mispredicted branch costs around 20 cycles.

>3. Why is device IO so effin complex if devices are getting smarter.

I don't know much about this, but I can think of two contributing
factors:

* Simple device interfaces would be slow, because round trips to I/O
are slow thanks to I/O being relatively far from the CPU core (and
these paths being not as optimized, and I/O-devices being slow). So
one invents "smart" interfaces that result in fewer round-trips, but
these are by necessity more complex than the simple interfaces.

* There is little pressure to make a good design for these device
interfaces. For Windows and Android the hardware manufacturers
develop the device driver themselves, so the hardware people can
just tell their software people: This is the hardware, deal with it.
And the free software people tend to also just deal with it, because
device availability (thanks to Windows or Android) trumps easy
programming.

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

Victor Yodaiken <victor.yodaiken@gmail.com> schrieb:
> On Friday, October 15, 2021 at 4:55:25 PM UTC-5, Thomas Koenig wrote:
>> Victor Yodaiken schrieb:
>> > On Friday, October 15, 2021 at 10:11:49 AM UTC-5, David Brown wrote:
>> >
>> >> In C, some people think wrapping signed integer overflow is a perfectly
>> >> reasonable choice of behaviour - that does not make it defined behaviour
>> >> in C, and it does not stop programs that rely on such behaviour from
>> >> being incorrect and program errors.
>> >
>> > When gcc/clang are used with the fwrapv flag, they define integer overflow to wrap
>> > as they are permitted to do by the C standard. Programs that rely on that behavior
>> > are not incorrect.
>> >
>> > There is nothing in the C standard that privileges one interpretation of C UB over
>> > another one.
>> It is "correct" in the sense that it works on a certain compiler
>> with a certain set of options.
>>
>
> It is correct in the sense that it is correct

A bit of a tautology there :-)

> and satisfies all the requirements
> of ISO-C

Except for relying on undefined behavior.

>as much as the mathematically capricious semantics gcc/clang
> optimizers produce without the flag.
>
>> The code is unportable and might trap or do other things, for
>> example with -ftrapv or with -fsanitize=undefined.
>
> And similarly, without fwrapv, "correct"code may still trap with ftrapv

You put the quotation marks on correct, which is correct :-)

To reiterate what the note 1 to 3.4.3 says:

# Possible undefined behavior ranges from ignoring the
# situation completely with unpredictable results, to behaving
# during translation or program execution in a documented manner
# characteristic of the environment (with or without the issuance of
# a diagnostic message), to terminating a translation or execution
# (with the issuance of a diagnostic message).

You're at the mercy of the compiler, the release of the compiler,
the architecture your program runs on, the operating system,
the options specified to the comiler, the phase of the moon,
the day of the week, cosmic rays and what the CPU ate for breakfast.

> and may produce different results even on different versions of the same compiler -
> non-portable with a star.

As long as you avoid undefined behavior, any trap would be a
compiler bug (or something like running out of memory).

>> It also disables certain optimizations.
>
> Which are minimal value.

You think that it is of minimal value to determine the number
of loop iterations at compile time, for example?

What, exactly, is your experience with writing and maintaining
a compiler?

>
>>
>> Finally, I still don't get it. C has perfectly defined operations
>> on modulo 2^n with its unsigned types. If that is what you want,
>> why use signed in the first place?
>
> Well, I might prefer the mathematical coherence of mod 2^k 2s complement
> over "it depends" and I might want to be able to test for wrap.

So use unsigned, it's well defined, and there is no overflow which
can lead to undefined behavior.