On 3/5/2022 8:31 PM, MitchAlsup wrote:
> On Saturday, March 5, 2022 at 8:15:37 PM UTC-6, BGB wrote:
>> On 3/5/2022 2:38 PM, MitchAlsup wrote:
>
>> It doesn't really destroy stereo effects, if anything it is more like
>> the use of chroma subsampling in JPEGs and similar. An image can still
>> be colorful and detailed, even despite all the color information being
>> encoded at a lower resolution when compared with brightness.
>>
> No amount of processing on a *.jpg can give as good an image as
> the 14-bits coming out of the camera. Good enough for way more
> than most: certainly. Good enough for the picky: not even close.

Though, production use, archival use, or dedicated listening, isn't what
I was going for here.

You could probably also switch nearly all of the audio in YouTube videos
from 44.1 to 16 kHz and probably very few people would notice. You could
also switch the graphics on many websites over to 50% or 65% quality
JPEG's and also, relatively few would notice.

Well, also Twitter has the property that nearly any image one uploads
tends to get auto-recompressed into a (typically) lower-quality JPEG
version, and also downscaled if the resolution is unreasonably large.
Sometimes this recompression actually makes the image bigger though (eg:
PNGs of synthetic images will tend to be pretty small, and
auto-conversion to JPEG will not help; apparently Twitter more recently
added a "don't use the JPEG if the JPEG makes it bigger" check).

Can the quality difference be seen and heard? Yes.
Is it particularly obvious? Not necessarily.

It is also probable that if (standard, or even de-facto) JPEG variants
supported an alpha channel, then it would have been used more often than
it is already (many contexts where people use PNG mostly because it
supports an alpha channel, rather than because lossless compression is
needed).

Well, and, typically, a low-sample-rate ADPCM wouldn't be used for
dedicated listening or similar.

For sound effects or similar, it works well. They are usually distorted
and attenuated during the mixing process, so people don't usually listen
all that closely.

Likewise, for ambient and background music, it is usually playing in the
background while other stuff is going on. Rarely are people all that
likely to stop and listen all that intently to it. It is more there to
set a mood or theme or similar.

Sometimes, it might also be used for things like artificial background
noise or similar (where one might want, say, a good 20 or 30 seconds or
more of audio to avoid it being too obvious that it is looping).

Many of the games back in the 90s also got along fine with 8 and 11 kHz
audio (typically 8-bit PCM).

In my foray into MOD and S3M files, I had also noted:
8kHz for "Middle C" is more or less a hard-coded assumption in MOD;
8kHz and 11kHz are still pretty common in S3M files;
...

....

On 3/5/2022 10:02 PM, Andy Valencia wrote:
>> MitchAlsup <MitchAlsup@aol.com> writes:
>>> My home system presents the full sound stage 10-120Hz if from the
>>> DD15 sub-woofer, 120-22KHz is from the Martin Logan CLS full range
>>> electrostatics.
>
> A friend sold me his Martin Logal SL3's at a shocking discount. A speaker
> I would never have justified buying at a retail price, but--wow. A real
> treat, and a much higher end audio setup than I ever expected to own.
> I upgraded to a Krell amplifier, which I guess made the speakers
> in effect a little more expensive!
>

I guess it does bring up a question of whether a dedicated stereo system
(with an amplifier and speakers), would make the relative differences in
audio quality more or less noticeable than with a "gamer headset" (eg,
headphones with an integrated microphone), running off the Realtek audio
chipset or similar integrated into ones' motherboard.

I would except that big speakers (say, the traditional "big wooden box"
speakers with 12-16 inch speaker cones behind a mesh or grate front
panel mounted inside a plywood box or similar), due to their size and
mechanical inertia, would effectively work as a low-pass filter for
audio playback.

Well, also one can note that seemingly some speaker setups are fine with
14 AWG wire or similar (and ye olde screw terminals or similar), and for
other speakers people go with 6 AWG or similar (with big lugs and bolts
for attaching the wires).

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

MitchAlsup <MitchAlsup@aol.com> schrieb:

> While LDM and STM are "in" ISA, I don't see them in use,

They can be quite useful for saving and restoring caller-saved
registers.

They can also be useful for bundling more than one store / load, but
the register allocation would have be be altered for that, starting
off with the LDM/STM. While this is theoretically faeasible,
I suspect the effort would be high and the resulting gain in efficiency
rather low.

The restriction on the VEC registers is far more severe, but AFAIK
you are already in contact with Brian about this. I suspect having
the vector mask as a 32-bit immediate would be better.

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

> Ivan Godard <ivan@millcomputing.com> writes:
>
>> Declarable (!) precedence was a disaster
>> in A68 - what's the precedence of left circular shift?

(For the record, I agree that declarable precedence is a bad
idea.)

