MitchAlsup wrote:
> On Tuesday, October 26, 2021 at 11:57:44 AM UTC-5, Ivan Godard wrote:
>> On 10/26/2021 9:36 AM, MitchAlsup wrote:
>
>>> But that function needs to be provided by the compiler as part of its own run
>>> time (support library). It is not something that is willy-nilly generated by a
>>> semi-concerned programmer using a few compiler switches.
>>> <
>>> Also, how does one unwind the stack when one has no access to the parts
>>> of the stack that are protected from the user code ?
> <
>> Good question. Our answer is NYF.
> <
> Seems to me you have 2 choices:: some HW instruction that performs job at hand
> faking access rights {sort of what I do in HW context switches...........}
> Or a cheap context switch to a address space with permissions to do the job in SW.
> <
> It seems painfully obvious that the entirety of the mechanism is to prevent user
> (unprivileged code) from accessing those locations {security, RoP,...}
>

First, note that this is a separate issue from a language not
having the primitives to examining program stack. This is a
protection domain issue. One can look at capability OSes
such as KeyKOS for such issues. This is what Norm Hardy says in
http://www.cap-lore.com/CapTheory/KK/Debug.html

In classic programming environments I am accustomed to a
debugger that displays the stack and understands the name
spaces defined by each of the stack frames. This pattern
does not work for the Keykos application that is
distributed in many Keykos objects running in separate
address spaces and with no conceptual stack known to the
system or debugger. A further problem in Keykos is that the
programmer who is debugging code may not be authorized to
see the implementation of other objects involved with the
current state where the problem is manifested. OO languages
typically assume that encapsulation is merely for limiting
access by programs and that a programmer can ignore such
barriers while debugging the code. In Keykos we took the
opposite view and assumed that encapsulation was really to
keep secrets, even from programmers, debuggers and DDT
(gdb). We took this attitude with some trepidation, but
business plans allowed no alternative.

Presumably the debugger would have to be given the necessary
keys (capabilities) to be able to access stack segment in a
different domain. Note that the same scheme could be extended
to distributed OSes (e.g. Alpha Real-Time Distributed Kernel)
where a "thread" may cross machine boundaries. Though Alpha
was not a capability OS.

On Tuesday, October 26, 2021 at 4:47:34 AM UTC-6, Thomas Koenig wrote:

> Some people like to write fomulas like pressure = velocity ^1.2342,
> of course it will be flagged. However, the problem is with the
> people writing the formula, not the program.

If the "correct" formula is pressure = unit-pressure * (velocity/unit-velocity) ^ 1.2342
....hopefully there is a way to prevent the compiler that is checking for
dimensioning errors from wastefully generating instructions to multiply by
one and divide by one. But of course there is, it's called optimization.

John Savard

On Tuesday, October 26, 2021 at 7:19:12 PM UTC-5, Bakul Shah wrote:
> MitchAlsup wrote:
> > On Tuesday, October 26, 2021 at 11:57:44 AM UTC-5, Ivan Godard wrote:
> >> On 10/26/2021 9:36 AM, MitchAlsup wrote:
> >
> >>> But that function needs to be provided by the compiler as part of its own run
> >>> time (support library). It is not something that is willy-nilly generated by a
> >>> semi-concerned programmer using a few compiler switches.
> >>> <
> >>> Also, how does one unwind the stack when one has no access to the parts
> >>> of the stack that are protected from the user code ?
> > <
> >> Good question. Our answer is NYF.
> > <
> > Seems to me you have 2 choices:: some HW instruction that performs job at hand
> > faking access rights {sort of what I do in HW context switches...........}
> > Or a cheap context switch to a address space with permissions to do the job in SW.
> > <
> > It seems painfully obvious that the entirety of the mechanism is to prevent user
> > (unprivileged code) from accessing those locations {security, RoP,...}
> >
> First, note that this is a separate issue from a language not
> having the primitives to examining program stack. This is a
> protection domain issue.
<
Yes, indeed, this is a pure protection issue--one designed to totally
eliminate RoP style of attacks. One can find the RET instructions,
but since one cannot see the return address, nor the preserved registers
one cannot string together a meaningful sequence of existing instruction
{beneficially or malevolently.}
<
> One can look at capability OSes
> such as KeyKOS for such issues. This is what Norm Hardy says in
> http://www.cap-lore.com/CapTheory/KK/Debug.html
>
> In classic programming environments I am accustomed to a
> debugger that displays the stack and understands the name
> spaces defined by each of the stack frames. This pattern
> does not work for the Keykos application that is
> distributed in many Keykos objects running in separate
> address spaces and with no conceptual stack known to the
> system or debugger. A further problem in Keykos is that the
> programmer who is debugging code may not be authorized to
> see the implementation of other objects involved with the
> current state where the problem is manifested. OO languages
> typically assume that encapsulation is merely for limiting
> access by programs and that a programmer can ignore such
> barriers while debugging the code. In Keykos we took the
> opposite view and assumed that encapsulation was really to
> keep secrets, even from programmers, debuggers and DDT
> (gdb). We took this attitude with some trepidation, but
> business plans allowed no alternative.
>
> Presumably the debugger would have to be given the necessary
> keys (capabilities) to be able to access stack segment in a
> different domain.
<
To bring you up to speed, Ivan and I are talking about a stack environment
where there are 2 stacks, one where visible data is stored, and one where
invisible data is stored. The user does not have read/write/execute
access to the second store, while the HW does have access, and indeed
looks to see that the pages being used are RWE=000--which means only
HW is allowed access.
<
Now debuggers are not HW, and thus the only means they have to look into
that stack area is by being a different task with a different virtual address
space where the hidden store is visible. But given the debugger knows which
task it is debugging, there is a straightforward means to access the suspended
task's header obtaining the root pointer, and then read/write thread registers,
or read from and writ to memory in the foreign address space.
>
> Note that the same scheme could be extended
> to distributed OSes (e.g. Alpha Real-Time Distributed Kernel)
> where a "thread" may cross machine boundaries. Though Alpha
> was not a capability OS.
<
I am currently wondering about implementing over-the-network ADA
rendezvous, where the accept entry accesses the caller data and
updates same before both split and go their separate ways. For
example one flight computer might be in the tail of the airplane and
it wants to rendezvous with an accept in the pilot's cockpit, and the
code works just as well if the two threads were in the same chip. Not
only does it work as well, it is the same CODE working across the
network as within a single chip.
<

Thomas Koenig wrote:
> Stephen Fuld <sfuld@alumni.cmu.edu.invalid> schrieb:
>> On 10/24/2021 12:42 AM, Thomas Koenig wrote:
>>> Ivan Godard <ivan@millcomputing.com> schrieb:
>>>
>>>> The lit history is full of efforts to put units into the type systems.
>>>> They sure look plausible but don't work. Think of a NR sqrt routine.
>>>
>>> MathCad has got this right. It is not a compiled language,
>>> but it certainly works. I use it a lot in my day job for simple
>>> engineering calculations: You see the formulas, you immediately
>>> see the output, you do input in units (like kg/h), you can convert
>>> the output to units you want.
>>>
>>> And, of course, it complains if you try to add or subtract
>>> dimensions that do not match.
>>
>> What happens if you multiply two variables with dimension "length"
>> together? Does it understand that the result is an "area"?
>
> It understands that the result is a length squared (and you can
> put in an area measurement if you feel like it).
>
> The only thing it cannot determine is the difference between
> torque and work - when I calculate a torque, a "J" automtically
> appears as a unit. I can change it to "N m" by hand, though.
>
>> And that is
>> a simple case. You can get far more complex combinations than that. It
>> seems to me that this could be a nearly bottomless pit.
>
> It works pretty well, as long as your formulas are consistent.
>
> Some people like to write fomulas like pressure = velocity ^1.2342,
> of course it will be flagged. However, the problem is with the
> people writing the formula, not the program.
>

