<div dir="auto"><div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, 14 Sept 2024, 09:36 Johan via Digitalmars-d, <<a href="mailto:digitalmars-d@puremagic.com">digitalmars-d@puremagic.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Thursday, 12 September 2024 at 22:59:32 UTC, Manu wrote:<br>
><br>
> expect() statements are not a good time.<br>
<br>
Why not?<br>
Expect is known from other languages and is more general (can <br>
work with wider range of values than just true/false, and can <br>
work with types too), and reduces the problem to the backend <br>
domain only: no new parsing rules (don't forget editors and other <br>
tooling), and no AST change, etc.<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">It's still ugly and relatively high impact on the code you markup though.</div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto">It's a bad time all round. We've moved on from expect statements. They have their place, but it's not for this.</div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
>> I think it would hurt D as a whole to<br>
>> have special stuff for such a rare thing.<br>
>><br>
><br>
> How?<br>
> And it's not 'rare'; it's 'niche'. For a microcontroller with <br>
> no branch<br>
> prediction, it's common and essential.<br>
> It's literally unworkable to write code for the platform <br>
> without this tool;<br>
> you can't have branches constantly mispredicting.<br>
<br>
It would help if your arguments would not use so much hyperbole. <br>
Obviously it is not unworkable, demonstrated by decades of <br>
microcontroller programming without it (C does not have it).</blockquote></div></div><div dir="auto"><br></div><div dir="auto">Huh? I've been writing expect statements in C for 20 years or maybe more...</div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto">Modern arch's are pipelined, and a mispredict is relatively more costly.</div><div dir="auto">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.</div><div dir="auto">There's a reason it's been recently added to C++. This situation is new.</div><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto">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 <i>by far</i> the most significant detail to take care. That's not hyperbole.</div><div dir="auto"><br></div><div dir="auto"></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
The "hurt" I meant is in maintenance of the compiler frontend <br>
which already is in quite a bad complexity state (subtle bugs <br>
existing and introduced upon almost every change). Adding yet <br>
another special case is imo a net loss.<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto">I don't see this is a special case. The grammar tweak would be no more special case than attaching attributes to other declarations.</div><div dir="auto">I reckon you're exaggerating the complexity.</div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
</blockquote></div></div></div>