On 3/6/2022 4:49 PM, MitchAlsup wrote:
> On Sunday, March 6, 2022 at 5:38:27 PM UTC-6, Stephen Fuld wrote:

snip

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

Good. Just to check my understanding, "Send" sends a message to some
other task, then returns immediately to the sending task? That seems
clean for the send side.

But a few questions about the receiving side (let me abbreviate it RS).
How does RS indicate it is ready to receive a message? If the RS is
"busy" when someone sends it a message, is the message queued somewhere?
If so, can the RS "inspect" the queue or at least tell if there is
one? There are a lot of scenarios that people might want, and I want to
see how they are accommodated.

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

On Monday, March 7, 2022 at 9:10:49 AM UTC-6, 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?
<
struct xyz function( struct xyz a);
{}
<
xyzarray[k] = function( xyzarray[k] );
<
MUL R25,Ri,sizeof(struct xyz)
LDM R1,[Rxyzarray+R25]
CALL function
STM R1,[Rxyzarray+R25]
<
note: pass by value, return by value.
> >
> > 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.
<
This implication, in my opinion, can be done for prologue and epilogue
but basically not for anything else.
<
>
> - kernel and/or user mode thread switch
<
Note: My 66000 does not have the CPU change threads by executing
instructions........
<
> - setjmp,longjmp
<
I got ENTER and EXIT to do this.
<
> - user mode exception/signal handler entry,exit
<
Note: My 66000 does not need code to save/restore state as
control arrives at or leaves from various "handlers".
<
> - 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.
<
ENTER and EXIT again.
>
> For example, does the structured exception handler prologue spill
> to the current frame FP-relative or stack SP-relative? At what offset?
<
Why not spill the registers to their permanent in-memory locations ?
<
> And if SP-relative is the save area allocated earlier or on demand?
> All of those design decisions are implementation specific.

On Monday, March 7, 2022 at 9:26:55 AM UTC-6, 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!
<
Is there any room for a middle-endian ? That is start from the middle
and progress outwards in both directions simultaneously.

On Monday, March 7, 2022 at 11:22:09 AM UTC-6, Stephen Fuld wrote:
> On 3/6/2022 4:49 PM, MitchAlsup wrote:
> > On Sunday, March 6, 2022 at 5:38:27 PM UTC-6, Stephen Fuld wrote:
> snip
> >> 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.
> Good. Just to check my understanding, "Send" sends a message to some
> other task, then returns immediately to the sending task? That seems
> clean for the send side.
>
> But a few questions about the receiving side (let me abbreviate it RS).
> How does RS indicate it is ready to receive a message? If the RS is
> "busy" when someone sends it a message, is the message queued somewhere?
<
Queued.
<
> If so, can the RS "inspect" the queue or at least tell if there is one?
<
There is an instruction whereby RS would ask if the queue is non-empty.
But I am still working in this domain of the architecture. I want to
accommodate ADA semantics.
<
< There are a lot of scenarios that people might want, and I want to
> see how they are accommodated.
> --
> - Stephen Fuld
> (e-mail address disguised to prevent spam)

MitchAlsup wrote:
> On Monday, March 7, 2022 at 11:22:09 AM UTC-6, Stephen Fuld wrote:
>> On 3/6/2022 4:49 PM, MitchAlsup wrote:
>>> On Sunday, March 6, 2022 at 5:38:27 PM UTC-6, Stephen Fuld wrote:
>> snip
>>>> 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.
>> Good. Just to check my understanding, "Send" sends a message to some
>> other task, then returns immediately to the sending task? That seems
>> clean for the send side.
>>
>> But a few questions about the receiving side (let me abbreviate it RS).
>> How does RS indicate it is ready to receive a message? If the RS is
>> "busy" when someone sends it a message, is the message queued somewhere?
> <
> Queued.
> <
>> If so, can the RS "inspect" the queue or at least tell if there is one?
> <
> There is an instruction whereby RS would ask if the queue is non-empty.
> But I am still working in this domain of the architecture. I want to
> accommodate ADA semantics.
> <
> < There are a lot of scenarios that people might want, and I want to
>> see how they are accommodated.