I haven't used mathcad but I believe in general you'd need an
ability to allow a user to *define* their own units. I think
you'd also need the concept of exactness as in Scheme if you
allow conversions between metric and imperial systems.

Incidentally, some accounting packages already have to do this
-- a conversion factor, such as exchange rate or share price
may even be time dependent!

On Tuesday, October 26, 2021 at 7:19:49 PM UTC-5, Quadibloc wrote:
> On Tuesday, October 26, 2021 at 4:47:34 AM UTC-6, Thomas Koenig wrote:
>
> > Some people like to write fomulas like pressure = velocity ^1.2342,
> > of course it will be flagged. However, the problem is with the
> > people writing the formula, not the program.
>
> If the "correct" formula is pressure = unit-pressure * (velocity/unit-velocity) ^ 1.2342
> ...hopefully there is a way to prevent the compiler that is checking for
> dimensioning errors from wastefully generating instructions to multiply by
> one and divide by one. But of course there is, it's called optimization.
<
The pressure in a input duct is dependent on the velocity of the air flowing
near the duct and the pressure inside the duct--in non-linear and intriguing
ways.
>
> John Savard

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

> Thomas Koenig <tkoenig@netcologne.de> writes:

[...]

>> so your code is certainly very much non-conforming.
>
> In terms of the C standard, it's a conformant program.

The ISO C standard does not use the term conformant either in
connection with code or with programs. It does define the two
terms 'strictly conforming program' and 'conforming program'.

The condition of being a 'strictly conforming program' is so
strong that essentially no real-world programs satisfy the
condition.

In contrast, the condition of being a 'conforming program' is
extremely weak. For example, it isn't hard to construct a C
program that satisfies the 'conforming program' condition and yet
will be rejected by almost all C compilers: it must be accepted
by some conforming implementation, but need not be accepted by
any other conforming implementation.

Unfortunately the C standard does not define a term that matches
something close to what I think you mean, which is a program
that compiles and is accepted by the vast majority of C
implementations, including those without any language extensions.

MitchAlsup wrote:
> On Tuesday, October 26, 2021 at 7:19:12 PM UTC-5, Bakul Shah wrote:
>> MitchAlsup wrote:
>>> On Tuesday, October 26, 2021 at 11:57:44 AM UTC-5, Ivan Godard wrote:
>>>> On 10/26/2021 9:36 AM, MitchAlsup wrote:
>>>
>>>>> But that function needs to be provided by the compiler as part of its own run
>>>>> time (support library). It is not something that is willy-nilly generated by a
>>>>> semi-concerned programmer using a few compiler switches.
>>>>> <
>>>>> Also, how does one unwind the stack when one has no access to the parts
>>>>> of the stack that are protected from the user code ?
>>> <
>>>> Good question. Our answer is NYF.
>>> <
>>> Seems to me you have 2 choices:: some HW instruction that performs job at hand
>>> faking access rights {sort of what I do in HW context switches...........}
>>> Or a cheap context switch to a address space with permissions to do the job in SW.
>>> <
>>> It seems painfully obvious that the entirety of the mechanism is to prevent user
>>> (unprivileged code) from accessing those locations {security, RoP,...}
>>>
>> First, note that this is a separate issue from a language not
>> having the primitives to examining program stack. This is a
>> protection domain issue.
> <
> Yes, indeed, this is a pure protection issue--one designed to totally
> eliminate RoP style of attacks. One can find the RET instructions,
> but since one cannot see the return address, nor the preserved registers
> one cannot string together a meaningful sequence of existing instruction
> {beneficially or malevolently.}
> <
>> One can look at capability OSes
>> such as KeyKOS for such issues. This is what Norm Hardy says in
>> http://www.cap-lore.com/CapTheory/KK/Debug.html
>>
>> In classic programming environments I am accustomed to a
>> debugger that displays the stack and understands the name
>> spaces defined by each of the stack frames. This pattern
>> does not work for the Keykos application that is
>> distributed in many Keykos objects running in separate
>> address spaces and with no conceptual stack known to the
>> system or debugger. A further problem in Keykos is that the
>> programmer who is debugging code may not be authorized to
>> see the implementation of other objects involved with the
>> current state where the problem is manifested. OO languages
>> typically assume that encapsulation is merely for limiting
>> access by programs and that a programmer can ignore such
>> barriers while debugging the code. In Keykos we took the
>> opposite view and assumed that encapsulation was really to
>> keep secrets, even from programmers, debuggers and DDT
>> (gdb). We took this attitude with some trepidation, but
>> business plans allowed no alternative.
>>
>> Presumably the debugger would have to be given the necessary
>> keys (capabilities) to be able to access stack segment in a
>> different domain.
> <
> To bring you up to speed, Ivan and I are talking about a stack environment
> where there are 2 stacks, one where visible data is stored, and one where
> invisible data is stored. The user does not have read/write/execute
> access to the second store, while the HW does have access, and indeed
> looks to see that the pages being used are RWE=000--which means only
> HW is allowed access.

I'd put it slightly differently though. The HW has the
*mechanisms* to access anything it wants but what it is
"allowed" to access *on the behalf of a process* is subject
to SW policies (which may be cached, as in TLBs).

The two stack segments situation already sort of happens when
you make a system call. If the OS is a microkernel, it is in
effect just a multiplexer. That is, process A can call a
function in process B and the situation is the same. Even in
normal OSes, if you use, for example, RPC, the same issue.
Why should be able to do a stack trace across machines on a
single chain of RPCs! This is sort of what Alpha Kernel did
back in mid '80s. I read some RPC papers in early eighties
but as far as I remember, they didn't talk about stack
traces. But this is a real problem. When some code in a
platform-as-a-service such as Google's App engine fails, your
stack trace would stop at the process level but the real
problem may be 3 RPCs back in a chain of RPCs!

> <
> Now debuggers are not HW, and thus the only means they have to look into
> that stack area is by being a different task with a different virtual address
> space where the hidden store is visible. But given the debugger knows which
> task it is debugging, there is a straightforward means to access the suspended
> task's header obtaining the root pointer, and then read/write thread registers,
> or read from and writ to memory in the foreign address space.

Alternatively, it can make calls to a *separate* thread in
the protection domain of the stack being traced to access
stack state. Not unlike ptrace(2). In a Cap OS, it can only
do so if it is given a key to such a debugger stub thread!

>>
>> Note that the same scheme could be extended
>> to distributed OSes (e.g. Alpha Real-Time Distributed Kernel)
>> where a "thread" may cross machine boundaries. Though Alpha
>> was not a capability OS.
> <
> I am currently wondering about implementing over-the-network ADA
> rendezvous, where the accept entry accesses the caller data and
> updates same before both split and go their separate ways. For
> example one flight computer might be in the tail of the airplane and
> it wants to rendezvous with an accept in the pilot's cockpit, and the
> code works just as well if the two threads were in the same chip. Not
> only does it work as well, it is the same CODE working across the
> network as within a single chip.

