David Brown <david.brown@hesbynett.no> writes:
>On 26/10/2021 14:59, Stefan Monnier wrote:
>> Thomas Koenig [2021-10-26 10:41:27] wrote:
>>> Anton Ertl <anton@mips.complang.tuwien.ac.at> schrieb:
>>>> Currently Gforth's configure.ac checks whether the C compiler
>>>> understands the following flags (and uses all those that the C
>>>> compiler understands):
>>>>
>>>> -fno-gcse
>>>> -fcaller-saves
>>>> -fno-defer-pop
>>>> -fno-inline
>>>> -fwrapv
>>>> -fchar-unsigned
>>>> -fno-strict-aliasing
>>>> -fno-cse-follow-jumps
>>>> -fno-reorder-blocks
>>>> -fno-reorder-blocks-and-partition
>>>> -fno-toplevel-reorder
>>>> -fno-trigraphs
>>>> -falign-labels=1
>>>> -falign-loops=1
>>>> -falign-jumps=1
>>>> -fno-delete-null-pointer-checks
....
>I am not clear here whether these are flags used when compiling the
>Gforth transpiler tool, or whether they are flags used when compiling
>the output of Gforth.

It seems that you have the wrong impression of the workings of Gforth.
Gforth does not compile Forth source to C source; if we ignore the
foreign function interface, Gforth does not perform call a C compiler
when the user runs Gforth and compiles and runs a Forth program.

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

On 27/10/2021 12:52, Anton Ertl wrote:
> David Brown <david.brown@hesbynett.no> writes:
>> On 26/10/2021 14:59, Stefan Monnier wrote:
>>> Thomas Koenig [2021-10-26 10:41:27] wrote:
>>>> Anton Ertl <anton@mips.complang.tuwien.ac.at> schrieb:
>>>>> Currently Gforth's configure.ac checks whether the C compiler
>>>>> understands the following flags (and uses all those that the C
>>>>> compiler understands):
>>>>>
>>>>> -fno-gcse
>>>>> -fcaller-saves
>>>>> -fno-defer-pop
>>>>> -fno-inline
>>>>> -fwrapv
>>>>> -fchar-unsigned
>>>>> -fno-strict-aliasing
>>>>> -fno-cse-follow-jumps
>>>>> -fno-reorder-blocks
>>>>> -fno-reorder-blocks-and-partition
>>>>> -fno-toplevel-reorder
>>>>> -fno-trigraphs
>>>>> -falign-labels=1
>>>>> -falign-loops=1
>>>>> -falign-jumps=1
>>>>> -fno-delete-null-pointer-checks
> ...
>> I am not clear here whether these are flags used when compiling the
>> Gforth transpiler tool, or whether they are flags used when compiling
>> the output of Gforth.
>
> It seems that you have the wrong impression of the workings of Gforth.
> Gforth does not compile Forth source to C source; if we ignore the
> foreign function interface, Gforth does not perform call a C compiler
> when the user runs Gforth and compiles and runs a Forth program.
>

Thanks for the clarification.

That is how I originally thought it worked, but I got a little mixed
from some of the recent posts. Code with lots of gotos and labels is
common in generated C code but rare in human-written code, so the
example shown added to my confusion.

Ivan Godard wrote:
> On 10/24/2021 2:41 PM, John Levine wrote:
>> When I was an undergraduate I was thrilled to be able to use a Wang
>> calculator
>> with Nixie tube display in the department library for some of my
>> chemistry
>> homework.  But I still have a slide rule in my backpack.  You never know.

I don't keep it in my backpack, but I did save my best slide rule when
we moved earlier this year.
>
> Ah, Wang Labs. We did a Fortran compiler for them. An Wang was the only
> person I know of who personally invented three billion dollar industries
> - calculators, core memory, and word processing - and back when a
> billion was a real number.

Sam Eyde basically started most of the industrialization of Norway, i.e.
both Hydro and Elkem, along with the hydroelectric power plants he
needed to run them. When he was finally forced out of Hydro in 1917 they
had to give him a _very_ golden parachute of 250K NOK/year, at a point
when that was worth well over a million dollars in today's money.

>
> The family was a tragic confirmation of the adage of "slum to palace to
> slum in four generations".

We tend to have less of those here, probably related to the fact that we
also have very few lottery jackpot winners who go overboard:

Typical reaction is "Get rid of all debts, buy a car for my parents, put
the rest in the bank/index funds. Go back to work on Monday"

Terje

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

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

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

In that case I think it's better if you say something like that
rather than just saying it's a conforming program. People who are
not familiar with how the C standard defines this term will very
probably have a wrong impression of what you mean, and people who
/are/ familiar with how the term is defined might easily think you
mean something much weaker than what is the case. For example, you
might say "It's a conforming program, but more importantly it is
written in standard (if not absolutely portable) C, plus a few
language extensions supported by both gcc and clang [and some of
the others, if there are others]." That tells your readers a lot
more than just saying it's a conforming program.

> but of course this does not matter for the conformance levels
> of the C standard.

I think it's misleading to characterize the terms "conforming
program" and "strictly conforming program" as conformance
levels. The ISO C standard defines these terms for its own
purposes, not as metrics for general C programs to be measured
against. Most C programs fall more in the middle of these two
extremes (not counting the "C" programs that fall outside the
range by virtue of being compilable only by compilers invoked
in a non-conforming mode).

> Gforth uses several language extensions.

Do you mean language extensions, or compiler options? Out of
curiosity, do you mind if I ask what options or what extensions
those are?

On Tuesday, October 26, 2021 at 10:58:24 PM UTC-5, Tim Rentsch wrote:
> MitchAlsup <Mitch...@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.
<
So the billion uses of 'cat' every day performs nothing of value to the users
invoking 'cat' ?

On Wednesday, October 27, 2021 at 4:09:17 AM UTC-5, Anton Ertl wrote:
> EricP <ThatWould...@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.
<
While the 'bits' are correct, the exceptions are different::
signed × can overflow if there ends up significant bits > 2^n
>
> - anton
> --
> 'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
> Mitch Alsup, <c17fcd89-f024-40e7...@googlegroups.com>

On 10/26/2021 11:38 PM, 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.
>
> 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.

I think there are two separable questions here. One is what the
mechanism does. The second is whether the mechanism should be a
property of the function or of the invocation of that function. Or
equivalently, should the syntax (whatever it is) be required for each
call, or should it be invoked automatically (without additional syntax)
every time the function is invoked.

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

On Wednesday, October 27, 2021 at 11:32:02 AM UTC-5, Stephen Fuld wrote:
> On 10/26/2021 11:38 PM, David Brown wrote:
> > On 27/10/2021 03:28, Tim Rentsch wrote:
> >> Niklas Holsti <niklas...@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.
<
> I think there are two separable questions here. One is what the
> mechanism does. The second is whether the mechanism should be a
> property of the function or of the invocation of that function. Or
> equivalently, should the syntax (whatever it is) be required for each
> call, or should it be invoked automatically (without additional syntax)
> every time the function is invoked.
<
None of this would be necessary if foo() was simply compiled separately
all the way down to code so the compiler could not have any knowledge
of what it does or does not do.
> --
> - Stephen Fuld
> (e-mail address disguised to prevent spam)

On 2021-10-27 19:48, MitchAlsup wrote:
> On Wednesday, October 27, 2021 at 11:32:02 AM UTC-5, Stephen Fuld wrote:
>> On 10/26/2021 11:38 PM, David Brown wrote:
>>> On 27/10/2021 03:28, Tim Rentsch wrote:
>>>> Niklas Holsti <niklas...@tidorum.invalid> writes:
>>>>
>>>>>> [.. volatile ..]

[ snip ]

>>> 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.
> <
>> I think there are two separable questions here. One is what the
>> mechanism does. The second is whether the mechanism should be a
>> property of the function or of the invocation of that function. Or
>> equivalently, should the syntax (whatever it is) be required for each
>> call, or should it be invoked automatically (without additional syntax)
>> every time the function is invoked.
> <
> None of this would be necessary if foo() was simply compiled separately
> all the way down to code so the compiler could not have any knowledge
> of what it does or does not do.

Except if link-time optimization is used. And the _Execution_barrier
mechanism could be used for any code, not just for function calls.

Anton Ertl wrote:
> 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

Yes, thanks.
In a new ISA, a MULL Multiply Low instruction would be used for
modulo types and the low part of trap and sat types.

A MULHS and MULHU Multiply High Signed/Unsigned instruction produces
the high result part which trap and sat types then check for overflow.