> IMO the general concept of precedence is a disaster. You can
> do implicit parenthesizing between well-established pairs of
> operators (e.g., a+b*c, but not "a or b and c"), or in a few
> cases it's intuitive (a<b+c, a<b and c), but that does not
> establish a transitive relation (don't accept a+b and c).
>
> My take would be to always require parenthesis when dealing
> with a pair of operators that are not among the few exceptions
> for which a binding relation is defined (when in doubt, don't
> add an exception, e.g., for the pair of "and" and "or").

In my view this conclusion is exactly backwards. Taking C as a
canonical example, given that C does have precisely defined
precedence rules, it would be better if any redundant parentheses
were disallowed and flagged as errors by the compiler. In a very
short time there would be no confusion about what various
combinations of operators meant, and no worry about developers
misunderstanding them.

It still can be useful to indicate an /expected/ precedence, but
that should be done in a way that does not /force/ a particular
precedence. An easy way to do this is with horizontal white
space, as for example

a = b + c*d;

or

if( this || that && that_other ) ...

Moreover if the white space convention were used it could be
checked unambiguously by the compiler. If a program has

a = b+c * d;

there is no question that the program's author is confused about
/something/, and it would be nice if compilers would flag that.

On 2022-03-06 16:31, Tim Rentsch wrote:
> anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
>
>> Ivan Godard <ivan@millcomputing.com> writes:
>>
>>> Declarable (!) precedence was a disaster
>>> in A68 - what's the precedence of left circular shift?
>
> (For the record, I agree that declarable precedence is a bad
> idea.)
>
>> IMO the general concept of precedence is a disaster. You can
>> do implicit parenthesizing between well-established pairs of
>> operators (e.g., a+b*c, but not "a or b and c"), or in a few
>> cases it's intuitive (a<b+c, a<b and c), but that does not
>> establish a transitive relation (don't accept a+b and c).
>>
>> My take would be to always require parenthesis when dealing
>> with a pair of operators that are not among the few exceptions
>> for which a binding relation is defined (when in doubt, don't
>> add an exception, e.g., for the pair of "and" and "or").
>
> In my view this conclusion is exactly backwards. Taking C as a
> canonical example, given that C does have precisely defined
> precedence rules, it would be better if any redundant parentheses
> were disallowed and flagged as errors by the compiler. In a very
> short time there would be no confusion about what various
> combinations of operators meant, and no worry about developers
> misunderstanding them.

I don't believe that for a second! Many programmers switch between
languages, more or less frequently, and different languages have
different operator symbols and sometimes different precedence systems.
People forget fiddly things like precedences, especially when they are
sure that they remember...

Anton Ertl wrote:
> EricP <ThatWouldBeTelling@thevillage.com> writes:
>>
>> and it would still need some kind of microcode sequencer for
>> when there was more than 8 save/restore registers in a set.
>
> It would be interesting to microbenchmark ldm/stm on a high-end
> implementation of ARM A32/T32. My guess is that it does not perform
> better than a sequence of ldp/stp, maybe worse.
>
> For the current implementation technology (with separate I-cache) and
> renamed registers with register port limits, the architects designed
> ldp/stp.
>
> In 1983, with no caches, and instructions competing with data for RAM
> access, LDM/STM worked nicely, not just for function
> prologue/epilogue, but also for copying and initializing large memory
> blocks.

The original ARM1 and later commercial ARMv3 aka ARM6 didn't use microcode
for LDM/STM. The register save/restore set was specified by a 16-bit mask
and the control sequencer selects the registers with a priority encoder.

You can see in the attached micrograph of the ARM1 the priority encoder,
which is only present to support LDM/STM, at the top of the picture takes
as much chip area as the whole rest of the decoder.

http://www.righto.com/2016/02/reverse-engineering-arm1-instruction.html

On ARM1 LDM/STM were by far the most HW expensive instructions and
(just guessing) probably remained so even after they added
MUL instructions which likely used Booth's shift-add.

Tim Rentsch <tr.17687@z991.linuxsc.com> schrieb:
> Taking C as a
> canonical example, given that C does have precisely defined
> precedence rules, it would be better if any redundant parentheses
> were disallowed and flagged as errors by the compiler.

I actually took this serious for a minute :-)

> In a very
> short time there would be no confusion about what various
> combinations of operators meant, and no worry about developers
> misunderstanding them.

On the off-chance that you were serious: Just publish branch of gcc
or clang with these modification, and see what happens. Hint: You
will fail boostrap :-)

On Sunday, March 6, 2022 at 4:21:11 AM UTC-6, Thomas Koenig wrote:
> MitchAlsup <Mitch...@aol.com> schrieb:
> > While LDM and STM are "in" ISA, I don't see them in use,
> They can be quite useful for saving and restoring caller-saved
> registers.
<
I have ENTER and EXIT (which are extensions of STM and LDM).
My 66000 ASM code is replete with these. ENTER and EXIT use
an implied SP as the target area of memory, and will automatically
push <specified> preserved arguments, update FP, and allocate
new local data on SP. EXIT does the reverse, but reads R0 first
so it can prefetch code at return point lessening latency.
>
> They can also be useful for bundling more than one store / load, but
> the register allocation would have be be altered for that, starting
> off with the LDM/STM. While this is theoretically faeasible,
> I suspect the effort would be high and the resulting gain in efficiency
> rather low.
<
Effort is high--and not straight forward.
>
> The restriction on the VEC registers is far more severe, but AFAIK
> you are already in contact with Brian about this. I suspect having
> the vector mask as a 32-bit immediate would be better.
<
We are working on that.