Should be doable.

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

>> [.. volatile ..]
>
> These discussions of volatile, and execution order wrt timing,
> gave me an idea: perhaps C (and other languages) should allow
> marking functions (subprograms) as "volatile", with the meaning
> that all of the effects of a call of that function (including use
> of processor time) should be ordered as volatile accesses are
> ordered, with respect to other volatile accesses.
>
> For example, if x and y are volatile variables, and foo is a
> volatile function, then in this code
>
> x = 1;
> foo ();
> y = 1;
>
> we would be sure that all effects and all dynamic resource usage
> of the foo() call would occur between the assignments to x and to
> y.
>
> A more flexible approach would be to mark selected function calls
> as volatile, in the same way that C allows in-line use of
> pointer-to-volatile to force a volatile access to an object that
> is not itself marked volatile. Something like:
>
> x = 1;
> (volatile) foo ();
> y = 1;
>
> Are volatile functions and/or volatile function calls a good idea?

Let me propose a simpler mechanism that I believe does a better
job of what (I think) it is you want to do. By way of example:

* (_Volatile int *) &x = 1;
foo();
* (_Volatile int *) &y = 1;

The semantics of the new _Volatile qualifier, speaking
informally, is that it imposes a sequence point in the actual
machine, not just in the abstract machine. So all logically
previous evaluations must be finished before a volatile access,
and after a volatile access all logically subsequent evaluations
must not yet be started. To say that another way, no expression
evaluation (including side effects) may be "moved across" a
read or write to a _Volatile object.

Note that foo() is a call to an ordinary function, and expressions
in foo() may be re-ordered in all the usual ways, except that they
must not be "moved across" the assignment to x or the assignment
to y.

On 10/26/2021 6:10 PM, Bakul Shah wrote:
> MitchAlsup wrote:
>> On Tuesday, October 26, 2021 at 7:19:12 PM UTC-5, Bakul Shah wrote:
>>> MitchAlsup wrote:
>>>> On Tuesday, October 26, 2021 at 11:57:44 AM UTC-5, Ivan Godard wrote:
>>>>> On 10/26/2021 9:36 AM, MitchAlsup wrote:
>>>>
>>>>>> But that function needs to be provided by the compiler as part of
>>>>>> its own run
>>>>>> time (support library). It is not something that is willy-nilly
>>>>>> generated by a
>>>>>> semi-concerned programmer using a few compiler switches.
>>>>>> <
>>>>>> Also, how does one unwind the stack when one has no access to the
>>>>>> parts
>>>>>> of the stack that are protected from the user code ?
>>>> <
>>>>> Good question. Our answer is NYF.
>>>> <
>>>> Seems to me you have 2 choices:: some HW instruction that performs
>>>> job at hand
>>>> faking access rights {sort of what I do in HW context
>>>> switches...........}
>>>> Or a cheap context switch to a address space with permissions to do
>>>> the job in SW.
>>>> <
>>>> It seems painfully obvious that the entirety of the mechanism is to
>>>> prevent user
>>>> (unprivileged code) from accessing those locations {security, RoP,...}
>>>>
>>> First, note that this is a separate issue from a language not
>>> having the primitives to examining program stack. This is a
>>> protection domain issue.
>> <
>> Yes, indeed, this is a pure protection issue--one designed to totally
>> eliminate RoP style of attacks. One can find the RET instructions,
>> but since one cannot see the return address, nor the preserved registers
>> one cannot string together a meaningful sequence of existing instruction
>> {beneficially or malevolently.}
>> <
>>>                                               One can look at
>>> capability OSes
>>> such as KeyKOS for such issues. This is what Norm Hardy says in
>>> http://www.cap-lore.com/CapTheory/KK/Debug.html
>>>
>>> In classic programming environments I am accustomed to a
>>> debugger that displays the stack and understands the name
>>> spaces defined by each of the stack frames. This pattern
>>> does not work for the Keykos application that is
>>> distributed in many Keykos objects running in separate
>>> address spaces and with no conceptual stack known to the
>>> system or debugger. A further problem in Keykos is that the
>>> programmer who is debugging code may not be authorized to
>>> see the implementation of other objects involved with the
>>> current state where the problem is manifested. OO languages
>>> typically assume that encapsulation is merely for limiting
>>> access by programs and that a programmer can ignore such
>>> barriers while debugging the code. In Keykos we took the
>>> opposite view and assumed that encapsulation was really to
>>> keep secrets, even from programmers, debuggers and DDT
>>> (gdb). We took this attitude with some trepidation, but
>>> business plans allowed no alternative.
>>>
>>> Presumably the debugger would have to be given the necessary
>>> keys (capabilities) to be able to access stack segment in a
>>> different domain.
>> <
>> To bring you up to speed, Ivan and I are talking about a stack
>> environment
>> where there are 2 stacks, one where visible data is stored, and one where
>> invisible data is stored. The user does not have read/write/execute
>> access to the second store, while the HW does have access, and indeed
>> looks to see that the pages being used are RWE=000--which means only
>> HW is allowed access.
>
> I'd put it slightly differently though. The HW has the
> *mechanisms* to access anything it wants but what it is
> "allowed" to access *on the behalf of a process* is subject
> to SW policies (which may be cached, as in TLBs).
>
> The two stack segments situation already sort of happens when
> you make a system call. If the OS is a microkernel, it is in
> effect just a multiplexer. That is, process A can call a
> function in process B and the situation is the same. Even in
> normal OSes, if you use, for example, RPC, the same issue.
> Why should be able to do a stack trace across machines on a
> single chain of RPCs! This is sort of what Alpha Kernel did
> back in mid '80s. I read some RPC papers in early eighties
> but as far as I remember, they didn't talk about stack
> traces. But this is a real problem. When some code in a
> platform-as-a-service such as Google's App engine fails, your
> stack trace would stop at the process level but the real
> problem may be 3 RPCs back in a chain of RPCs!
>
>> <
>> Now debuggers are not HW, and thus the only means they have to look into
>> that stack area is by being a different task with a different virtual
>> address
>> space where the hidden store is visible. But given the debugger knows
>> which
>> task it is debugging, there is a straightforward means to access the
>> suspended
>> task's header obtaining the root pointer, and then read/write thread
>> registers,
>> or read from and writ to memory in the foreign address space.
>
> Alternatively, it can make calls to a *separate* thread in
> the protection domain of the stack being traced to access
> stack state.  Not unlike ptrace(2). In a Cap OS, it can only
> do so if it is given a key to such a debugger stub thread!
>
>>>
>>>                                  Note that the same scheme could be
>>> extended
>>> to distributed OSes (e.g. Alpha Real-Time Distributed Kernel)
>>> where a "thread" may cross machine boundaries. Though Alpha
>>> was not a capability OS.
>> <
>> I am currently wondering about implementing over-the-network ADA
>> rendezvous, where the accept entry accesses the caller data and
>> updates same before both split and go their separate ways. For
>> example one flight computer might be in the tail of the airplane and
>> it wants to rendezvous with an accept in the pilot's cockpit, and the
>> code works just as well if the two threads were in the same chip. Not
>> only does it work as well, it is the same CODE working across the
>> network as within a single chip.
>
> Should be doable.