By the way, synchronous Ada rendezvous allows deadlock.
I haven't looked at it but I believe deadlock detection
between arbitrary tasks is a traveling salesman problem.

On 3/7/2022 9:36 AM, MitchAlsup wrote:
> On Monday, March 7, 2022 at 9:26:55 AM UTC-6, 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!
> <
> Is there any room for a middle-endian ? That is start from the middle
> and progress outwards in both directions simultaneously.

No languages that I know of are middle-endian in that sense. However
several switch directions at each line: l2r->r2l->l2r->etc, an endless
snake.

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

Yes, that makes sense.
Even for a mid-80's TTL DRAM controller I would be
surprised if it didn't have same-row detection.
Its a few latches and xors.

So you are saying that because LDM/STM do a single instruction fetch,
then a sequence of data addresses, it allows same-row detection
and just a column address strobe CAS will do.
For a sequence of individual LD or ST, the instruction addresses
would most likely be to a different row than their data addresses
so same-row detect doesn't kick in, and requires full RAS and CAS.

On 2022-03-07 19:54, Ivan Godard wrote:
> On 3/7/2022 9:36 AM, MitchAlsup wrote:
>> On Monday, March 7, 2022 at 9:26:55 AM UTC-6, 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!
>> <
>> Is there any room for a middle-endian ? That is start from the middle
>> and progress outwards in both directions simultaneously.
>
> No languages that I know of are middle-endian in that sense. However
> several switch directions at each line: l2r->r2l->l2r->etc, an endless
> snake.

In some viruses (I believe) the genetic code can be read in both
directions along the DNA or RNA strand, and each direction produces
different useful proteins. So a language without precedence could be
both left-to-right and right-to-left, computing two different useful
answers at the same time.

Ivan Godard wrote:
> 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.

I don't think this is complicated.
Sometimes one wants to take a specified set of registers and
store them in a contiguous memory block of ones' choosing.

> > - kernel and/or user mode thread switch
>
> What's this "mode" thing you speak of?

Privilege mode - user or super.

> > - setjmp,longjmp
>
> are these speed sensitive?

Its not about speed. People use LDM/STM as it is a concise way
to specify a set of registers to save/restore in a contiguous block.
That it also offers hardware a chance to optimize the sequence is a bonus.

> > - user mode exception/signal handler entry,exit
>
> Why are exceptions different from calls you didn't ask for?

If I was doing it, the OS deposits (pushes) a packet of exception info
and the return PC onto the apps' user mode stack, and OS returns to
the exception routine. User mode exception handler saves the full integer
context on the stack, and calls the exception dispatcher routine
passing pointers to the exception info and saved context structs as args.
Exception handlers can edit saved context as they wish.
When handlers return, exception dispatcher reloads the now possibly edited
interrupted context, restores stack, and returns to the possibly edited PC.

> > - 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 the try-catch calls inner routines and those throw an exception,
the exception dispatcher walks the stack evaluating catch conditions
in the context of each catch's frame, then the saved info has to be
valid and in a known location in that frame.

Yes it could be done lazy, and possibly the save even canceled later,
but then you'd need a mechanism to sync the memory state under various
conditions, like if any interrupt or exception occurred,
or upon manual request.

Sparc ran into various issues with its lazy register windows
so I'd check on their experiences first before going the lazy route.
There could be issues with multi-threading like where one threads'
lazy update memory is passed by reference to another thread
which doesn't know it is lazy update.

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

On Monday, March 7, 2022 at 11:54:19 AM UTC-6, Ivan Godard wrote:
> On 3/7/2022 9:36 AM, MitchAlsup wrote:
> > On Monday, March 7, 2022 at 9:26:55 AM UTC-6, 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!
> > <
> > Is there any room for a middle-endian ? That is start from the middle
> > and progress outwards in both directions simultaneously.
> No languages that I know of are middle-endian in that sense. However
> several switch directions at each line: l2r->r2l->l2r->etc, an endless
> snake.
<
That is almost Z-ordering.