On Sunday, March 6, 2022 at 8:31:58 AM UTC-6, Tim Rentsch wrote:
> an...@mips.complang.tuwien.ac.at (Anton Ertl) writes:
>
> > Ivan Godard <iv...@millcomputing.com> writes:
> >
> >> Declarable (!) precedence was a disaster
> >> in A68 - what's the precedence of left circular shift?
>
> (For the record, I agree that declarable precedence is a bad
> idea.)
>
> > IMO the general concept of precedence is a disaster. You can
> > do implicit parenthesizing between well-established pairs of
> > operators (e.g., a+b*c, but not "a or b and c"), or in a few
> > cases it's intuitive (a<b+c, a<b and c), but that does not
> > establish a transitive relation (don't accept a+b and c).
> >
> > My take would be to always require parenthesis when dealing
> > with a pair of operators that are not among the few exceptions
> > for which a binding relation is defined (when in doubt, don't
> > add an exception, e.g., for the pair of "and" and "or").
>
> In my view this conclusion is exactly backwards. Taking C as a
> canonical example, given that C does have precisely defined
> precedence rules, it would be better if any redundant parentheses
> were disallowed and flagged as errors by the compiler. In a very
<
How can you possibly do this in the presence of # defines ?
These things almost invariably HAVE to use excess parenthesisization.
<
> short time there would be no confusion about what various
> combinations of operators meant, and no worry about developers
> misunderstanding them.
>
> It still can be useful to indicate an /expected/ precedence, but
> that should be done in a way that does not /force/ a particular
> precedence. An easy way to do this is with horizontal white
> space, as for example
>
> a = b + c*d;
>
> or
>
> if( this || that && that_other ) ...
>
> Moreover if the white space convention were used it could be
> checked unambiguously by the compiler. If a program has
>
> a = b+c * d;
>
> there is no question that the program's author is confused about
> /something/, and it would be nice if compilers would flag that.

MitchAlsup <MitchAlsup@aol.com> writes:

> On Sunday, March 6, 2022 at 8:31:58 AM UTC-6, Tim Rentsch wrote:
>
>> an...@mips.complang.tuwien.ac.at (Anton Ertl) writes:
>>
>>> Ivan Godard <iv...@millcomputing.com> writes:
>>>
>>>> Declarable (!) precedence was a disaster
>>>> in A68 - what's the precedence of left circular shift?
>>
>> (For the record, I agree that declarable precedence is a bad
>> idea.)
>>
>>> IMO the general concept of precedence is a disaster. You can
>>> do implicit parenthesizing between well-established pairs of
>>> operators (e.g., a+b*c, but not "a or b and c"), or in a few
>>> cases it's intuitive (a<b+c, a<b and c), but that does not
>>> establish a transitive relation (don't accept a+b and c).
>>>
>>> My take would be to always require parenthesis when dealing
>>> with a pair of operators that are not among the few exceptions
>>> for which a binding relation is defined (when in doubt, don't
>>> add an exception, e.g., for the pair of "and" and "or").
>>
>> In my view this conclusion is exactly backwards. Taking C as a
>> canonical example, given that C does have precisely defined
>> precedence rules, it would be better if any redundant parentheses
>> were disallowed and flagged as errors by the compiler. In a very
>
> How can you possibly do this in the presence of # defines ?
> These things almost invariably HAVE to use excess parenthesisization.

One way would be for the compiler to mark parentheses that are part
of macro definitions with an internal bit that would exempt them
from the "no redundant parentheses" rule. Of course doing that
would mean macro definitions would be free to use parentheses
wherever and however they wanted, but I don't see that as a big
problem - any program that has more than, say, 10% of its source
in macro definitions has bigger problems than precedence and where
parentheses are allowed.

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

> On 2022-03-06 16:31, Tim Rentsch wrote:
>
>> anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
>>
>>> Ivan Godard <ivan@millcomputing.com> writes:
>>>
>>>> Declarable (!) precedence was a disaster
>>>> in A68 - what's the precedence of left circular shift?
>>
>> (For the record, I agree that declarable precedence is a bad
>> idea.)
>>
>>> IMO the general concept of precedence is a disaster. You can
>>> do implicit parenthesizing between well-established pairs of
>>> operators (e.g., a+b*c, but not "a or b and c"), or in a few
>>> cases it's intuitive (a<b+c, a<b and c), but that does not
>>> establish a transitive relation (don't accept a+b and c).
>>>
>>> My take would be to always require parenthesis when dealing
>>> with a pair of operators that are not among the few exceptions
>>> for which a binding relation is defined (when in doubt, don't
>>> add an exception, e.g., for the pair of "and" and "or").
>>
>> In my view this conclusion is exactly backwards. Taking C as a
>> canonical example, given that C does have precisely defined
>> precedence rules, it would be better if any redundant parentheses
>> were disallowed and flagged as errors by the compiler. In a very
>> short time there would be no confusion about what various
>> combinations of operators meant, and no worry about developers
>> misunderstanding them.
>
> I don't believe that for a second! Many programmers switch between
> languages, more or less frequently, and different languages have
> different operator symbols and sometimes different precedence
> systems. People forget fiddly things like precedences, especially when
> they are sure that they remember...

That's why it's important to include the second part of my
proposal, where expected precedence relationships can be
indicated with whitespace, and have those be checked during
compilation. Doing that will also reinforce the learning
process, because reading code supplies an ongoing stream of
information about what the precedence relationships are in each
of the various languages.

Thomas Koenig <tkoenig@netcologne.de> writes:

> Tim Rentsch <tr.17687@z991.linuxsc.com> schrieb:
>
>> Taking C as a
>> canonical example, given that C does have precisely defined
>> precedence rules, it would be better if any redundant parentheses
>> were disallowed and flagged as errors by the compiler.
>
> I actually took this serious for a minute :-)

On this point you may rest assured I am quite serious.

>> In a very
>> short time there would be no confusion about what various
>> combinations of operators meant, and no worry about developers
>> misunderstanding them.
>
> On the off-chance that you were serious: Just publish branch of gcc
> or clang with these modification, and see what happens. Hint: You
> will fail boostrap :-)

That's a dumb comment. The two languages are not the same. There
is no reason to expect a C' compiler will successfully compile a C
program, regardless of whether the C program is a compiler or just
an ordinary program.

On Sunday, March 6, 2022 at 5:20:10 PM UTC-6, Tim Rentsch wrote:
> Niklas Holsti <niklas...@tidorum.invalid> writes:
>
> > On 2022-03-06 16:31, Tim Rentsch wrote:
> >
> >> an...@mips.complang.tuwien.ac.at (Anton Ertl) writes:
> >>
> >>> Ivan Godard <iv...@millcomputing.com> writes:
> >>>
> >>>> Declarable (!) precedence was a disaster
> >>>> in A68 - what's the precedence of left circular shift?
> >>
> >> (For the record, I agree that declarable precedence is a bad
> >> idea.)
> >>
> >>> IMO the general concept of precedence is a disaster. You can
> >>> do implicit parenthesizing between well-established pairs of
> >>> operators (e.g., a+b*c, but not "a or b and c"), or in a few
> >>> cases it's intuitive (a<b+c, a<b and c), but that does not
> >>> establish a transitive relation (don't accept a+b and c).
> >>>
> >>> My take would be to always require parenthesis when dealing
> >>> with a pair of operators that are not among the few exceptions
> >>> for which a binding relation is defined (when in doubt, don't
> >>> add an exception, e.g., for the pair of "and" and "or").
> >>
> >> In my view this conclusion is exactly backwards. Taking C as a
> >> canonical example, given that C does have precisely defined
> >> precedence rules, it would be better if any redundant parentheses
> >> were disallowed and flagged as errors by the compiler. In a very
> >> short time there would be no confusion about what various
> >> combinations of operators meant, and no worry about developers
> >> misunderstanding them.
> >
> > I don't believe that for a second! Many programmers switch between
> > languages, more or less frequently, and different languages have
> > different operator symbols and sometimes different precedence
> > systems. People forget fiddly things like precedences, especially when
> > they are sure that they remember...
<
> That's why it's important to include the second part of my
> proposal, where expected precedence relationships can be
> indicated with whitespace, and have those be checked during
> compilation. Doing that will also reinforce the learning
> process, because reading code supplies an ongoing stream of
> information about what the precedence relationships are in each
> of the various languages.
<
This sounds like a job for the text editor, coloring variables and operators
differently based on precedence. Text editors already do this for key words
in languages. They also match up ( with ) and [ with ] and { with }. Seems
like a natural extension.

On 3/3/2022 11:45 AM, MitchAlsup wrote:

snip

> I recently added messages to My 66000 ISA. The caller sends a number of
> registers to the called (in accordance with ABI) and whether or not the
> called can access callers memory through indirection. Called runs in a
> different address space, with different privilege, under a potentially
> different Guest OS. Here Return Address = 0x01 (a magic cookie).
> <
> When called executes a RET instruction, control returns to caller in his
> own address space, at his privilege, in a core of his affinity,...
> <
> The called "subroutine" cannot tell that he was invoked by the message
> or called locally, except by looking at RA being the magic cookie. This
> works if safe stack is in use or not on both sides.

How does this work with however different runs get access to the CPU, or
expressed differently, how does synchronous versus asynchronous message
passing work. That is, how is the following situation handled? The
"called" program is "stalled", waiting for a message that tells it what
to do next. When it gets the message it wants to proceed with its
processing independent of the called program, which wants to return to
whatever it is doing, and potentially want to pass another message to
the same or different run before the first called run is finished with
its work.

I apologize that I fear I am not expressing this clearly. :-( I want to
have a "master" task that say gets work requests from some external
source and then sends the requests to the appropriate "slave" task, then
returns to potentially get another request before the first one is
finished. (Assuming multiple cores or equivalent.)

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

On Sunday, March 6, 2022 at 5:38:27 PM UTC-6, Stephen Fuld wrote:
> On 3/3/2022 11:45 AM, MitchAlsup wrote:
>
> snip
>
> > I recently added messages to My 66000 ISA. The caller sends a number of
> > registers to the called (in accordance with ABI) and whether or not the
> > called can access callers memory through indirection. Called runs in a
> > different address space, with different privilege, under a potentially
> > different Guest OS. Here Return Address = 0x01 (a magic cookie).
> > <
> > When called executes a RET instruction, control returns to caller in his
> > own address space, at his privilege, in a core of his affinity,...
> > <
> > The called "subroutine" cannot tell that he was invoked by the message
> > or called locally, except by looking at RA being the magic cookie. This
> > works if safe stack is in use or not on both sides.
>
> How does this work with however different runs get access to the CPU, or
> expressed differently, how does synchronous versus asynchronous message
> passing work. That is, how is the following situation handled? The
> "called" program is "stalled", waiting for a message that tells it what
> to do next. When it gets the message it wants to proceed with its
> processing independent of the called program, which wants to return to
> whatever it is doing, and potentially want to pass another message to
> the same or different run before the first called run is finished with
> its work.
<
There are 3 components: Message Call, Send Message, and Return.
Message call passes a message to an identified thread and relinquishes control.
Send message passes a message to an identified thread and retains control.
Return (RET and EXIT) passes results back to a caller and relinquish control.
<
So, for example, an ADA rendezvous would return control to caller using
a Send message: caller regains control, called retains control. If they have
affinity to disjoint cores, they even run concurrently.
<
The caller has the option of allowing the called to look into its address
space; so a secretive Guest OS can ask for HyperVisor services without
enabling HyperVisor to look into its address space. Application calls
service provider in Guest OS using Message Call, and allows provider to
look into his address space. For example:: status= read( file, buffer, bytes );
File in application is a handle to file_information in Guest OS, buffer is
a sized[bytes] unit of memory in application virtual address space; status
is a result of performing the read() service call.
<
The hard part was hiding the various things threads should never be able
to see. Guest OS cannot see HyperVisor information, applications cannot
see Guest OS information. Yet, any thread can call/send messages to any
other thread, at least conceptually. I even envisioned a Guest OS/HyperVisor
service called : method = GetThread( "F:/guest OS/services/providers/thread" );
At this point forward, application can use method and it and service provider
can communicate.
>
> I apologize that I fear I am not expressing this clearly. :-( I want to
> have a "master" task that say gets work requests from some external
> source and then sends the requests to the appropriate "slave" task, then
> returns to potentially get another request before the first one is
> finished. (Assuming multiple cores or equivalent.)
<
You want Send message not Message call. Send message is also used
for ADA rendezvous, Deferred Procedure Calls, Soft_IRQs, and basically
anything one thread wants another thread to perform, with threads only
operating at its own defined priority and only on cores it has affinity. Send
can also be used to setup co-routines between multiple threads each
manipulating their own state machine to coordinate individual activities.
>
> --
> - Stephen Fuld
> (e-mail address disguised to prevent spam)

Ivan Godard <ivan@millcomputing.com> writes:
[(E)BNF, Stack effect notation]
>That seems a very limited notion of semantics.

Certainly. That's the point I am trying to make: Formal descriptions
have been successful for only very limited notions of semantics.

>Try something more of a
>challenge: the language's type system for example.

I think that type systems are an area where formal descriptions are
relatively close to being good enough to being used. The main problem
is that every programming language has its own type system with its
own twists, that results in its own notation. There is no unifying
notation like (E)BNF or stack effect notation that is usable for
describing many languages.

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

On 07/03/2022 00:25, MitchAlsup wrote:
> On Sunday, March 6, 2022 at 5:20:10 PM UTC-6, Tim Rentsch wrote:
>> Niklas Holsti <niklas...@tidorum.invalid> writes:
>>
>>> On 2022-03-06 16:31, Tim Rentsch wrote:
>>>
>>>> an...@mips.complang.tuwien.ac.at (Anton Ertl) writes:
>>>>
>>>>> Ivan Godard <iv...@millcomputing.com> writes:
>>>>>
>>>>>> Declarable (!) precedence was a disaster
>>>>>> in A68 - what's the precedence of left circular shift?
>>>>
>>>> (For the record, I agree that declarable precedence is a bad
>>>> idea.)
>>>>
>>>>> IMO the general concept of precedence is a disaster. You can
>>>>> do implicit parenthesizing between well-established pairs of
>>>>> operators (e.g., a+b*c, but not "a or b and c"), or in a few
>>>>> cases it's intuitive (a<b+c, a<b and c), but that does not
>>>>> establish a transitive relation (don't accept a+b and c).
>>>>>
>>>>> My take would be to always require parenthesis when dealing
>>>>> with a pair of operators that are not among the few exceptions
>>>>> for which a binding relation is defined (when in doubt, don't
>>>>> add an exception, e.g., for the pair of "and" and "or").
>>>>
>>>> In my view this conclusion is exactly backwards. Taking C as a
>>>> canonical example, given that C does have precisely defined
>>>> precedence rules, it would be better if any redundant parentheses
>>>> were disallowed and flagged as errors by the compiler. In a very
>>>> short time there would be no confusion about what various
>>>> combinations of operators meant, and no worry about developers
>>>> misunderstanding them.
>>>
>>> I don't believe that for a second! Many programmers switch between
>>> languages, more or less frequently, and different languages have
>>> different operator symbols and sometimes different precedence
>>> systems. People forget fiddly things like precedences, especially when
>>> they are sure that they remember...
> <
>> That's why it's important to include the second part of my
>> proposal, where expected precedence relationships can be
>> indicated with whitespace, and have those be checked during
>> compilation. Doing that will also reinforce the learning
>> process, because reading code supplies an ongoing stream of
>> information about what the precedence relationships are in each
>> of the various languages.
> <
> This sounds like a job for the text editor, coloring variables and operators
> differently based on precedence. Text editors already do this for key words
> in languages. They also match up ( with ) and [ with ] and { with }. Seems
> like a natural extension.
>

Colouring (or otherwise changing the font) of keywords, variables,
types, etc., is one thing. It associates a class of words with a
colour, making it easier for the programmer to match things up quickly.
The exact colour doesn't matter - one editor might use green for
keywords and blue for types, another editor has the opposite, and people
can switch between them easily.

But for operators it's a whole different world. For one thing, it is
far harder to distinguish fonts and colours for punctuation. The main
problem, however, is that you are now trying to use this to indicate an
ordering. If "&" is green and "<<" is yellow, how does that tell the
programmer about the precedence?

I'm a fan of "smart" highlighting in IDE's to make code easier to read.
But I don't see it in this particular case.

Extra parenthesis makes things abundantly clear at a glance - the reader
can be in no doubt. They are useful for operators that are relatively
rarely used or rarely used in particular combinations, but they are also
useful to give the reader an idea of how you are building up the
expression logically. Maybe "(a + b) + (c + d)" gives the reader more
information than just "a + b + c + d". Making code clear to read - so
that the compiler and the reader are in sync - is vital.

The worst possible choice is to have something controlled by programmer
but with no meaning in the language as a way to indicate precedence to
the reader. Using whitespace is worse than useless - how could it
possibly help anyone to write "a & b<<2" or "a&b << 2" ? Just write
either "a & (b << 2)" or "(a & b) << 2", depending on what you mean.
Only one of these needs parenthesis according to the language - both
need parenthesis according to the principles of writing clear code.

Another really bad idea is to rely on tools to spot problems - having
the compiler complain about extra parenthesis or see when white space
does not match precedence. People use lots of different tools, and
there is no way to enforce extra checking in these tools. People who
use good tools with lots of warnings and checks, frequently fail to use
them well and don't enable these checks. Then there are macros -
somehow the compiler is supposed to distinguish between these
non-semantic elements in user code (including the user's macros) while
ignoring them in other cases. Finally, there is the "existing code
base" issue. All in all, it is a completely impractical idea.

These things are always seen as a matter of opinion - and my opinion
here is very different from Tim's opinion. But they are also the
subject of serious studies and investigations that form the basis of
industry-standard coding standards. Now, you can well argue how good
the studies might be, but they are closer to "objective" than the
gut-feelings of individuals. In industries where coding styles are
controlled and standardised, extra parenthesis are required (and if that
makes things hard to read, expressions should be split up).

In the real world of programming, people's skills vary, and the type of
coding varies. There are programming groups where everyone in the team
knows all the precedence levels and can quote chapter and verse from the
C standards without looking. At the other end, there are groups where
people are learning as they go along and looking up everything - yet
still doing productive and useful work. Usually you should not code in
a way that dumbs things down for complete amateurs, but elitist code is
equally bad in most circumstances. The right balance depends on the
task at hand.

On 3/7/2022 12:19 AM, Anton Ertl wrote:
> Ivan Godard <ivan@millcomputing.com> writes:
> [(E)BNF, Stack effect notation]
>> That seems a very limited notion of semantics.
>
> Certainly. That's the point I am trying to make: Formal descriptions
> have been successful for only very limited notions of semantics.
>
>> Try something more of a
>> challenge: the language's type system for example.
>
> I think that type systems are an area where formal descriptions are
> relatively close to being good enough to being used. The main problem
> is that every programming language has its own type system with its
> own twists, that results in its own notation. There is no unifying
> notation like (E)BNF or stack effect notation that is usable for
> describing many languages.
>
> - anton

There is such: VWG, perhaps others. There are two problems: VWG itself
is a mouthful, and to formalize a type system by any complete and
correct means you have to have defined the system, and no new language
has gotten all the arm-waving out.

On 3/7/2022 12:34 AM, David Brown wrote:
> On 07/03/2022 00:25, MitchAlsup wrote:
>> On Sunday, March 6, 2022 at 5:20:10 PM UTC-6, Tim Rentsch wrote:
>>> Niklas Holsti <niklas...@tidorum.invalid> writes:
>>>
>>>> On 2022-03-06 16:31, Tim Rentsch wrote:
>>>>
>>>>> an...@mips.complang.tuwien.ac.at (Anton Ertl) writes:
>>>>>
>>>>>> Ivan Godard <iv...@millcomputing.com> writes:
>>>>>>
>>>>>>> Declarable (!) precedence was a disaster
>>>>>>> in A68 - what's the precedence of left circular shift?
>>>>>
>>>>> (For the record, I agree that declarable precedence is a bad
>>>>> idea.)
>>>>>
>>>>>> IMO the general concept of precedence is a disaster. You can
>>>>>> do implicit parenthesizing between well-established pairs of
>>>>>> operators (e.g., a+b*c, but not "a or b and c"), or in a few
>>>>>> cases it's intuitive (a<b+c, a<b and c), but that does not
>>>>>> establish a transitive relation (don't accept a+b and c).
>>>>>>
>>>>>> My take would be to always require parenthesis when dealing
>>>>>> with a pair of operators that are not among the few exceptions
>>>>>> for which a binding relation is defined (when in doubt, don't
>>>>>> add an exception, e.g., for the pair of "and" and "or").
>>>>>
>>>>> In my view this conclusion is exactly backwards. Taking C as a
>>>>> canonical example, given that C does have precisely defined
>>>>> precedence rules, it would be better if any redundant parentheses
>>>>> were disallowed and flagged as errors by the compiler. In a very
>>>>> short time there would be no confusion about what various
>>>>> combinations of operators meant, and no worry about developers
>>>>> misunderstanding them.
>>>>
>>>> I don't believe that for a second! Many programmers switch between
>>>> languages, more or less frequently, and different languages have
>>>> different operator symbols and sometimes different precedence
>>>> systems. People forget fiddly things like precedences, especially when
>>>> they are sure that they remember...
>> <
>>> That's why it's important to include the second part of my
>>> proposal, where expected precedence relationships can be
>>> indicated with whitespace, and have those be checked during
>>> compilation. Doing that will also reinforce the learning
>>> process, because reading code supplies an ongoing stream of
>>> information about what the precedence relationships are in each
>>> of the various languages.
>> <
>> This sounds like a job for the text editor, coloring variables and operators
>> differently based on precedence. Text editors already do this for key words
>> in languages. They also match up ( with ) and [ with ] and { with }. Seems
>> like a natural extension.
>>
>
> Colouring (or otherwise changing the font) of keywords, variables,
> types, etc., is one thing. It associates a class of words with a
> colour, making it easier for the programmer to match things up quickly.
> The exact colour doesn't matter - one editor might use green for
> keywords and blue for types, another editor has the opposite, and people
> can switch between them easily.
>
> But for operators it's a whole different world. For one thing, it is
> far harder to distinguish fonts and colours for punctuation. The main
> problem, however, is that you are now trying to use this to indicate an
> ordering. If "&" is green and "<<" is yellow, how does that tell the
> programmer about the precedence?
>
> I'm a fan of "smart" highlighting in IDE's to make code easier to read.
> But I don't see it in this particular case.
>
> Extra parenthesis makes things abundantly clear at a glance - the reader
> can be in no doubt. They are useful for operators that are relatively
> rarely used or rarely used in particular combinations, but they are also
> useful to give the reader an idea of how you are building up the
> expression logically. Maybe "(a + b) + (c + d)" gives the reader more
> information than just "a + b + c + d". Making code clear to read - so
> that the compiler and the reader are in sync - is vital.

Which is why having no precedence at all, just lexical order on the
page, gets rid of all the problems.

> The worst possible choice is to have something controlled by programmer
> but with no meaning in the language as a way to indicate precedence to
> the reader.

This was A68's bete noir.

> Using whitespace is worse than useless - how could it
> possibly help anyone to write "a & b<<2" or "a&b << 2" ? Just write
> either "a & (b << 2)" or "(a & b) << 2", depending on what you mean.
> Only one of these needs parenthesis according to the language - both
> need parenthesis according to the principles of writing clear code.

Is that white area a space or a tab? Does it make a difference?

> Another really bad idea is to rely on tools to spot problems - having
> the compiler complain about extra parenthesis or see when white space
> does not match precedence. People use lots of different tools, and
> there is no way to enforce extra checking in these tools. People who
> use good tools with lots of warnings and checks, frequently fail to use
> them well and don't enable these checks. Then there are macros -
> somehow the compiler is supposed to distinguish between these
> non-semantic elements in user code (including the user's macros) while
> ignoring them in other cases. Finally, there is the "existing code
> base" issue. All in all, it is a completely impractical idea.
>
>
> These things are always seen as a matter of opinion - and my opinion
> here is very different from Tim's opinion. But they are also the
> subject of serious studies and investigations that form the basis of
> industry-standard coding standards. Now, you can well argue how good
> the studies might be, but they are closer to "objective" than the
> gut-feelings of individuals. In industries where coding styles are
> controlled and standardised, extra parenthesis are required (and if that
> makes things hard to read, expressions should be split up).
>
> In the real world of programming, people's skills vary, and the type of
> coding varies. There are programming groups where everyone in the team
> knows all the precedence levels and can quote chapter and verse from the
> C standards without looking. At the other end, there are groups where
> people are learning as they go along and looking up everything - yet
> still doing productive and useful work. Usually you should not code in
> a way that dumbs things down for complete amateurs, but elitist code is
> equally bad in most circumstances. The right balance depends on the
> task at hand.
>

EricP <ThatWouldBeTelling@thevillage.com> wrote:
> Anton Ertl wrote:
> > For the current implementation technology (with separate I-cache) and
> > renamed registers with register port limits, the architects designed
> > ldp/stp.
> >
> > In 1983, with no caches, and instructions competing with data for RAM
> > access, LDM/STM worked nicely, not just for function
> > prologue/epilogue, but also for copying and initializing large memory
> > blocks.
>
> The original ARM1 and later commercial ARMv3 aka ARM6 didn't use microcode
> for LDM/STM. The register save/restore set was specified by a 16-bit mask
> and the control sequencer selects the registers with a priority encoder.
>
> You can see in the attached micrograph of the ARM1 the priority encoder,
> which is only present to support LDM/STM, at the top of the picture takes
> as much chip area as the whole rest of the decoder.
>
> http://www.righto.com/2016/02/reverse-engineering-arm1-instruction.html
>
> On ARM1 LDM/STM were by far the most HW expensive instructions and
> (just guessing) probably remained so even after they added
> MUL instructions which likely used Booth's shift-add.

The reason for this is that it made optimal use of DRAM bandwidth, being
essentially burst read/write operation. At the start of the LDM/STM you did
a row select, and then you only needed a column select for each subsequent
32-bit value being transferred (unless you wrapped off the end of a row).
In a MIPS style machine you'd be doing a full DRAM fetch (two cycles) each
time *and* you'd be doing an instruction fetch (from DRAM, another two
cycles), which would mean four cycles for every 32 bit transferred rather
than one. This was probably a good contribution to ARM2's competitiveness.

These days with caches the calculus has changed: instruction fetches from
cache are 'free' (no DRAM cycles) and bursting from cache makes life
complicated when you're crossing cache lines/page boundaries. Hence
load/store pair and vector instructions sit at different tradeoff points.

Theo

Ivan Godard wrote:
>
> In all the discussion here about STM/LDM here I have yet to see a case
> where the address of the location wasn't the same for every use, or
> could be the same with a little rearranging of the call protocol. But if
> the address is always static known, why not fold the action into some
> other instruction and do it lazy?
>
> Have I overlooked some usecase?

It sounds like you are suggesting that the effective address of the
save/restore block be implied by LDM/STM. I think that is too constrained
as in each of the following it is a software specified decision.

- kernel and/or user mode thread switch
- setjmp,longjmp
- user mode exception/signal handler entry,exit
- languages with structured exception handling, try...catch
need to spill all the dynamic registers before entry so the handler,
if triggered, has a known location to pick variables up.

For example, does the structured exception handler prologue spill
to the current frame FP-relative or stack SP-relative? At what offset?
And if SP-relative is the save area allocated earlier or on demand?
All of those design decisions are implementation specific.

Ivan Godard wrote:
> On 3/7/2022 12:34 AM, David Brown wrote:
>>
>> Extra parenthesis makes things abundantly clear at a glance - the reader
>> can be in no doubt. They are useful for operators that are relatively
>> rarely used or rarely used in particular combinations, but they are also
>> useful to give the reader an idea of how you are building up the
>> expression logically. Maybe "(a + b) + (c + d)" gives the reader more
>> information than just "a + b + c + d". Making code clear to read - so
>> that the compiler and the reader are in sync - is vital.
>
> Which is why having no precedence at all, just lexical order on the
> page, gets rid of all the problems.

Ah but then we will have the left-endians and the right-endians,
and heretics will still abound!

On 3/7/2022 7:10 AM, EricP wrote:
> Ivan Godard wrote:
>>
>> In all the discussion here about STM/LDM here I have yet to see a case
>> where the address of the location wasn't the same for every use, or
>> could be the same with a little rearranging of the call protocol. But
>> if the address is always static known, why not fold the action into
>> some other instruction and do it lazy?
>>
>> Have I overlooked some usecase?
>
> It sounds like you are suggesting that the effective address of the
> save/restore block be implied by LDM/STM. I think that is too constrained
> as in each of the following it is a software specified decision.
>
> - kernel and/or user mode thread switch
> - setjmp,longjmp
> - user mode exception/signal handler entry,exit
> - languages with structured exception handling, try...catch
>   need to spill all the dynamic registers before entry so the handler,
>   if triggered, has a known location to pick variables up.
>
> For example, does the structured exception handler prologue spill
> to the current frame FP-relative or stack SP-relative? At what offset?
> And if SP-relative is the save area allocated earlier or on demand?
> All of those design decisions are implementation specific.
>

When solutions are complicated it's usually a sign that the problem has
been defined as complicated.

> - kernel and/or user mode thread switch

What's this "mode" thing you speak of?

> - setjmp,longjmp

are these speed sensitive?

> - user mode exception/signal handler entry,exit

Why are exceptions different from calls you didn't ask for?

> - languages with structured exception handling, try...catch
> need to spill all the dynamic registers before entry so the handler,

why before entry, as opposed to lazy later?

> if triggered, has a known location to pick variables up.

Why not?

On 3/7/2022 7:26 AM, EricP wrote:
> Ivan Godard wrote:
>> On 3/7/2022 12:34 AM, David Brown wrote:
>>>
>>> Extra parenthesis makes things abundantly clear at a glance - the reader
>>> can be in no doubt.  They are useful for operators that are relatively
>>> rarely used or rarely used in particular combinations, but they are also
>>> useful to give the reader an idea of how you are building up the
>>> expression logically.  Maybe "(a + b) + (c + d)" gives the reader more
>>> information than just "a + b + c + d".  Making code clear to read - so
>>> that the compiler and the reader are in sync - is vital.
>>
>> Which is why having no precedence at all, just lexical order on the
>> page, gets rid of all the problems.
>
> Ah but then we will have the left-endians and the right-endians,
> and heretics will still abound!

English vs. Arabic vs. Chinese ideograms. It is trivial for your IDE to
rotate the whole of your code to the preferred direction

On 3/7/2022 7:02 AM, Ivan Godard wrote:
> On 3/7/2022 12:34 AM, David Brown wrote:
>> On 07/03/2022 00:25, MitchAlsup wrote:
>>> On Sunday, March 6, 2022 at 5:20:10 PM UTC-6, Tim Rentsch wrote:
>>>> Niklas Holsti <niklas...@tidorum.invalid> writes:
>>>>
>>>>> On 2022-03-06 16:31, Tim Rentsch wrote:
>>>>>
>>>>>> an...@mips.complang.tuwien.ac.at (Anton Ertl) writes:
>>>>>>
>>>>>>> Ivan Godard <iv...@millcomputing.com> writes:
>>>>>>>
>>>>>>>> Declarable (!) precedence was a disaster
>>>>>>>> in A68 - what's the precedence of left circular shift?
>>>>>>
>>>>>> (For the record, I agree that declarable precedence is a bad
>>>>>> idea.)
>>>>>>
>>>>>>> IMO the general concept of precedence is a disaster. You can
>>>>>>> do implicit parenthesizing between well-established pairs of
>>>>>>> operators (e.g., a+b*c, but not "a or b and c"), or in a few
>>>>>>> cases it's intuitive (a<b+c, a<b and c), but that does not
>>>>>>> establish a transitive relation (don't accept a+b and c).
>>>>>>>
>>>>>>> My take would be to always require parenthesis when dealing
>>>>>>> with a pair of operators that are not among the few exceptions
>>>>>>> for which a binding relation is defined (when in doubt, don't
>>>>>>> add an exception, e.g., for the pair of "and" and "or").
>>>>>>
>>>>>> In my view this conclusion is exactly backwards. Taking C as a
>>>>>> canonical example, given that C does have precisely defined
>>>>>> precedence rules, it would be better if any redundant parentheses
>>>>>> were disallowed and flagged as errors by the compiler. In a very
>>>>>> short time there would be no confusion about what various
>>>>>> combinations of operators meant, and no worry about developers
>>>>>> misunderstanding them.
>>>>>
>>>>> I don't believe that for a second! Many programmers switch between
>>>>> languages, more or less frequently, and different languages have
>>>>> different operator symbols and sometimes different precedence
>>>>> systems. People forget fiddly things like precedences, especially when
>>>>> they are sure that they remember...
>>> <
>>>> That's why it's important to include the second part of my
>>>> proposal, where expected precedence relationships can be
>>>> indicated with whitespace, and have those be checked during
>>>> compilation. Doing that will also reinforce the learning
>>>> process, because reading code supplies an ongoing stream of
>>>> information about what the precedence relationships are in each
>>>> of the various languages.
>>> <
>>> This sounds like a job for the text editor, coloring variables and
>>> operators
>>> differently based on precedence. Text editors already do this for key
>>> words
>>> in languages. They also match up ( with ) and [ with ] and { with }.
>>> Seems
>>> like a natural extension.
>>>
>>
>> Colouring (or otherwise changing the font) of keywords, variables,
>> types, etc., is one thing.  It associates a class of words with a
>> colour, making it easier for the programmer to match things up quickly.
>>   The exact colour doesn't matter - one editor might use green for
>> keywords and blue for types, another editor has the opposite, and people
>> can switch between them easily.
>>
>> But for operators it's a whole different world.  For one thing, it is
>> far harder to distinguish fonts and colours for punctuation.  The main
>> problem, however, is that you are now trying to use this to indicate an
>> ordering.  If "&" is green and "<<" is yellow, how does that tell the
>> programmer about the precedence?
>>
>> I'm a fan of "smart" highlighting in IDE's to make code easier to read.
>>   But I don't see it in this particular case.
>>
>> Extra parenthesis makes things abundantly clear at a glance - the reader
>> can be in no doubt.  They are useful for operators that are relatively
>> rarely used or rarely used in particular combinations, but they are also
>> useful to give the reader an idea of how you are building up the
>> expression logically.  Maybe "(a + b) + (c + d)" gives the reader more
>> information than just "a + b + c + d".  Making code clear to read - so
>> that the compiler and the reader are in sync - is vital.
>
> Which is why having no precedence at all, just lexical order on the
> page, gets rid of all the problems.

I am reminded of the calculator debate; algebraic versus RPN entry. RPN
may be more "elegant", and eliminates parentheses, but eventually pretty
much lost out.

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