Mill is a grant system, not caps, but it can control debug access in
essentially the same way. In either system, there's a question of how
does the debugger get given the access and by whom; how does it identify
which domain it wants; and how does it set breakpoints (securely) in
services that it hasn't RPCd to yet and which will be concurrently
serving other clients.

Semantics is harder than code.

Ivan Godard wrote:
> On 10/26/2021 6:10 PM, Bakul Shah wrote:
>> MitchAlsup wrote:
>> <
>>> To bring you up to speed, Ivan and I are talking about a stack
>>> environment
>>> where there are 2 stacks, one where visible data is stored, and one
>>> where
>>> invisible data is stored. The user does not have read/write/execute
>>> access to the second store, while the HW does have access, and indeed
>>> looks to see that the pages being used are RWE=000--which means only
>>> HW is allowed access.
>>
>> I'd put it slightly differently though. The HW has the
>> *mechanisms* to access anything it wants but what it is
>> "allowed" to access *on the behalf of a process* is subject
>> to SW policies (which may be cached, as in TLBs).
>>
>> The two stack segments situation already sort of happens when
>> you make a system call. If the OS is a microkernel, it is in
>> effect just a multiplexer. That is, process A can call a
>> function in process B and the situation is the same. Even in
>> normal OSes, if you use, for example, RPC, the same issue.
>> Why should be able to do a stack trace across machines on a
>> single chain of RPCs! This is sort of what Alpha Kernel did
>> back in mid '80s. I read some RPC papers in early eighties
>> but as far as I remember, they didn't talk about stack
>> traces. But this is a real problem. When some code in a
>> platform-as-a-service such as Google's App engine fails, your
>> stack trace would stop at the process level but the real
>> problem may be 3 RPCs back in a chain of RPCs!
....
>
> Mill is a grant system, not caps, but it can control debug access in
> essentially the same way. In either system, there's a question of how
> does the debugger get given the access and by whom; how does it identify
> which domain it wants; and how does it set breakpoints (securely) in
> services that it hasn't RPCd to yet and which will be concurrently
> serving other clients.

This is not possible today so I am speculating:

- you'd have to carry the breakpoint state with the gate-call, and
somehow apply it when the call is made or see below.
- you'd have to COW the page where the bkpt is to be set (so that
no one other than the caller gets a bkpt). This will be difficult
to impossible on a single address machine!
- may be the service will have to be accessed via a "debug" port!
- as you put it, a bigger issue is protection/permission semantics.
As an example, a customer should not be able to set a bkpt in a
bank's server code! And even a debugger should have extremely
limited visibility.
- I think this calls for *cooperative* debugging. There is a bank guy
who runs the bank debugger in collaboration with a customer service
guy.

Seems like one can write a research paper or few on this topic!

>
> Semantics is harder than code.

Yup.

EricP <ThatWouldBeTelling@thevillage.com> writes:

> Tim Rentsch wrote:
>
>> Ivan Godard <ivan@millcomputing.com> writes:
>>
>>> As for your sum of sat+wrap+trunc, there's a simple solution: don't
>>> pollute the types of the operations with the types of the
>>> arguments. Let + take arguments and produce results from Z, and then
>>> check when that is assigned or passed to see if it conforms to the
>>> well defined and unambiguous type of the destination. [...]
>>
>> That's fine if that behavior is what is wanted. My comment is
>> about a wider range of application, including for example
>> combination rules more like what C or C++ have. What you are
>> saying, in effect, is that user-defined types work just fine, but
>> only if we are willing to change how things work; in short they
>> offer a great solution, but to a different problem.
>
> What changes for strong typing is that if you mix incompatible
> types you must specify that you intended to do so.

Having strong typing does not imply that expressions must use
homogeneous types or that there are no automatic conversions.
The term I think you're looking for is strict typing; strong
typing means something else.

> [..discussion of type conversion in C arithmetic expressions..]

I am thoroughly familiar with what happens with mixed types in C
arithmetic expressions. I'm not offering any argument either for
or against those rules. My comment is only about the difficulty
of implementing a similar, but more elaborate because of overflow
behavior choices, set of rules, using user-defined types, instead
of in the language definition.

EricP <ThatWouldBeTelling@thevillage.com> writes:

> Tim Rentsch wrote:
>
>> Niklas Holsti <niklas.holsti@tidorum.invalid> writes:
>>
>>> In the Ada case, the idea (= spirit) is that you cannot combine
>>> different types in that way -- for example, you cannot by default
>>> add a signed integer to a modular integer. The programmer has to
>>> convert one or both operands explicitly to compatible types,
>>
>> I understand. My point is about environments like C or C++
>> where mixing of different types is allowed, and the result
>> type depends on the operand types.
>
> [..behavior of mixed-type expressions in C..]

Basically the same response that I gave to your other recent
post.

>>> or [let the compiler know in some other way what it should do in
>>> various specific cases, such as function overloading]
>>
>> This alternative illustrates the kinds of problems I'm talking
>> about. Types have to know, in some sense, about other types,
>> and the resultant code growth in N*N rather than linear.
>
> Hmmm... under the hood there are only the physical types that the
> hardware supports, and the compiler has to know how to change
> those. e.g. integer, single, double, decimal(m.n).
>
> Types may have some additional logical rules applied
> and a conversion should apply those too.
> e.g. integer range 1..10
>
> But a strong type language compiler doesn't generate all conversions
> between all logical and physical types just in case someone needs
> one. It has a set of converters for the 3 or 4 physical types, just
> like C. Most conversion checks result from assigning a larger to
> smaller integer so it checks that you are not putting 10 lbs into a
> 5 lbs bag.

Here again is a discussion of a problem different than the
problem I've been talking about. Kind of like the drunk who is
looking for his keys under a streetlight, rather than where he
lost them, because under the streetlight the light is better.

MitchAlsup <MitchAlsup@aol.com> writes:

> On Monday, October 25, 2021 at 12:59:40 PM UTC-5, Tim Rentsch wrote:
>
>> MitchAlsup <Mitch...@aol.com> writes:
>>
>>> On Saturday, October 23, 2021 at 6:09:53 PM UTC-5, Tim Rentsch wrote:
>
>>>> In truth GC works just fine for many or most application areas,
>>>
>>> The other truth is that most applications do not need any GC
>>> whatsoever. {Where most means over 50%}
>>
>> That is a vacuous statement.
>
> OK, how much GC does 'cat' need ? 'more' ? 'less', 'ls', '|',
> 'vi',.....'dev/null',...

Here the word vacuous does not mean wrong or stupid but devoid
of any useful content. Sorry for the ambiguity.

Quadibloc <jsavard@ecn.ab.ca> schrieb:
> On Sunday, October 24, 2021 at 1:42:23 AM UTC-6, Thomas Koenig wrote:
>> Ivan Godard <iv...@millcomputing.com> schrieb:
>> > The lit history is full of efforts to put units into the type systems.
>> > They sure look plausible but don't work. Think of a NR sqrt routine.
>
>> MathCad has got this right. It is not a compiled language,
>> but it certainly works. I use it a lot in my day job for simple
>> engineering calculations: You see the formulas, you immediately
>> see the output, you do input in units (like kg/h), you can convert
>> the output to units you want.
>>
>> And, of course, it complains if you try to add or subtract
>> dimensions that do not match.
>>
>> (Notice I said "dimensions" in the last sentence - adding an inch
>> to a meter is fine, because both get converted automatically,
>> but adding a meter to a second is an error. Nomenclature:
>> Length is a dimension, meter or inch are units, of length
>> in this case).
>>
>> It even handles square roots of units and dimensions, which
>> are sometimes used, as characteristics of distillations colums,
>> for example.
>>
>> It handles units and dimensions as floating point numbers.
>> For dimensions, using rational numbers would probably be better.
>
> This is interesting; I am glad to hear that a language is available
> that can handle physical quantities with units correctly, thus
> reducing problems created by mistakes in dimensional analysis
> by the programmer.

