H1 2015 Priorities and Bare-Metal Programming

Daniel Murphy via Digitalmars-d digitalmars-d at puremagic.com
Tue Feb 3 01:56:10 PST 2015


"Walter Bright"  wrote in message news:maq10s$2avu$1 at digitalmars.com...

> A separate message with a pragmatic difficulty with your suggestion.
>
> Different compilers will have different inlining capabilities. Different 
> versions of the same compiler may behave differently. This means that 
> sometimes a user may get a compilation failure, sometimes not. It's highly 
> brittle.
>
> So enter the workaround code. Different compilers and different versions 
> will require different workaround code. Is this really reasonable for 
> users to put up with? And will they really want to be running the 
> workaround code when they upgrade the compiler and now it could have 
> inlined it?

I don't expect this to be a huge problem, because most functions marked with 
forceinline would be trivial.

eg. setREG(ubyte val) { volatileStore(cast(ubyte*)0x1234, val); }

This function only exists to give a nicer interface to the register.  If the 
compiler can't inline it, I want to know about it at compilation time rather 
than later.

Again, it's for those cases that would just be done with macros in C.  Where 
the code should always be inlined but doing it manually the source would 
lead to maintenance problems. 



More information about the Digitalmars-d mailing list