On Monday, March 7, 2022 at 1:12:43 PM UTC-6, EricP wrote:
> Ivan Godard wrote:
> > 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.
> I don't think this is complicated.
> Sometimes one wants to take a specified set of registers and
> store them in a contiguous memory block of ones' choosing.
> > > - kernel and/or user mode thread switch
> >
> > What's this "mode" thing you speak of?
> Privilege mode - user or super.
> > > - setjmp,longjmp
> >
> > are these speed sensitive?
> Its not about speed. People use LDM/STM as it is a concise way
> to specify a set of registers to save/restore in a contiguous block.
> That it also offers hardware a chance to optimize the sequence is a bonus.
> > > - user mode exception/signal handler entry,exit
> >
> > Why are exceptions different from calls you didn't ask for?
> If I was doing it, the OS deposits (pushes) a packet of exception info
> and the return PC onto the apps' user mode stack, and OS returns to
> the exception routine. User mode exception handler saves the full integer
> context on the stack, and calls the exception dispatcher routine
> passing pointers to the exception info and saved context structs as args.
> Exception handlers can edit saved context as they wish.
> When handlers return, exception dispatcher reloads the now possibly edited
> interrupted context, restores stack, and returns to the possibly edited PC.
> > > - 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 the try-catch calls inner routines and those throw an exception,
> the exception dispatcher walks the stack evaluating catch conditions
> in the context of each catch's frame, then the saved info has to be
> valid and in a known location in that frame.
<
The stack walker must also ~new the newed structures as it walks
the stack back.
>
> Yes it could be done lazy, and possibly the save even canceled later,
> but then you'd need a mechanism to sync the memory state under various
> conditions, like if any interrupt or exception occurred,
> or upon manual request.
>
> Sparc ran into various issues with its lazy register windows
> so I'd check on their experiences first before going the lazy route.
> There could be issues with multi-threading like where one threads'
> lazy update memory is passed by reference to another thread
> which doesn't know it is lazy update.
> > > if triggered, has a known location to pick variables up.
> >
> > Why not?

On 3/7/2022 11:09 AM, Niklas Holsti wrote:
> On 2022-03-07 19:54, Ivan Godard wrote:
>> On 3/7/2022 9:36 AM, MitchAlsup wrote:
>>> On Monday, March 7, 2022 at 9:26:55 AM UTC-6, 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!
>>> <
>>> Is there any room for a middle-endian ? That is start from the middle
>>> and progress outwards in both directions simultaneously.
>>
>> No languages that I know of are middle-endian in that sense. However
>> several switch directions at each line: l2r->r2l->l2r->etc, an endless
>> snake.
>
>
> In some viruses (I believe) the genetic code can be read in both
> directions along the DNA or RNA strand, and each direction produces
> different useful proteins. So a language without precedence could be
> both left-to-right and right-to-left, computing two different useful
> answers at the same time.
>

Clever! Some also get more than one protein from a xna strand by
starting the frame on a different one of the three coding phases.

I did that last trick in a memory-dumping utility for the B6500 that had
to entirely fit on an 80-column card, but I've never written code that
read backwards. As it happens, one could do that on a Mill, because the
two decoders read away from each other. Sounds like a challenge for Terje!

On 3/7/2022 11:10 AM, EricP wrote:
> Ivan Godard wrote:
>> 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.
>
> I don't think this is complicated.
> Sometimes one wants to take a specified set of registers and
> store them in a contiguous memory block of ones' choosing.
>
>>  > - kernel and/or user mode thread switch
>>
>> What's this "mode" thing you speak of?
>
> Privilege mode - user or super.

Sorry, missing irony alert. Note that neither Mill not my66 have
user/super modes.