MathCad is more like a calculation paper sheet; you enter variable
assignments with formulas (and some programming, but that is quite
limited and rather painful for anything more complex) on a sheet-like
graph.

> And given that statement of the _benefit_ of doing this, I think
> that one _could_ in a compiled language flag floating-point
> quantities with units, so that the compiler would give an error or
> warning if incorrect arithmetic operations were specified with them.

I would actually prefer rational numbers for dimensions, for
generality.

There is at least one unit in frequent use by people who
design distillation colums which has the dimension of
(IIRC) of something * Pa^(1/2), which makes sense because
it is linear with the velocity.

> This reminds me: on my web site, in my description of a
> proposed language, I've proposed an extension to the type
> system for languages like FORTRAN that are used for numerical
> computation.
>
> The language is based on one I'd come up with many years ago
> back when I was a student in University. It was basically a fancy
> Fortran with additional ease of use features.
>
> So if A, B, and C are arrays, one could write A=B+C or A=B*C
> instead of having to write a DO loop.

Fortran 90 so far.

>
> I spoke to someone else about it, and I noted that A=B*C was
> element-by-element, not matrix multiplication, in response to
> a question. The other fellow thought I was being too slavish
> in following APL.
>
> I thought about the matter further.
>
> I felt I _was_ right in handling _arrays_ that way. Making matrix
> multiplication the default for multiplying arrays was giving
> inappropriate semantic content to the notion of an array.

Fortran has the MATMUL intrinsic for that.

> But I felt the other fellow had a point too. Matrix multiplication
> is important in scientific and engineering computation.
>
> So I came up with what was, to me, a solution.
>
> In FORTRAN, there is a COMPLEX data type. In my language,
> I had already added, as an obvious extension, a QUATERNION
> data type.
>
> Well, then.
>
> What about a MATRIX data type?

You can typedef a matrix in Fortran, and you can give
it user-defined operators.

For one occasion, I have written a vector type in Fortran which
implements scalar product, cross product (with an operator .x.) and
the norm.

Anton Ertl <anton@mips.complang.tuwien.ac.at> schrieb:
> Thomas Koenig <tkoenig@netcologne.de> writes:
>>-fno-reorder-blocks puts the compiler back before the very first
>>FORTRAN compiler, which invented basic blocks and moving them
>>around for optimization.
>
> So you want to imply that this is going to slow gforth down?

Not necessarily, but it does so quite often; I've seen enough
bug reports where additional branches caused by this caused
quite a slowdown.

>Let's
> test this hypothesis (gcc-10.2 on Skylake):
>
> with with without
> -fno-reorder-blocks
> default --no-dynamic default
> 1358614162 1834084907 1959794599 cycles:u onebench.fs
> 3209609889 4229597875 4499690628 instructions:u onebench.fs
>
> What happens is that without -fno-reorder-blocks a sanity check in
> Gforth disables Gforth's dynamic superinstruction optimization

Duh.

>(the
> sanity check sees that the code is not arranged in one of the ways
> needed for the optimization). Interestingly, the slowdown is slightly
> worse than when disabling dynamic superinstructions directly, so there
> is an additional effect at work. In any case, your implied claim that
> -fno-reorder-blocks generally hurts performance is debunked.

You have a habit of reading things into my posts that I did not
write, and then refuting them. Additionally, your grasp of compiler
optimzation seems rather weak.

Does every optimization help every program? No, and I made no
such claim. If you want another counter-example, I spent quite
some time optimizing MATMUL for gfortran. Does that optimzation
help a program that does not perform MATMUL? No.

Does such basic block reordering often help? Definitely.

>
>>-fno-inline can be a performance killer if people prefer static
>>inline functions, which are type-safe and evaluate their arguments
>>only once over macros.
>
> Ok, after reinstating -fno-reorder-blocks, let's test this hypothesis:

So, you do not use that particular style in your code. Fine.

A good test would have been to check, on code where it matters,

#define MY_FMAX(a,b) (a>b? a: b)

versus

static MY_FMAX (float a, float b)
{ return a > b;
}

>>But then, I understand from an old PR of yours (PR 15252) that
>>gforth makes heavy use of "goto variable", an extension that
>>(IIRC) was originally put into gcc by Craig Burley to support
>>assigned gotos in FORTRAN,
>
> How does adding an extension to C help Fortran?

It was the other way around. Craig added assigned GOTOs for g77,
and somebody thought it was a good idea to add it to C, too,
once the infrastructure had been put in. I think that this
was a bad idea.

>
>>so your code is certainly very much
>>non-conforming.
>
> In terms of the C standard, it's a conformant program.
>
>>Luckily, assigned gotos have been depecated
>>in Fortran.
>
> I guess nobody is implementing virtual-machine interpreters in Fortran
> these days, much less the kind of dynamic native code generation that
> Gforth uses. Both techniques use the labels-as-values extension in
> GNU C, and have been used in several programming language
> implementations. It is used so widely that icc, clang and tcc have
> implemented this extension as well.

So the cancer spread.

There are standard-conforming ways of doing the same, such as
switch statements followed by goto. I can imagine that there
are problems with speed using that approach.

As your use of options to dumb down gcc shows, by using that rarely
used extension, you are living dangerously - not many people
are going to find something that breaks when used togeter with
"goto variable", and getting people to care about such an extension
to the C standard may be even harder. This is going to affect only
very small minority of users.

I can understand, however, that "goto variable" can be faster
because of inefficiencies in code generation for the switch
statement. That can be tricky, and I have submitted at least
one still open bug report about that.

If this were my project, my solution would be to develop standard
C constructs as an alternate, identify bottlenecks in speed and
submit missed-optimization PRs for them.

So, a proposal: Do you have a piece of code which works appreciably
faster using "goto variable" rather than using switch and goto?

If you have it, I can submit a PR for it, if you want to.

>But nobody implements programming
> languages in Fortran these days, so if assigned gotos go away, maybe
> nobody will miss them.

You could use Fortran, but actually we use C (well, a very limited
subset of C++) for gfortran. No assigned gotos in the code, though.

