On 5 January 2012 20:36, Manu <turkey...@gmail.com> wrote: > On 5 January 2012 21:41, Sean Kelly <s...@invisibleduck.org> wrote: >> >> On Jan 5, 2012, at 10:02 AM, Manu wrote: >> > >> > That said, this is just one of numerous issues myself and the OP raised. >> > I don't know why this one became the most popular for discussion... my >> > suspicion is that is because this is the easiest of my complaints to >> > dismiss >> > and shut down ;) >> >> It's also about the only language change among the issues you mentioned. >> Most of the others are QOI issues for compiler vendors. What I've been >> curious about is if you really have a need for the performance that would be >> granted by these features, or if this is more of an idealistic issue. > > > I think they are all language requests. They could be implemented by 3rd > party compilers, but these things are certainly nice to standardise in the > language, or you end up with C, which is a mess I'm trying to escape. > > Of the topics been discussed: > * vector type - I can't be expected to write a game without using the > vector hardware... I'd rather use a portable standardised type than a GDC > extension. Why the resistance? I haven't heard any good arguments against, > other than some murmurings about float[4] as the official syntax, which I > gave detailed arguments against. >
I dabbled with vector types, none of the vector builtins are hashed out to GDC because it really does require that vector be a unique type from a normal array. > * inline asm supporting pseudo regs - As an extension of using the vector > hardware, I'll need inline asm, and inline assembly without pseudo regs is > pretty useless... it's mandatory that the compiler shedule the register > allocation otherwise inline asm will most likely be an un-optimisation. If D > had pseudo regs in its inline assembler, it would make it REALLY attractive > for embedded systems programmers. > In lieu of that, I need to use opcode intrinsics instead, which I > believe GDC exposes, but again, I'm done with C and versioning (#ifdef-ing) > every compiler I intend to use. Why not standardise these things? At least > put the intrinsics in the standard lib... > This is only possible using GDC extended asm - which is really GCC asm but encapsulated in {} instead of (); > * __restrict - Not a deal breaker, but console game dev industry uses this > all the time. There are countless articles on the topic (many are private or > on console vendor forums). If this is not standardised in the language, GDC > will still expose it I'm sure, fragmenting the language. > I don't think D enforces any sort of aliasing rules, but it would be nice to turn on strict aliasing though... > * __forceinline - I'd rather have a proper keyword than using tricks like > mixins and stuff as have been discussed. The reason for this is debugging. > Code is not-inlined in debug builds, looks&feels like normal code, can still > evaluate, and step like regular code... and guarantee that it inlines > properly when optimised. This just saves time; no frills debugging. > __forceinline still won't be a guarantee though. -- Iain Buclaw *(p < e ? p++ : p) = (c & 0x0f) + '0';