For unsigned trap and sat multiply Trap Conditional and Move Conditional
instructions handle the overflow checks for non-zero high part.
Each checked unsigned multiply would be MULL MULHU TRAPNZ instructions
so is worthwhile integrating into a single instruction MULTU.

For signed trap and sat multiply it needs to check that the high part is
the signed extension of the low part. A SHRA Shift Right Arithmetic fills
a register with the sign bit, a CMP, and either Trap or Move Conditional.

Since, in this alternate universe, most signed integers would use checked
arithmetic, that 5 instruction sequence MULL MULHS SHRA CMPEQ TRAPEZ
would occur for almost every multiply, it is worthwhile to integrate
into a single instruction MULTS Multiply Trap Signed Overflow.
Similar for saturate MULSS Multiply Saturate Signed.

So new ISA multiply instructions are

MULL Multiply Low
MULHU MULHS Multiply High Unsigned/Signed
MULTU MULTS Multiply Trap Unsigned/Signed Overflow
MULSU MULSS Multiply Saturate Unsigned/Signed

Quadibloc <jsavard@ecn.ab.ca> schrieb:
> 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.

You can always do that (and it is what I have done on occasion,
while sending heartfelt curses in the dirction of whoever wrote
that formula).

Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
>
>> 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 [conforming] program.
....
>> 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,
>
>In that case I think it's better if you say something like that
>rather than just saying it's a conforming program.

Normally I don't say anything about that. But since Thomas Koenig
claimed that using a C extension makes it "very much non-conforming",
I wanted to point out to him that it is a conforming program.

>> but of course this does not matter for the conformance levels
>> of the C standard.
>
>I think it's misleading to characterize the terms "conforming
>program" and "strictly conforming program" as conformance
>levels. The ISO C standard defines these terms for its own
>purposes, not as metrics for general C programs to be measured
>against.

What are these purposes? It seems to me that these two definitions
(and there are no others for programs) are a reflection on the
incompleteness of the C standard (nothing wrong with this
incompleteness, but one should be aware of it).

>> Gforth uses several language extensions.
>
>Do you mean language extensions, or compiler options? Out of
>curiosity, do you mind if I ask what options or what extensions
>those are?

Extensions: labels-as-values, extended asm (including portable use of
extended asm:-) and POSIX calls are the most obvious ones because
compilers can easily recognize them. Probably lots and lots of usages
that are undefined behaviour in the standard or somesuch.

Options: see <2021Oct25.195829@mips.complang.tuwien.ac.at>

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

Bakul Shah <bakul@iitbombay.org> schrieb:
> 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.

Which is no problem, as long as you stick to the dimensions
of SI units.

There are actually two versions of the program. In the older
one, which I still use, units are just variables, so you
can write

fortnight := 14 days

and it will just work (days is predefined). The newer version,
which I don't use because it is source code incompatible and has
a poorly- working conversion program, units are a bit special so
you are in no danger of redefining the liter if you use L for a
measurement, but you can still define your own units.

And if you have a time as a result, you can plug it into the
display, so the output will be either

time = 1000000 s

where the program supplies the unit, or

time = 0.826 fortnight

if you plug in the unit yourself.

> I think
> you'd also need the concept of exactness as in Scheme if you
> allow conversions between metric and imperial systems.

I don't know what that concept is. Could you elaborate?

For engineering calculations, double precision in something
that could actually be measured is plenty enough.

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

Or Excel tables.

You're given throughput in kg/hour and a density in kg/m^3, please
calculate the volumentric throughput in m^3/s.

(In a seminar I give, I actually let people calculate the above as
part of an excercise. It is astonishing how long people, most of
whome have university degrees in engineering or natural science
work on on their pocket calculators or mobile phones before they
have the result, if that is even correct).

Stephen Fuld <sfuld@alumni.cmu.edu.invalid> schrieb:
> 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)

That is accepted, because both are Length^2.

Stefan Monnier <monnier@iro.umontreal.ca> schrieb:
>> In general, I am in favor of languages which lets me do things I
>> cannot do in other languages. I am less a fan of languages which
>> try to educate me what to use and not to use.
>
> Every time a language allows X, it inevitably prevents you from
> doing the things which depend on X never happening.

Well, yes, true... so a PGAS language will prevent me from doing
things which depend on my program being serial and not being
able to access other images :-)