On 27/10/2021 03:28, Tim Rentsch wrote:
> Niklas Holsti <niklas.holsti@tidorum.invalid> writes:
>
>>> [.. volatile ..]
>>
>> These discussions of volatile, and execution order wrt timing,
>> gave me an idea: perhaps C (and other languages) should allow
>> marking functions (subprograms) as "volatile", with the meaning
>> that all of the effects of a call of that function (including use
>> of processor time) should be ordered as volatile accesses are
>> ordered, with respect to other volatile accesses.
>>
>> For example, if x and y are volatile variables, and foo is a
>> volatile function, then in this code
>>
>> x = 1;
>> foo ();
>> y = 1;
>>
>> we would be sure that all effects and all dynamic resource usage
>> of the foo() call would occur between the assignments to x and to
>> y.
>>
>> A more flexible approach would be to mark selected function calls
>> as volatile, in the same way that C allows in-line use of
>> pointer-to-volatile to force a volatile access to an object that
>> is not itself marked volatile. Something like:
>>
>> x = 1;
>> (volatile) foo ();
>> y = 1;
>>
>> Are volatile functions and/or volatile function calls a good idea?
>
> Let me propose a simpler mechanism that I believe does a better
> job of what (I think) it is you want to do. By way of example:
>
> * (_Volatile int *) &x = 1;
> foo();
> * (_Volatile int *) &y = 1;
>
> The semantics of the new _Volatile qualifier, speaking
> informally, is that it imposes a sequence point in the actual
> machine, not just in the abstract machine. So all logically
> previous evaluations must be finished before a volatile access,
> and after a volatile access all logically subsequent evaluations
> must not yet be started. To say that another way, no expression
> evaluation (including side effects) may be "moved across" a
> read or write to a _Volatile object.
>
> Note that foo() is a call to an ordinary function, and expressions
> in foo() may be re-ordered in all the usual ways, except that they
> must not be "moved across" the assignment to x or the assignment
> to y.
>

That does sound like a simpler mechanism for the same effect. But
perhaps we can go further and simpler:

x = 1;
_Execution_barrier();
foo();
_Execution_barrier();
y = 1;

_Execution_barrier() would be an implementation-dependent macro that
imposes a sequence point in the actual machine, in the manner described
by Tim above. I see no advantage to making it a qualifier or tying it
to a particular lvalue access, since it acts on the entire machine.

It would still be a big challenge (I believe) to get clear and precise
definitions for how this would work, but I think it would be easier to
define, understand and implement than "volatile functions" or a new
"_Volatile" qualifier.

(Note to Niklas, Ivan, etc. - Tim has a strong policy of never answering
my posts. I don't know if he reads them, or has killfiled me entirely.
So if any of you want his opinion on this suggestion, someone may have
to re-post it.)

On 10/26/2021 3:47 AM, Thomas Koenig wrote:
> Stephen Fuld <sfuld@alumni.cmu.edu.invalid> schrieb:
>> On 10/24/2021 12:42 AM, Thomas Koenig wrote:
>>> Ivan Godard <ivan@millcomputing.com> schrieb:
>>>
>>>> The lit history is full of efforts to put units into the type systems.
>>>> They sure look plausible but don't work. Think of a NR sqrt routine.
>>>
>>> MathCad has got this right. It is not a compiled language,
>>> but it certainly works. I use it a lot in my day job for simple
>>> engineering calculations: You see the formulas, you immediately
>>> see the output, you do input in units (like kg/h), you can convert
>>> the output to units you want.
>>>
>>> And, of course, it complains if you try to add or subtract
>>> dimensions that do not match.
>>
>> What happens if you multiply two variables with dimension "length"
>> together? Does it understand that the result is an "area"?
>
> It understands that the result is a length squared (and you can
> put in an area measurement if you feel like it).

I guess the question is, given a variable L of dimension "Length", and a
variable A of dimension "Area", does it complain at a statement like

A = A + (L*L)

--
- Stephen Fuld
(e-mail address disguised to prevent spam)

On 2021-10-27 4:28, Tim Rentsch wrote:
> Niklas Holsti <niklas.holsti@tidorum.invalid> writes:
>
>>> [.. volatile ..]
>>
>> These discussions of volatile, and execution order wrt timing,
>> gave me an idea: perhaps C (and other languages) should allow
>> marking functions (subprograms) as "volatile", with the meaning
>> that all of the effects of a call of that function (including use
>> of processor time) should be ordered as volatile accesses are
>> ordered, with respect to other volatile accesses.
>>
>> For example, if x and y are volatile variables, and foo is a
>> volatile function, then in this code
>>
>> x = 1;
>> foo ();
>> y = 1;
>>
>> we would be sure that all effects and all dynamic resource usage
>> of the foo() call would occur between the assignments to x and to
>> y.
>>
>> A more flexible approach would be to mark selected function calls
>> as volatile, in the same way that C allows in-line use of
>> pointer-to-volatile to force a volatile access to an object that
>> is not itself marked volatile. Something like:
>>
>> x = 1;
>> (volatile) foo ();
>> y = 1;
>>
>> Are volatile functions and/or volatile function calls a good idea?
>
> Let me propose a simpler mechanism that I believe does a better
> job of what (I think) it is you want to do. By way of example:
>
> * (_Volatile int *) &x = 1;
> foo();
> * (_Volatile int *) &y = 1;
>
> The semantics of the new _Volatile qualifier, speaking
> informally, is that it imposes a sequence point in the actual
> machine, not just in the abstract machine. So all logically
> previous evaluations must be finished before a volatile access,
> and after a volatile access all logically subsequent evaluations
> must not yet be started. To say that another way, no expression
> evaluation (including side effects) may be "moved across" a
> read or write to a _Volatile object.
>
> Note that foo() is a call to an ordinary function, and expressions
> in foo() may be re-ordered in all the usual ways, except that they
> must not be "moved across" the assignment to x or the assignment
> to y.

That is exactly the semantics I intended, as I described in my response
to David Brown. So we are creating the same functionality but using
different source-code mechanisms - my suggestion marks the call (or the
function), and interacts with the existing "volatile" mechanism, while
your suggestion defines a new and stronger "_Volatile" access. I suppose
only compiler implementors can tell us which of the two is easier to
implement.

Your suggestion has the benefit that the "immovable" code is not
necessarily a function call, as in my proposal. However, I had in mind
an extension to let any code block be defined as immovable in this
sense, perhaps as

(volatile) { some code ... };

which would let the programmer use a local encapsulation of the
immovable code, without defining a function just for that purpose.

On 27/10/2021 08:24, Thomas Koenig wrote:
> Anton Ertl <anton@mips.complang.tuwien.ac.at> schrieb:

>> I guess nobody is implementing virtual-machine interpreters in Fortran
>> these days, much less the kind of dynamic native code generation that
>> Gforth uses. Both techniques use the labels-as-values extension in
>> GNU C, and have been used in several programming language
>> implementations. It is used so widely that icc, clang and tcc have
>> implemented this extension as well.
>
> So the cancer spread.
>
> There are standard-conforming ways of doing the same, such as
> switch statements followed by goto. I can imagine that there
> are problems with speed using that approach.
>
> As your use of options to dumb down gcc shows, by using that rarely
> used extension, you are living dangerously - not many people
> are going to find something that breaks when used togeter with
> "goto variable", and getting people to care about such an extension
> to the C standard may be even harder. This is going to affect only
> very small minority of users.
>
> I can understand, however, that "goto variable" can be faster
> because of inefficiencies in code generation for the switch
> statement. That can be tricky, and I have submitted at least
> one still open bug report about that.
>
> If this were my project, my solution would be to develop standard
> C constructs as an alternate, identify bottlenecks in speed and
> submit missed-optimization PRs for them.
>
> So, a proposal: Do you have a piece of code which works appreciably
> faster using "goto variable" rather than using switch and goto?
>
> If you have it, I can submit a PR for it, if you want to.
>
C compilers are almost always better at optimising code written in clear
and standard ways - they compiler can get more information from such
code, and the compiler developers put most effort into working with
common code constructs. When people "manually optimise" their C code,
such as with these labels-as-value arrays and hand-written jump tables,
it's difficult for a compiler to see what is happening, and difficult to
optimise - normal optimisation passes may regress performance.

