On Thursday, 21 June 2012 at 00:02:58 UTC, Walter Bright wrote:
> On 6/20/2012 4:26 AM, Bernard Helyer wrote:
>> I was sputtering with rage. Sputtering!
>
> Look Dave, I can see you're really upset about this. I honestly think you ought to sit down calmly, take a stress pill, and think things over. I know I've made some very poor decisions recently, but I can give you my complete assurance that my work will be back to normal.

Open the source repo doors, Walt.

On 20/06/12 16:37, Manu wrote:
> On 20 June 2012 17:15, Don Clugston <dac@nospam.com
> <mailto:dac@nospam.com>> wrote:
>
>     On 20/06/12 13:22, Manu wrote:
>
>         I find optimisers are very good at code simplification, assuming
>         that
>
>         you massage the code/expressions to neatly match any
>         architectural quirks.
>         I also appreciate that good x86 code is possibly the hardest
>         architecture for an optimiser to get right...
>
>
>     Optimizers improved enormously during the 80's and 90's, but the
>     rate of improvement seems to have slowed.
>
>     With x86, out-of-order execution has made it very easy to get
>     reasonably good code, and much harder to achieve perfection. Still,
>     Core i7 is much easier than Core2, since Intel removed one of the
>     most complicated bottlenecks (on core2 and earlier there is a max 3
>     reads per cycle, of registers you haven't written to in the previous
>     3 cycles).
>
>
> Yeah okay, I can easily imagine the complexity for an x86 codegen.
> RISC architectures are so much more predictable.
>
> How do you define 'perfection'? Performance as measured on what
> particular machine? :)

The theoretical limit for a particular architecture. Eg in BigInt, the most crucial functions an integer multiply in each loop iteration.
Since the machine only has one integer multiply unit, it is impossible to do better than one multiply per cycle. If you've achieved that, it's perfect.
If the processors are different enough you may also need a separate branch for different processors.

On 21 June 2012 04:06, Bernard Helyer <b.helyer@gmail.com> wrote:
> On Thursday, 21 June 2012 at 00:02:58 UTC, Walter Bright wrote:
>>
>> On 6/20/2012 4:26 AM, Bernard Helyer wrote:
>>>
>>> I was sputtering with rage. Sputtering!
>>
>>
>> Look Dave, I can see you're really upset about this. I honestly think you ought to sit down calmly, take a stress pill, and think things over. I know I've made some very poor decisions recently, but I can give you my complete assurance that my work will be back to normal.
>
>
> Open the source repo doors, Walt.
>
>

It's not pining. It's passed on. This door is no more. It has ceased to be. It's expired and gone to meet its maker. This is a late door. It's a stiff. Bereft of life, it rests in peace. If you hadn't nailed it to the perch, it would be pushing up the daisies. It's rung down the curtain and joined the choir invisible. THIS IS AN EX-DOOR.


-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';

On 20 June 2012 21:16, Alex Rønne Petersen <alex@lycus.org> wrote:
> On 20-06-2012 21:48, Joseph Rushton Wakeling wrote:
>>
>> On 20/06/12 20:35, Alex Rønne Petersen wrote:
>>>
>>> And x86 inline assembler... on ARM? I don't think I follow.
>>
>>
>> If I understand http://dlang.org/iasm.html correctly, the idea is that D should have an inline assembler for each target architecture.
>>
>> AFAICS what's desired is that you should be able to insert
>>
>> asm
>> {
>> // target-specific assembly goes here
>> }
>>
>> .... and have it accepted by _any_ D compiler. That seems to me to be an
>>
>> important part of the language in general and even more so on architectures that are suited to embedded systems. So while it may make sense to cut the inline assembly in the short term for GDC, it doesn't make sense to me for it to be a change that lasts.
>
>
> GDC currently supports x86, ARM, PowerPC, MIPS, SPARC, and possibly others. The language reference lists assembly syntax for x86. I understand that in an ideal world, we'd have standardized assembly syntaxes for all of these architectures, but somebody has to actually spec and implement them.
>
> Besides, Iain has already pointed out that the x86 syntax in the spec doesn't integrate with GCC's inline assembly support at all (which is why GDC had the glue code for it). It took around 2000 lines (if memory serves) to translate the D inline assembly to GCC inline assembly. Now imagine having to do this for every architecture ever supported.
>

More closer to 4000 lines, and the current implementation is in no state to be able to add more architechtures into the mix.


-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';