David Brown <david.brown@hesbynett.no> writes:
>That is how I originally thought it worked, but I got a little mixed
>from some of the recent posts. Code with lots of gotos and labels is
>common in generated C code but rare in human-written code, so the
>example shown added to my confusion.

The code shown was written by a human.

The Gforth build process uses a generator (a variant of vmgen) with
input like the following:

+ ( n1 n2 -- n ) core plus
n = n1+n2;

The output looks as follows:

LABEL(plus) /* + ( n1 n2 -- n ) S1 -- S1 */
/* */
NAME("+")
{ DEF_CA
MAYBE_UNUSED Cell n1;
MAYBE_UNUSED Cell n2;
Cell n;
NEXT_P0;
vm_Cell2n(sp[1],n1);
vm_Cell2n(spTOS,n2);
#ifdef VM_DEBUG
if (vm_debug) {
fputs(" n1=", vm_out); printarg_n(n1);
fputs(" n2=", vm_out); printarg_n(n2);
} #endif
sp += 1;
{ #line 697 "prim"
n = n1+n2;
#line 3208 "prim-fast.i"
}

#ifdef VM_DEBUG
if (vm_debug) {
fputs(" -- ", vm_out); fputs(" n=", vm_out); printarg_n(n);
fputc('\n', vm_out);
} #endif
NEXT_P1;
vm_n2Cell(n,spTOS);
LABEL2(plus)
NAME1("l2-plus")
NEXT_P1_5;
LABEL3(plus)
NAME1("l3-plus")
DO_GOTO;
}

The code generated by gcc for this is:

55C9C8F573A6: add r13,$08
55C9C8F573AA: add r15,$08
55C9C8F573AE: add r8,$00[r13]
55C9C8F573B2: mov rcx,-$08[r15]
55C9C8F573B6: jmp rcx

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

MitchAlsup <MitchAlsup@aol.com> schrieb:
> On 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.

Certainly - and, as we know since Buckingham proved his theorem,
all of these can be expressed using dimensionless numbers.

Niklas Holsti <niklas.holsti@tidorum.invalid> schrieb:
> 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,

I find this quite admirable, but metric and Imperial (what is a
gallon again? :-) is only part of the problem.

Ever since I saw a volume conversion plant in the operator's room in
a chemical plant (and if your tank volumes are given in cubic feet,
with your flows given in gallons per minute, you need that table,
or you need MathCad, which I usually have open when talking to
US colleagues), and since I saw a formula for the Reynolds number
on the Web given as

Re = u * D * rho / (correction_factor * mu)

I have been utterly convinced that the Imperial system is sheer
madness, and that the US should reject this system that has been
imposed of them by their colonialist oppressors.

However, I digress.

There are also inconsitent units in everyday use - seconds and
hours, Liters and cubic meters, and so on.

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

So anybody who puts in kg/h and kg/m^3 and wants m^3/s to calculate
that dimensionless number has to do the conversion by hand.

Hm, I'm not sure I would find that feature to be useful enough.

David Brown <david.brown@hesbynett.no> writes:
>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.

Jon Bentley wrote "Writing Efficient Programs" in 1982, and he gave an
example in Pascal. I transliterated them to C IIRC in 1999 and you
can find the results at
<http://www.complang.tuwien.ac.at/anton/lvas/effizienz/tsp.html>.