>
>>  > - setjmp,longjmp
>>
>> are these speed sensitive?
>
> Its not about speed. People use LDM/STM as it is a concise way
> to specify a set of registers to save/restore in a contiguous block.
> That it also offers hardware a chance to optimize the sequence is a bonus.

Notation is handled by an asm macro; why have an actual instruction?

>
>>  > - user mode exception/signal handler entry,exit
>>
>> Why are exceptions different from calls you didn't ask for?
>
> If I was doing it, the OS deposits (pushes) a packet of exception info
> and the return PC onto the apps' user mode stack, and OS returns to
> the exception routine. User mode exception handler saves the full integer
> context on the stack, and calls the exception dispatcher routine
> passing pointers to the exception info and saved context structs as args.
> Exception handlers can edit saved context as they wish.
> When handlers return, exception dispatcher reloads the now possibly edited
> interrupted context, restores stack, and returns to the possibly edited PC.

How do you do it if there are no modes?

On 07/03/2022 16:02, 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.

That would get rid of such problems (though obviously it is not
applicable to C or C-like languages). However, it would introduce new
problems - people expect "a + b * c" to have the same precedence as in
normal mathematics.

Other alternatives would be to switch to prefix functional notation
"add(a, multiply(b, c))" or postfix RPN like Forth "a b c * +", where
you don't need precedence levels to make things unambiguous.

>
>> 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?
>
I wrote it with space characters - but I think making a language
sensitive to the number or type of white spaces is at best a
questionable decision. (Newline can be different from spaces or tabs in
some circumstances.) Python's decision to use indentation for block
structuring is not universally popular, and make's distinction between
leading spaces and leading tabs is considered its worst feature (by the
original author of the program).

On 07/03/2022 18:36, MitchAlsup wrote:
> On Monday, March 7, 2022 at 9:26:55 AM UTC-6, 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!
> <
> Is there any room for a middle-endian ? That is start from the middle
> and progress outwards in both directions simultaneously.
>

Why limit yourself to two directions?

<https://en.wikipedia.org/wiki/Befunge>

On 07/03/2022 18:54, Ivan Godard wrote:
> On 3/7/2022 9:36 AM, MitchAlsup wrote:
>> On Monday, March 7, 2022 at 9:26:55 AM UTC-6, 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!
>> <
>> Is there any room for a middle-endian ? That is start from the middle
>> and progress outwards in both directions simultaneously.
>
> No languages that I know of are middle-endian in that sense. However
> several switch directions at each line: l2r->r2l->l2r->etc, an endless
> snake.

I think such direction-switching writing is only found historically, and
not used by any current languages.

<https://en.wikipedia.org/wiki/Boustrophedon>

On Monday, March 7, 2022 at 2:24:27 PM UTC-6, David Brown wrote:
> On 07/03/2022 16:02, 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.
> That would get rid of such problems (though obviously it is not
> applicable to C or C-like languages). However, it would introduce new
> problems - people expect "a + b * c" to have the same precedence as in
> normal mathematics.
<
Only when you have never written in a precedence-free language.
<
a + b * c
<
Reads just like ASM:
<
ADD Rt,Ra,Rb
MUL Rt,Rt,Rc
>
> Other alternatives would be to switch to prefix functional notation
> "add(a, multiply(b, c))" or postfix RPN like Forth "a b c * +", where
> you don't need precedence levels to make things unambiguous.
<
You will find the road ahead very steep indeed.
> >
> >> 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?
<
You forgot vertical tab, and page feed.
> >
> I wrote it with space characters - but I think making a language
> sensitive to the number or type of white spaces is at best a
> questionable decision. (Newline can be different from spaces or tabs in
> some circumstances.) Python's decision to use indentation for block
> structuring is not universally popular, and make's distinction between
> leading spaces and leading tabs is considered its worst feature (by the
> original author of the program).
<
All white space should be equivalent.

Tim Rentsch <tr.17687@z991.linuxsc.com> schrieb:
> 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.

Sorry for confusing intentional and unintentional humor, then.

