On Tuesday, 5 July 2016 at 23:56:48 UTC, Walter Bright wrote:
> On 7/5/2016 2:44 PM, ketmar wrote:
>> anyway, fixing long-standing bug with `align()` being ignored on stack variables
>> will allow to use SIMD on x86.
>
> Not really. The alignment requirement has to be done by all functions, whether they use SIMD or not.

nope. it should be done only for the data that participating in SIMD. and this can be perfectly solved by fixing `align()` issues. some bit operations to adjust ESP won't hurt, if people want SIMD: SIMD will give much bigger win.

>>> 4. people wanting high performance are going to be using 64 bits anyway
>> so i'm not in a set of "people". ok.
>
> I'm curious about why you require 32 bits.

and i'm curious why everyone is so amazed by 64-bit systems. none of my software is using more than 2GB of RAM. why should i pay for something i don't need? like, all pointers are magically twice bigger. hello, cache lines, i have a present for you!

On Wednesday, 6 July 2016 at 01:27:11 UTC, ketmar wrote:
> On Tuesday, 5 July 2016 at 23:50:35 UTC, Basile B. wrote:
>>>> Major Linux distributions...
> ...
>> Are you windows Ketmar ?
>
> no. GNU/Linux here. and i don't care what shitheads from "major linux distributions" may think.

ok, bad bet but why do you insist with DMD 32 bit SIMD support ? can't you use a 64 bit linux distribution ?

On Wednesday, 6 July 2016 at 02:10:09 UTC, Basile B. wrote:
> ok, bad bet but why do you insist with DMD 32 bit SIMD support ? can't you use a 64 bit linux distribution ?

i can even dance naked on the street, no problems. but i just can't see a reason to do that.

On Wednesday, 6 July 2016 at 02:34:04 UTC, ketmar wrote:
> On Wednesday, 6 July 2016 at 02:10:09 UTC, Basile B. wrote:
>> ok, bad bet but why do you insist with DMD 32 bit SIMD support ? can't you use a 64 bit linux distribution ?
>
> i can even dance naked on the street, no problems. but i just can't see a reason to do that.

That's a bad analogy. You layer two possibilities that are unrelated in order to show that the first one is stupid. But that's the opposite, this is the analogy that's stupid, not the the proposition you refer to, because while using a 64 bit linux will help you, dancing naked in the street won't.

Eventually this kind of reasoning will impress a child or someone a bit weak but seriously you can't win when the solution is so obvious.

On Wednesday, 6 July 2016 at 03:23:18 UTC, Basile B. wrote:
> while using a 64 bit linux will help you, dancing naked in the street won't.

it will really help me to head my house, yes. so you proposing me to rebuild the world, and all my custom-built software (alot!) for... for nothing, as (i said it before) no of the apps i'm using require more than 2GB of RAM. and SIMD instructions are perfectly usable in 32-bit mode too -- with anything except DMD. so you proposing me to fuck my whole system to workarond a DMD bug/limitation. great. this is even more stupid than naked dances.

p.s. *heat. ;-)

p.p.s. and i can use SIMD with DMD built-in asm, of course. that's what i did in Follin, and it works like a charm. but, of course, the code is completely unportable -- and this is something i wanted to avoid...

On 7/5/2016 6:06 PM, deadalnix wrote:
> On Tuesday, 5 July 2016 at 23:56:48 UTC, Walter Bright wrote:
>> On 7/5/2016 2:44 PM, ketmar wrote:
>>> anyway, fixing long-standing bug with `align()` being ignored on stack variables
>>> will allow to use SIMD on x86.
>>
>> Not really. The alignment requirement has to be done by all functions, whether
>> they use SIMD or not.
>>
>
> The intel performance optimization manual have some nice trick to mix code with
> different stack alignment.
>
> You may want to check that out. Sadly, I can't find the article right now, but
> mostly it boils down to :
>  - as the stack grow down, you can mask the stack pointer at function entry to
> get it aligned.
>  - If both caller and callee both need alignment, callee can call/jump over the
> masking instructions directly into the meat of the callee.
>

The trouble with that is you lose the ability to use EBP as a general purpose register, as you'll need EBP to point to the parameters and ESP to point to the locals.

It's a complex and disruptive change to the code generator.

It's certainly doable, but in an age of priorities I suspect the time is better spent on improving 64 bit code generation.

On 7/5/2016 6:30 PM, ketmar wrote:
>> I'm curious about why you require 32 bits.
> and i'm curious why everyone is so amazed by 64-bit systems. none of my software
> is using more than 2GB of RAM. why should i pay for something i don't need?
> like, all pointers are magically twice bigger. hello, cache lines, i have a
> present for you!

I agree, 64 bits does have its drawbacks.

Apple has dropped all 32 bit support, Ubuntu is preparing to. I wonder when Windows will drop it like they did 16 bit support - they'll probably be the last to do so, as they value legacy compatibility more than anyone else.

But it's coming. We should be investing in the future with our limited resources.

On Wednesday, 6 July 2016 at 01:30:46 UTC, ketmar wrote:
> and i'm curious why everyone is so amazed by 64-bit systems. none of my software is using more than 2GB of RAM. why should i pay for something i don't need? like, all pointers are magically twice bigger. hello, cache lines, i have a present for you!

The advantage of compiling for AMD64 is that the compiler can assume a lot of extensions like the SSE bunch. If you want to distribute a binary for x86 you only have the 386 instructions. Ok, 686 is probably common enough today. For more special instructions, you could guard them and provide a fallback.

One example: To convert a floating point value to integer on 386, you need to store it to memory and load it again. Makes sense, if you floating point stuff is handled by a co-processor, but today this is completely integrated. SSE added an extra instruction to avoid the memory detour.

GCC has a switch (-mx32) to store pointers as 32bit on a 64bit system. That is probably very close to what you want.

On Wednesday, 6 July 2016 at 04:56:07 UTC, Walter Bright wrote:
>
> It's certainly doable, but in an age of priorities I suspect the time is better spent on improving 64 bit code generation.

It's not like it is a blocker for anyone, there is:
- assembly
- auto-vectorization
- LDC

Not worth your time (and the backend risk!) imho.