Last I looked, the manual optimization steps that Jon Bentley
described in 1982 still produced a speedup factor of >2.7, while the
difference between disabling (with "-fno-aggressive-loop-optimizations
-fno-unsafe-loop-optimizations -fno-delete-null-pointer-checks
-fno-strict-aliasing -fno-strict-overflow
-fno-isolate-erroneous-paths-dereference-fwrapv" in gcc-5.2.0) and
leaving enabled the undefined-behaviour you cherish is a factor of 1
for the majority of programs, and a factor 0.95-1.04 for the rest.
Interestingly, the differences exist more for the more optimized
programs. Read all about it in Section 4.2 of
<https://www.complang.tuwien.ac.at/kps2015/proceedings/KPS_2015_submission_29.pdf>.

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

I put up the challenge before <2017Aug18.152854@mips.complang.tuwien.ac.at>

|Write a proof-of-concept Forth interpreter in the language you
|advocate that runs at least one of bubble-sort, matrix-mult or sieve
|from bench/forth in
|<http://www.complang.tuwien.ac.at/forth/bench.zip>

We can then check whether the language you advocate can compete with a
low-level language by benchmarking your interpreter against Gforth.

>But to me, that's just a small step from
>programming in assembly,

That's the point.

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

On Wednesday, October 27, 2021 at 12:04:50 PM UTC-5, Niklas Holsti wrote:
> On 2021-10-27 19:48, MitchAlsup wrote:
> > On Wednesday, October 27, 2021 at 11:32:02 AM UTC-5, Stephen Fuld wrote:
> >> On 10/26/2021 11:38 PM, David Brown wrote:
> >>> On 27/10/2021 03:28, Tim Rentsch wrote:
> >>>> Niklas Holsti <niklas...@tidorum.invalid> writes:
> >>>>
> >>>>>> [.. volatile ..]
> [ snip ]
> >>> 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.
> > <
> >> I think there are two separable questions here. One is what the
> >> mechanism does. The second is whether the mechanism should be a
> >> property of the function or of the invocation of that function. Or
> >> equivalently, should the syntax (whatever it is) be required for each
> >> call, or should it be invoked automatically (without additional syntax)
> >> every time the function is invoked.
> > <
> > None of this would be necessary if foo() was simply compiled separately
> > all the way down to code so the compiler could not have any knowledge
> > of what it does or does not do.
<
> Except if link-time optimization is used. And the _Execution_barrier
> mechanism could be used for any code, not just for function calls.
<
You can prevent link-time optimization by erasing the information
about the function excepting the entry point names. {In any event,
there does need to be some way of preventing link-time optimization.}

On Wednesday, October 27, 2021 at 12:08:59 PM UTC-5, EricP wrote:
> Anton Ertl wrote:
> > EricP <ThatWould...@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
> Yes, thanks.
> In a new ISA, a MULL Multiply Low instruction would be used for
> modulo types and the low part of trap and sat types.
>
> A MULHS and MULHU Multiply High Signed/Unsigned instruction produces
> the high result part which trap and sat types then check for overflow.
>
> For unsigned trap and sat multiply Trap Conditional and Move Conditional
> instructions handle the overflow checks for non-zero high part.
> Each checked unsigned multiply would be MULL MULHU TRAPNZ instructions
> so is worthwhile integrating into a single instruction MULTU.
>
> For signed trap and sat multiply it needs to check that the high part is
> the signed extension of the low part. A SHRA Shift Right Arithmetic fills
> a register with the sign bit, a CMP, and either Trap or Move Conditional.
>
> Since, in this alternate universe, most signed integers would use checked
> arithmetic, that 5 instruction sequence MULL MULHS SHRA CMPEQ TRAPEZ
> would occur for almost every multiply, it is worthwhile to integrate
> into a single instruction MULTS Multiply Trap Signed Overflow.
> Similar for saturate MULSS Multiply Saturate Signed.
>
> So new ISA multiply instructions are
>
> MULL Multiply Low
> MULHU MULHS Multiply High Unsigned/Signed
> MULTU MULTS Multiply Trap Unsigned/Signed Overflow
> MULSU MULSS Multiply Saturate Unsigned/Signed
<
When I faced this in a new ISA that, in general, sought to provide signed integer
overflow exceptions, I left a bit in the instruction OpCode so that if significance
showed up that could not be contained in the container of delivery, that OVEFLOW
exception would be raised.
<
Multiply 64×64->128 is
CARRY Rhigh,{(1)}
MUL Rlow,Rx,Ry
And {Rhigh,Rlow} contains the signed or unsigned 128-bit product.
No pairing, no even, odd, Rhigh is not related in any way to Rlow.

On Wednesday, October 27, 2021 at 12:40:05 PM UTC-5, Thomas Koenig wrote:
> MitchAlsup <Mitch...@aol.com> schrieb:
> > 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.
>
> Certainly - and, as we know since Buckingham proved his theorem,
> all of these can be expressed using dimensionless numbers.
<
Not complaining about the dimensionlessness, was complaining about
the original equation not considering what the air was flowing into.

Anton Ertl <anton@mips.complang.tuwien.ac.at> schrieb:
> David Brown <david.brown@hesbynett.no> writes:
>>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.
>
> Jon Bentley wrote "Writing Efficient Programs" in 1982, and he gave an
> example in Pascal. I transliterated them to C IIRC in 1999 and you
> can find the results at
><http://www.complang.tuwien.ac.at/anton/lvas/effizienz/tsp.html>.
>
> Last I looked, the manual optimization steps that Jon Bentley
> described in 1982 still produced a speedup factor of >2.7,

So, which of these are actually permitted according to the C
semantics?

Thomas Koenig <tkoenig@netcologne.de> wrote:
> Bakul Shah <bakul@iitbombay.org> schrieb:
>> 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.
>
> Which is no problem, as long as you stick to the dimensions
> of SI units.
>
> There are actually two versions of the program. In the older
> one, which I still use, units are just variables, so you
> can write
>
> fortnight := 14 days
>
> and it will just work (days is predefined). The newer version,
> which I don't use because it is source code incompatible and has
> a poorly- working conversion program, units are a bit special so
> you are in no danger of redefining the liter if you use L for a
> measurement, but you can still define your own units.
>
> And if you have a time as a result, you can plug it into the
> display, so the output will be either
>
> time = 1000000 s
>
> where the program supplies the unit, or
>
> time = 0.826 fortnight
>
> if you plug in the unit yourself.
>
>> I think
>> you'd also need the concept of exactness as in Scheme if you
>> allow conversions between metric and imperial systems.
>
> I don't know what that concept is. Could you elaborate?

You can’t represent many values exactly in floating point. So for example
in Scheme:

(exact? 1.3) => #f
(exact? 13/10) => #t
(exact->inexact 1/7) => .14285714285714285

Repeated conversions with inexact numbers can lose precision.
Most apps may not care. I suspect financial apps care enough
to at least use decimal arithmetic!

> For engineering calculations, double precision in something
> that could actually be measured is plenty enough.
>
>> Incidentally, some accounting packages already have to do this
>> -- a conversion factor, such as exchange rate or share price
>> may even be time dependent!
>
> Or Excel tables.
>
> You're given throughput in kg/hour and a density in kg/m^3, please
> calculate the volumentric throughput in m^3/s.
>
> (In a seminar I give, I actually let people calculate the above as
> part of an excercise. It is astonishing how long people, most of
> whome have university degrees in engineering or natural science
> work on on their pocket calculators or mobile phones before they
> have the result, if that is even correct).

While growing up we had no calculators so I learned to do mental math.
I think even today Indian students are not allowed to use calculators,
at least until the end of high school. A useful skill because you can play
with numbers and get a feeling for how to solve such problems.

On 10/26/2021 3:50 AM, Thomas Koenig wrote:
> Anton Ertl <anton@mips.complang.tuwien.ac.at> schrieb:
>> Terje Mathisen <terje.mathisen@tmsw.no> writes:
>>> Anton Ertl wrote:
>>>> Quadibloc <jsavard@ecn.ab.ca> writes:
>>>>> That isn't a solution. If the problem is to satisfy both sides,
>>>>> killing the branch of the language that satisfies one of them
>>>>> constitutes failure; one side is not satisfied.
>>>>>
>>>>> However, reality is more complex than that. The reality is
>>>>> that C99 and gcc are viewed by the dissatisfied side as
>>>>> just that "solution" as having happened already...
>>>>
>>>> Actually, it seems to me that C++ is the solution for the nasal demon
>>>> worshippers. And once C compilers started to be written by C++
>>>> programmers, they applied the C++ view of how to deal with undefined
>>>> behaviour also to C.
>>>
>>> So why aren't more people switching to Rust?
>>
>> More generally, why aren't people switching to other programming
>> languages? Because they have a legacy of C code.
>
> Or because they like the language, or do not feel like being
> constrained, or the language is not available on their
> favorite platform, or...
>
> In general, I am in favor of languages which lets me do things I
> cannot do in other languages.

So you prefer assembler over C, as the you can write instruction
sequences or even instructions that the compiler would never generate?

> I am less a fan of languages whi
> try to educate me what to use and not to use.

A language is a tool to get some job done. If the language puts
constraints on what I write in order to help me get the job done more
quickly or with fewer errors, then I like it, even if it disallows some
things. Better yet is a language that allows me to do potentially
"dangerous" things, but makes me explicitly write something that says
essentially "I know this would violate the typical rules, but I know
what I am doing so please allow it". This tells other programmers, or
even future me, that something "tricky" is going on and be extra careful
when you want to change it. But this should be pretty rare.

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