Standard way to supply hints to branches

[Manu]

On Sat, 14 Sept 2024, 09:36 Johan via Digitalmars-d, <
digitalmars-d at puremagic.com> wrote:

> On Thursday, 12 September 2024 at 22:59:32 UTC, Manu wrote:
> >
> > expect() statements are not a good time.
>
> Why not?
> Expect is known from other languages and is more general (can
> work with wider range of values than just true/false, and can
> work with types too), and reduces the problem to the backend
> domain only: no new parsing rules (don't forget editors and other
> tooling), and no AST change, etc.
>

It's still ugly and relatively high impact on the code you markup though.
You have to insert additional lines in the flow and write expressions,
which is awkward if it's some long or compound expression, and it's also an
undesirable repetition of an expression; a tweak to some if(expr) may also
need to have a matching tweak to the expect statement, could lose sync, or
if you then suggest to resolve the expression to a local bool somewhere
before the expect() and the if(), then that's ANOTHER pointless line.

It's a bad time all round. We've moved on from expect statements. They have
their place, but it's not for this.

>> I think it would hurt D as a whole to
> >> have special stuff for such a rare thing.
> >>
> >
> > How?
> > And it's not 'rare'; it's 'niche'. For a microcontroller with
> > no branch
> > prediction, it's common and essential.
> > It's literally unworkable to write code for the platform
> > without this tool;
> > you can't have branches constantly mispredicting.
>
> It would help if your arguments would not use so much hyperbole.
> Obviously it is not unworkable, demonstrated by decades of
> microcontroller programming without it (C does not have it).


Huh? I've been writing expect statements in C for 20 years or maybe more...
It's always been a useful tool; but the reason it's actually way more
relevant today, is because the nature of static branch prediction in modern
micros where it's much more costly to mispredict in riscv or xtensa than it
used to be. Old arch's with weak (or no) branch prediction also had very
shallow pipelines, or even no pipelines in early micros. More advanced old
arch's did have dynamic branch predictors, but you could still gain some
optimisations from hunting code layout, or signalling an initial
prediction; though the value and applicability of this sort of hint was
MUCH narrower; it was rare to bother.

Modern arch's are pipelined, and a mispredict is relatively more costly.
I don't think there has ever been a time where we have had popular
architectures with meaningfully deep pipelines and without dynamic branch
prediction, where a mispredict is anywhere near as costly.
There's a reason it's been recently added to C++. This situation is new.

Also the nature of code on these micros today; they are hundreds of mhz and
we do a whole lot more with them, including more complex logic and number
crunching. Old micros were conveniently coded in asm, and nobody ever
really expected them to do much of anything.

These micros are comparable to a PlayStation 2 or something of that era;
there's a really great opportunity to write meaningful software for them.
~2004 is back... and it's actually a pretty interesting new domain.

Most micro software even on these modern processors doesn't do anything
particularly interesting (turns a light on or off over wifi); but if you
want to do something interesting with these chips, there's a lot of careful
handling which gives huge advantages. The branch predictor is *by far* the
most significant detail to take care. That's not hyperbole.

The "hurt" I meant is in maintenance of the compiler frontend
> which already is in quite a bad complexity state (subtle bugs
> existing and introduced upon almost every change). Adding yet
> another special case is imo a net loss.
>

I reckon we're dealing with one pointer to an attribute expression in the
branch node (which will be completely ignored except for by the backend),
and a line in the parser to allow attaching an attribute expression to that
pointer. I'd imagine the patch is less than 10 lines, and not very invasive
at all.

I don't see this is a special case. The grammar tweak would be no more
special case than attaching attributes to other declarations.
I reckon you're exaggerating the complexity.

>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20240915/4e859438/attachment.htm>