[m-users.] That parallel low-level C bug

[Zoltan Somogyi]

On Mon, 14 Sep 2026 10:50:34 +0200, Volker Wysk <post at volker-wysk.de> wrote:
> "Sorry, but the implementation of parallelism for low-level C code
> currently has a bug that causes the generated code to be unreliable.
> Until that bug is fixed, this mmc does not support this combination."

> What is "this combination"?

The one in the previous sentence: "paralellism" and "low-level C code".

> Of grade components?

Yes, they are.

> Then I would replace
> "this combination" with "the current grade".

That would imply that sticking e.g. ".stseg" on the grade
might change things. It cannot.

> Since no "asm_fast.par" grades are available, you need to compile in a
> high level C grade instead. But some programs need the tail recursion
> optimization, which isn't available there.

Yes, it is. For about a decade, tail recursion optimization has been
almost as good in high level C grades as in low level C grades.
For most purposes, though not all, they are just as good.
 
> When I try to compile in a high-level C grade, doing this:
> 
> :- pragma require_tail_recursion(master_loop_normal/12,
>     [error, in_all_grades]).
> 
> ... then I get:
> 
> mfwpar.m:1044: Error in predicate `master_loop_abort'/12:
> mfwpar.m:1044:   this self-recursive call is not tail recursive.

The differences between low and high level C's ability to do
tail recursion involve *mutual* recursion. If a self-recursive call
is not tail recursive in a hlc grade, it won't be tail recursive
in a low level C grade either, UNLESS some other grade component
prevents ALL tail recursion.

I am pretty sure that there is some computation in the code
of master_loop_abort that takes as input some result of the call
on line 1044, and therefore must be done after that call.

> And here, please add "in the current grade" to the message.

The test for tail recursion is always specific to the current grade.
It would be expensive to repeat the test in any other grade,
and your proposed message extension could be misleading
without the compiler knowing that the result *can be different*
in a different grade.

> I'm wondering how bad the lack of tail recursion optimization in hlc
> grades is.

Not bad at all.

> Is there only a constant amount of stack space available?
> Won't it grow automatically? I can't see any hlc grade with ".stseg".
> We have multi-gigabytes of RAM nowadays, so if the stack would grow as
> needed, it might still work.

The whole point of high level C grades is that they generate *normal*
C code, which means that the C compiler is in charge of managing the stack.
All of your questions have the same answers as if you asked the implementor
of the C compiler: stack space can and will grow dynamically as needed,
until you run the whole computer out of memory and swap space.

> Is the fixing of the problem in process?

There is no problem of "finite stack space in hlc grades"  to fix.

Zoltan.