You often see such "manually optimised" code as left-overs in older
programs, from days when compilers were weaker and processors were
simpler and more consistent. There was a time when this kind of thing
made a big improvement to a lot of code.

Modern processors vary quite a bit in how they actually handle such code
- the best strategy for a switch structure might be jump tables, tree of
conditionals, combining branches into calculations or conditional moves,
or various other possibilities. It can depend on the target processor
and the details of its superscaler execution, branch predictions,
speculative execution, caches, etc. And it can depend greatly on the
rest of the code around the section. Sometimes the programmer knows
most about these details - often it is the compiler.

I can't say anything specific about this particular section of code.
Maybe the manual label tables and unusual choice of optimisation flags
is as good as it gets here. But to me, that's just a small step from
programming in assembly, missing many of the benefits of using a
high-level language.

As a general point, I agree with Thomas here - write the code in a
clear, maintainable modern style, taking advantage of some compiler
extensions (such as having a "default : __builtin_unreachable();" clause
in a switch), and then study and measure the generated results for
different processors. If there is scope for improvement, work with the
compiler developers on it - that way, /everyone/ benefits. Maybe there
are ways to get better results on a wider scope. Perhaps what is needed
is a new "__attribute__" for switch statements to let the programmer
determine the strategy or provide hints about the likelihood of
different cases.

On 2021-10-27 8:41, Thomas Koenig wrote:
> Quadibloc <jsavard@ecn.ab.ca> schrieb:
>> On Sunday, October 24, 2021 at 1:42:23 AM UTC-6, Thomas Koenig wrote:
>>> Ivan Godard <iv...@millcomputing.com> schrieb:
>>>> The lit history is full of efforts to put units into the type systems.
>>>> They sure look plausible but don't work. Think of a NR sqrt routine.
>>
>>> MathCad has got this right. It is not a compiled language,
>>> but it certainly works. I use it a lot in my day job for simple
>>> engineering calculations: You see the formulas, you immediately
>>> see the output, you do input in units (like kg/h), you can convert
>>> the output to units you want.
>>>
>>> And, of course, it complains if you try to add or subtract
>>> dimensions that do not match.
>>>
>>> (Notice I said "dimensions" in the last sentence - adding an inch
>>> to a meter is fine, because both get converted automatically,
>>> but adding a meter to a second is an error. Nomenclature:
>>> Length is a dimension, meter or inch are units, of length
>>> in this case).
>>>
>>> It even handles square roots of units and dimensions, which
>>> are sometimes used, as characteristics of distillations colums,
>>> for example.
>>>
>>> It handles units and dimensions as floating point numbers.
>>> For dimensions, using rational numbers would probably be better.
>>
>> This is interesting; I am glad to hear that a language is available
>> that can handle physical quantities with units correctly, thus
>> reducing problems created by mistakes in dimensional analysis
>> by the programmer.
>
> MathCad is more like a calculation paper sheet; you enter variable
> assignments with formulas (and some programming, but that is quite
> limited and rather painful for anything more complex) on a sheet-like
> graph.
>
>
>> And given that statement of the _benefit_ of doing this, I think
>> that one _could_ in a compiled language flag floating-point
>> quantities with units, so that the compiler would give an error or
>> warning if incorrect arithmetic operations were specified with them.
>
> I would actually prefer rational numbers for dimensions, for
> generality.

The GNAT Ada compiler from AdaCore has an extension to provide a
compile-time dimensional analysis system. It is not (yet) part of the
Ada standard, though. It is described in
https://www.adacore.com/gems/gem-136-how-tall-is-a-kilogram.

The system lets one define one's own system of dimensions, supports
rational dimension powers, and lets one define how units are indicated
in output, for example "m" for meters.

The system does not provide easy conversion between different units of
measurement, such as metric and imperial units, but it does detect and
reject invalid mixtures, such as an attempt to add a length in meters to
a length in feet. This check uses the ordinary strong typing rules,
while the dimensionality check uses Ada subtypes extended with a
dimension "aspect".

On 2021-10-27 9:38, David Brown wrote:
> On 27/10/2021 03:28, Tim Rentsch wrote:
>> Niklas Holsti <niklas.holsti@tidorum.invalid> writes:
>>
>>>> [.. volatile ..]
>>>
>>> These discussions of volatile, and execution order wrt timing,
>>> gave me an idea: perhaps C (and other languages) should allow
>>> marking functions (subprograms) as "volatile", with the meaning
>>> that all of the effects of a call of that function (including use
>>> of processor time) should be ordered as volatile accesses are
>>> ordered, with respect to other volatile accesses.
>>>
>>> For example, if x and y are volatile variables, and foo is a
>>> volatile function, then in this code
>>>
>>> x = 1;
>>> foo ();
>>> y = 1;
>>>
>>> we would be sure that all effects and all dynamic resource usage
>>> of the foo() call would occur between the assignments to x and to
>>> y.
>>>
>>> A more flexible approach would be to mark selected function calls
>>> as volatile, in the same way that C allows in-line use of
>>> pointer-to-volatile to force a volatile access to an object that
>>> is not itself marked volatile. Something like:
>>>
>>> x = 1;
>>> (volatile) foo ();
>>> y = 1;
>>>
>>> Are volatile functions and/or volatile function calls a good idea?
>>
>> Let me propose a simpler mechanism that I believe does a better
>> job of what (I think) it is you want to do. By way of example:
>>
>> * (_Volatile int *) &x = 1;
>> foo();
>> * (_Volatile int *) &y = 1;
>>
>> The semantics of the new _Volatile qualifier, speaking
>> informally, is that it imposes a sequence point in the actual
>> machine, not just in the abstract machine. So all logically
>> previous evaluations must be finished before a volatile access,
>> and after a volatile access all logically subsequent evaluations
>> must not yet be started. To say that another way, no expression
>> evaluation (including side effects) may be "moved across" a
>> read or write to a _Volatile object.
>>
>> Note that foo() is a call to an ordinary function, and expressions
>> in foo() may be re-ordered in all the usual ways, except that they
>> must not be "moved across" the assignment to x or the assignment
>> to y.
>>
>
> That does sound like a simpler mechanism for the same effect. But
> perhaps we can go further and simpler:
>
> x = 1;
> _Execution_barrier();
> foo();
> _Execution_barrier();
> y = 1;
>
> _Execution_barrier() would be an implementation-dependent macro that
> imposes a sequence point in the actual machine, in the manner described
> by Tim above. I see no advantage to making it a qualifier or tying it
> to a particular lvalue access, since it acts on the entire machine.

I like this proposal better than Tim's _Volatile. It provides the same
functionality as the "volatile function" proposal, and looks like it
could be more straight-forward to implement. But I think (and I think
you agree) that it should be limited to act on a single core (= the
current thread) and should not affect other threads or other cores in
the machine.

EricP <ThatWouldBeTelling@thevillage.com> writes:
>For integer * and / signed and unsigned map to different instructions.

For 2s-complement representation of signed numbers and wrapping on
overflow non-widening multiplication is the same for signed and
unsigned numbers, and therefore the same instruction. Note that,
e.g., AMD64 only has two widening multiplication instructions MUL
(unsigned) and IMUL (signed) with one explicit operand, but only one
non-widening instruction: IMUL with two or three explicit operands.

That's because

((a mod 2^n) * (b mod 2^n)) mod 2^n = (a*b) mod 2^n