On 07/03/2022 20:09, Niklas Holsti wrote:
>
> In some viruses (I believe) the genetic code can be read in both
> directions along the DNA or RNA strand, and each direction produces
> different useful proteins.

I know this is getting /really/ off-topic, but do you have any
references for that? I know that transcription from DNA to RNA can run
in both directions at once, but AFAIUI in eukaryotes there are
mechanisms in place to identify the wrong half and reject it.

From the way proteins are coded and the complexity of most of them, I
find it hard to imagine that you could get two useful proteins from the
same RNA in different directions - it's like trying to run a
byte-reversed program. It is (to me) a lot more believable that there
are bits of virus DNA or RNA that are simply backwards.

On 07/03/2022 22:48, MitchAlsup wrote:
> On Monday, March 7, 2022 at 2:24:27 PM UTC-6, David Brown wrote:
>> On 07/03/2022 16:02, 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.
>> That would get rid of such problems (though obviously it is not
>> applicable to C or C-like languages). However, it would introduce new
>> problems - people expect "a + b * c" to have the same precedence as in
>> normal mathematics.
> <
> Only when you have never written in a precedence-free language.
> <
> a + b * c
> <
> Reads just like ASM:
> <
> ADD Rt,Ra,Rb
> MUL Rt,Rt,Rc

I've written plenty of assembly. But assembly is not a precedence-free
language - it is a language using prefix functional notation. That is a
very different thing.

I know there /are/ languages without operator precedence, where "a + b *
c" is "(a + b) * c". And I expect that people who use them get used to
it. But I think it would take a fair amount of effort for most people
to change their thinking when starting with such a language, and
mistakes and misunderstandings would be common.

>>
>> Other alternatives would be to switch to prefix functional notation
>> "add(a, multiply(b, c))" or postfix RPN like Forth "a b c * +", where
>> you don't need precedence levels to make things unambiguous.
> <
> You will find the road ahead very steep indeed.

I have done a little (a very little) Forth programming. Yes, it
requires a bit of mind-twisting!

>>>
>>>> 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?
> <
> You forgot vertical tab, and page feed.

No one has used these this century. But you can include them if you
like (and perhaps some Unicode spaces of different sizes).

>>>
>> I wrote it with space characters - but I think making a language
>> sensitive to the number or type of white spaces is at best a
>> questionable decision. (Newline can be different from spaces or tabs in
>> some circumstances.) Python's decision to use indentation for block
>> structuring is not universally popular, and make's distinction between
>> leading spaces and leading tabs is considered its worst feature (by the
>> original author of the program).
> <
> All white space should be equivalent.
>

There is a convenience in things like line-limited comments, and it is
not uncommon for programming languages to equate "end of line" with "end
of statement". (This has its adherents and detractor.)

In general, however, I agree that white space should be equivalent.

Ivan Godard wrote:
> On 3/7/2022 11:09 AM, Niklas Holsti wrote:
>> On 2022-03-07 19:54, Ivan Godard wrote:
>>> On 3/7/2022 9:36 AM, MitchAlsup wrote:
>>>> On Monday, March 7, 2022 at 9:26:55 AM UTC-6, 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!
>>>> <
>>>> Is there any room for a middle-endian ? That is start from the middle
>>>> and progress outwards in both directions simultaneously.
>>>
>>> No languages that I know of are middle-endian in that sense. However
>>> several switch directions at each line: l2r->r2l->l2r->etc, an
>>> endless snake.
>>
>>
>> In some viruses (I believe) the genetic code can be read in both
>> directions along the DNA or RNA strand, and each direction produces
>> different useful proteins. So a language without precedence could be
>> both left-to-right and right-to-left, computing two different useful
>> answers at the same time.
>>
>
>
> Clever! Some also get more than one protein from a xna strand by
> starting the frame on a different one of the three coding phases.
>
> I did that last trick in a memory-dumping utility for the B6500 that had
> to entirely fit on an 80-column card, but I've never written code that
> read backwards. As it happens, one could do that on a Mill, because the
> two decoders read away from each other. Sounds like a challenge for Terje!