(like for addition and subtraction).

Whether you interpret the mod 2^n numbers as signed or unsigned is
immaterial.

The "/" operation is a different kettle of fish, though.

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

On 27/10/2021 09:26, Niklas Holsti wrote:
> On 2021-10-27 9:38, David Brown wrote:
>> On 27/10/2021 03:28, Tim Rentsch wrote:
>>> Niklas Holsti <niklas.holsti@tidorum.invalid> writes:
>>>
>>>>> [.. volatile ..]
>>>>
>>>> These discussions of volatile, and execution order wrt timing,
>>>> gave me an idea:  perhaps C (and other languages) should allow
>>>> marking functions (subprograms) as "volatile", with the meaning
>>>> that all of the effects of a call of that function (including use
>>>> of processor time) should be ordered as volatile accesses are
>>>> ordered, with respect to other volatile accesses.
>>>>
>>>> For example, if x and y are volatile variables, and foo is a
>>>> volatile function, then in this code
>>>>
>>>>     x = 1;
>>>>     foo ();
>>>>     y = 1;
>>>>
>>>> we would be sure that all effects and all dynamic resource usage
>>>> of the foo() call would occur between the assignments to x and to
>>>> y.
>>>>
>>>> A more flexible approach would be to mark selected function calls
>>>> as volatile, in the same way that C allows in-line use of
>>>> pointer-to-volatile to force a volatile access to an object that
>>>> is not itself marked volatile.  Something like:
>>>>
>>>>     x = 1;
>>>>     (volatile) foo ();
>>>>     y = 1;
>>>>
>>>> Are volatile functions and/or volatile function calls a good idea?
>>>
>>> Let me propose a simpler mechanism that I believe does a better
>>> job of what (I think) it is you want to do.  By way of example:
>>>
>>>      * (_Volatile int *) &x = 1;
>>>      foo();
>>>      * (_Volatile int *) &y = 1;
>>>
>>> The semantics of the new _Volatile qualifier, speaking
>>> informally, is that it imposes a sequence point in the actual
>>> machine, not just in the abstract machine.  So all logically
>>> previous evaluations must be finished before a volatile access,
>>> and after a volatile access all logically subsequent evaluations
>>> must not yet be started.  To say that another way, no expression
>>> evaluation (including side effects) may be "moved across" a
>>> read or write to a _Volatile object.
>>>
>>> Note that foo() is a call to an ordinary function, and expressions
>>> in foo() may be re-ordered in all the usual ways, except that they
>>> must not be "moved across" the assignment to x or the assignment
>>> to y.
>>>
>>
>> That does sound like a simpler mechanism for the same effect.  But
>> perhaps we can go further and simpler:
>>
>>     x = 1;
>>     _Execution_barrier();
>>     foo();
>>     _Execution_barrier();
>>     y = 1;
>>
>> _Execution_barrier() would be an implementation-dependent macro that
>> imposes a sequence point in the actual machine, in the manner described
>> by Tim above.  I see no advantage to making it a qualifier or tying it
>> to a particular lvalue access, since it acts on the entire machine.
>
>
> I like this proposal better than Tim's _Volatile. It provides the same
> functionality as the "volatile function" proposal, and looks like it
> could be more straight-forward to implement. But I think (and I think
> you agree) that it should be limited to act on a single core (= the
> current thread) and should not affect other threads or other cores in
> the machine.

Yes. It can always be combined with an atomic fence (such as
atomic_thread_fence(..), from C11 or C++11 onwards) when you need it to
apply to multiple threads. On many systems, a full sequential
consistency atomic barrier is quite expensive to execute as it involves
buffer and cache synchronisation across all cores, so you don't want
that if you don't need it.

Niklas Holsti <niklas.holsti@tidorum.invalid> writes:
>Based on earlier discussions with
>Anton Ertl, Gforth does not generate C source. It has an internal set of
>small C functions or code blocks, compiled by the C compiler when Gforth
>is compiled, which implement each predefined Forth "word" (primitive
>Forth operation). To compile a user-defined Forth word (a subroutine),
>Gforth can either do as most simple interactive Forth systems do, which
>is to make a list of the machine addresses of the code blocks for the
>words that are used (called) in the subroutine, to be traversed by the
>Forth "interpreter", _or_ Gforth can copy and concatenate the machine
>code for those words, from the original code blocks for each word,
>generating at run-time a new and larger machine code block for the new
>word. This in-lines the machine code for each word and means that the
>word can be executed as one step in the "interpreter". (I don't think
>Gforth then optimizes the in-lined code in any way.)
>
>As I understand it, the gcc options listed above are partly intended to
>make this copy-and-concatenate process produce machine code that works
>as intended. It amazes me that it actually works on several architectures.
>
>(I hope Anton will correct the above if it is wrong.)

You got it mostly right. Minor corrections:

C source code is generated from a virtual machine description language
at Gforth build time. Also, C source code is generated for at Gforth
run-time for the foreign function interface; that's because only a C
compiler really knows how to call something that looks like a C
function.

The granularity of dynamic native code generation is finer-grained.
Basically, if Gforth compiles a relocatably primitive, it copies it to
the dynamically generated code, then the next, the next, etc. falling
through between them without a threaded-code dispatch; you only get
threaded-code dispatch if the next primitive is elsewhere, either
because of (Forth-level) control-flow or because the next primitive is
non-relocatable (then the dispatch jumps to its original location).

There are indeed no optimizations of the resulting code (apart from
the issue of whether to append the dispatch or not), but there are two
optimizations wrt. which pieces of code to copy:

* There are static superinstructions, code for a common sequence of
primitives (these sequences are fixed at Gforth build time, thus
"static" superinstructions), and the Gforth code generator copies the
code for the superinstruction instead of the constituent primitives if
that gives smaller code.

* There is also static stack caching: Instead of always having the
same stack representation at the boundary between primitives, there
are versions of the primitives with different representations (fewer
or more stack items in registers); there are also code fragments for
switching from one stack representation to a different one. Smaller
code can be generated by the resulting freedom of selecting other
versions of the primitives than the one that takes the canonical stack
state as input and produces the cononical stack state as output.

Gforth uses dynamic programming (when it compiles a Forth program) to
select the shortest code for the sequence of primitives for the
statically given superinstructions and stack-cache-variants of the
primitives.

As to why it works for several architectures: Because they are all the
same wrt. the invariants we require. However, we have disabled
dynamic native code generation for MIPS, where the architected load
delay slots do not satisfy these invariants (the way the jal
instruction works on MIPS (absolute address, but works only within a
256MB segment) would also be a hurdle).

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

Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
>
>> Thomas Koenig <tkoenig@netcologne.de> writes:
>
>[...]
>
>>> so your code is certainly very much non-conforming.
>>
>> In terms of the C standard, it's a conformant program.
>
>The ISO C standard does not use the term conformant either in
>connection with code or with programs. It does define the two
>terms 'strictly conforming program' and 'conforming program'.

Sorry, I meant a "conforming program".

>Unfortunately the C standard does not define a term that matches
>something close to what I think you mean, which is a program
>that compiles and is accepted by the vast majority of C
>implementations, including those without any language extensions.

In the present case, I mean a "conforming program" in the standard C
sense. Gforth uses several language extensions. There are dozens of
C compilers that compile Gforth (many "versions" of gcc and clang) and
it works on many architectures, but of course this does not matter for
the conformance levels of the C standard.

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