This is of course quite easy on a RISC style fixed-length instruction
set, you just need to write code that makes sense in both directions.

It is a bit more complicated with varible-length instructions like x86,
where you will very quickly run into issues like prefix bytes (like REP
CMPS etc), in order to use those for a block move I would need something
like MOVS REP MOVS, while all/most function calls require hiding the
opposite endian code inside immediates.

I.e. almost certainly doable, but very hard to make it space-saving.

Terje

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

David Brown wrote:
> On 07/03/2022 16:02, 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.
>
> That would get rid of such problems (though obviously it is not
> applicable to C or C-like languages). However, it would introduce new
> problems - people expect "a + b * c" to have the same precedence as in
> normal mathematics.
>
> Other alternatives would be to switch to prefix functional notation
> "add(a, multiply(b, c))" or postfix RPN like Forth "a b c * +", where
> you don't need precedence levels to make things unambiguous.
>
>>
>>> 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?
>>
> I wrote it with space characters - but I think making a language
> sensitive to the number or type of white spaces is at best a
> questionable decision. (Newline can be different from spaces or tabs in
> some circumstances.) Python's decision to use indentation for block
> structuring is not universally popular, and make's distinction between
> leading spaces and leading tabs is considered its worst feature (by the
> original author of the program).

Space vs Tab is a feature, not a bug, at least according to the Perl
Acme::Bleach module!

Insert "use Acme::Bleach;" at the top of your program, then run it once
which turns it into a new version with just that line at the top:
Everything else is just whitespace, but it still runs! :-)

Terje

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

David Brown <david.brown@hesbynett.no> schrieb:

> Maybe "(a + b) + (c + d)" gives the reader more
> information than just "a + b + c + d".

The two expressions might also mean different things (even in
the absence of operator overloading). Think floating point
arithmetic and a language which used parenthses to force
evaluation of something in parentheses first.

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

I concur.

George Neuner <gneuner2@comcast.net> writes:
>On Mon, 7 Mar 2022 07:02:23 -0800, Ivan Godard
><ivan@millcomputing.com> wrote:
>
>>Which is why having no precedence at all, just lexical order on the
>>page, gets rid of all the problems.
>
>Lisp tried that

And Forth and Postscript (without all these parentheses). And, for
infix, APL, Smalltalk and, as I learned here), Mary.

>... how many people today use SExpr languages?

Or any of the others.

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

On 2022-03-08 9:47, David Brown wrote:
> On 07/03/2022 20:09, Niklas Holsti wrote:
>>
>> In some viruses (I believe) the genetic code can be read in both
>> directions along the DNA or RNA strand, and each direction produces
>> different useful proteins.
>
> I know this is getting /really/ off-topic, but do you have any
> references for that? I know that transcription from DNA to RNA can run
> in both directions at once, but AFAIUI in eukaryotes there are
> mechanisms in place to identify the wrong half and reject it.
>
> From the way proteins are coded and the complexity of most of them, I
> find it hard to imagine that you could get two useful proteins from the
> same RNA in different directions - it's like trying to run a
> byte-reversed program. It is (to me) a lot more believable that there
> are bits of virus DNA or RNA that are simply backwards.

My recollection may be at fault, and I may have confused "direction"
with "sense" (that is, strand complementarity). Or I may have
mis-remembered the use of different coding-frame phases that Ivan
described (which is already an amazing feat of biology).

The section titled "Ambisense" in
https://en.wikipedia.org/wiki/Sense_(molecular_biology) seems to come
close, but perhaps it only means that the same RNA strand contains
sections that are read in one direction, and sections that are read in
the other direction, but no section is read in both directions. That
resembles the alternation of reading direction line by line that Ivan
also described. So, sorry, that is the closest I can come to a
reference. I would not have made my comment in a serious discussion
without checking it better.