"Iain Buclaw via Digitalmars-d" wrote in message
news:mailman.4161.1420481405.9932.digitalmar...@puremagic.com...
> Do you think we can change _all_ the druntime and phobos code to just
> use
> va_arg directly? It would be nice to have it all portable like that.
Oh, yeah, do it! You have r
"Iain Buclaw via Digitalmars-d" wrote in message
news:mailman.4161.1420481405.9932.digitalmar...@puremagic.com...
>
> I think I've got a handle on this, sort of. I've moved the declaration
> of
> __va_argsave into the glue layer, and added intrinsic detection for
> va_start/va_end/va_arg (t
On 2015-01-05 00:50:55 +, Brian Schott said:
Looks like it's time to spend some more time with perf:
http://i.imgur.com/k50dFbU.png
X-axis: Meaningless (Phobos module file names)
Y-axis: Time in "hnsecs" (Lower is better)
I had to hack the ddmd code to get it compile (more "1337 h4x" were
"Daniel Murphy" wrote in message news:m8eihu$21to$1...@digitalmars.com...
I'll run some more extensive tests tomorrow, and then have a look at some
other platforms.
The problem with using a fuzz tester to verify the new varargs
implementation is I need to fix all the existing ABI bugs first.
"Tobias Pankrath" wrote in message
news:sdturuippuqoqvbuq...@forum.dlang.org...
Every type has at least a size of one byte. So a and b occupy different
stack slots due to padding. The default op== does a memcmp and compares
the padding as well.
My guess.
Haha yes, you're spot on. I was a
On Wednesday, 7 January 2015 at 13:02:20 UTC, Daniel Murphy wrote:
"Iain Buclaw via Digitalmars-d" wrote in message
news:mailman.4250.1420635158.9932.digitalmar...@puremagic.com...
No, that assert should never fail.
And yet for some reason it does.
Every type has at least a size of one by
"Iain Buclaw via Digitalmars-d" wrote in message
news:mailman.4250.1420635158.9932.digitalmar...@puremagic.com...
No, that assert should never fail.
And yet for some reason it does.
On 7 January 2015 at 12:35, Daniel Murphy via Digitalmars-d
wrote:
> "Iain Buclaw via Digitalmars-d" wrote in message
> news:mailman.4248.1420631820.9932.digitalmar...@puremagic.com...
>
>> I'd say bug in dmc.
>
>
> Yeah I'm thinking so, fun. It looks like dmc sets up the code to copy the
> stru
"Brian Schott" wrote in message
news:wyligkafbpgxzlevf...@forum.dlang.org...
@forceinline would solve all of it.
Ok, good.
It would have to be range-based and be capable of performing syntax
highlighting. My D lexer is based on lexer generator code that might
someday become std.lexer, so
"Iain Buclaw via Digitalmars-d" wrote in message
news:mailman.4248.1420631820.9932.digitalmar...@puremagic.com...
I'd say bug in dmc.
Yeah I'm thinking so, fun. It looks like dmc sets up the code to copy the
struct into the variable but never bothers emitting the loop/movsds.
What about
On 7 January 2015 at 05:27, Daniel Murphy via Digitalmars-d
wrote:
> Is there something wrong with this code or have I found a dmc bug?
>
I'd say bug in dmc.
Is there something wrong with this code or have I found a dmc bug?
#include
#include
struct S16 {
char val_0;
unsigned char val_1;
int val_2;
unsigned val_3;
long long val_4;
unsigned val_5;
};
void checkValues(int arg0, unsigned long long arg1, long long arg2, int
arg3, S1
On Tuesday, 6 January 2015 at 15:42:22 UTC, Daniel Murphy wrote:
Yes, but __va_argsave is declared in the frontend, which is
unnecessary. It was easy enough to make the glue layer reserve
the right number of bytes for varargs functions.
I agree. Walter said that he didn't manage to implement
On Tuesday, 6 January 2015 at 12:39:27 UTC, Daniel Murphy wrote:
Nice! How far would @forceinline go to getting the same
results without the ugly?
@forceinline would solve all of it.
I don't expect you to do this, but what features would ddmd's
lexer need before you could entirely replace li
"David Nadlinger" wrote in message
news:qzodhfgpknmlbjtnw...@forum.dlang.org...
I'd suggest you have a look at Posix x86_64 first before finalizing the
"easy" x86 implementation. The former comes with two extra niceties
compared to the simple "pointer to stack-allocated arguments" model:
I
On Monday, 5 January 2015 at 17:44:31 UTC, Daniel Murphy wrote:
I think I've got a handle on this, sort of. I've moved the
declaration of __va_argsave into the glue layer, and added
intrinsic detection for va_start/va_end/va_arg (the two-arg
form).
I've implemented them in the backend for wi
"Brian Schott" wrote in message
news:bhmpbqutpimjxtbcs...@forum.dlang.org...
Now with more copy-paste inlining!
http://i.imgur.com/D5IAlvl.png
I'm glad I could get this kind of speed up, but not happy with how ugly
the changes were.
Nice! How far would @forceinline go to getting the same
On Monday, 5 January 2015 at 00:50:57 UTC, Brian Schott wrote:
Looks like it's time to spend some more time with perf:
http://i.imgur.com/k50dFbU.png
X-axis: Meaningless (Phobos module file names)
Y-axis: Time in "hnsecs" (Lower is better)
I had to hack the ddmd code to get it compile (more "1
On 5 January 2015 at 17:44, Daniel Murphy via Digitalmars-d
wrote:
> "Iain Buclaw via Digitalmars-d" wrote in message
> news:mailman.4157.1420479008.9932.digitalmar...@puremagic.com...
>
>> For consistency? I would go with (c) as va_list could be anything,
>> even a struct (PPC). That and people
"Iain Buclaw via Digitalmars-d" wrote in message
news:mailman.4157.1420479008.9932.digitalmar...@puremagic.com...
For consistency? I would go with (c) as va_list could be anything,
even a struct (PPC). That and people shouldn't (*!*) be manipulating
va_list directly, though unfortunately we do
On 5 January 2015 at 13:37, Daniel Murphy via Digitalmars-d
wrote:
> "Daniel Murphy" wrote in message news:m8dv49$1cgs$1...@digitalmars.com...
>
>> And what about explicit casts?
>
>
> Oh yeah, and how does __va_argsave work, why do we need it?
>
> Looking at the druntime and phobos code, I'm not
On 5 January 2015 at 12:13, Daniel Murphy via Digitalmars-d
wrote:
> "Daniel Murphy" wrote in message news:m8dv1g$1cg4$1...@digitalmars.com...
>>
>> Druntime and phobos rely on va_list converting to void*. Should this
>> a) be allowed on platforms where va_list is a pointer
>> b) always be allow
On 5 January 2015 at 12:11, Daniel Murphy via Digitalmars-d
wrote:
> "Iain Buclaw via Digitalmars-d" wrote in message
> news:mailman.4146.1420457999.9932.digitalmar...@puremagic.com...
>
>> That is correct for user code, but not druntime C bindings.
>>
>> GDC can compile the test in 3568 thanks t
"Daniel Murphy" wrote in message news:m8dv49$1cgs$1...@digitalmars.com...
And what about explicit casts?
Oh yeah, and how does __va_argsave work, why do we need it?
Looking at the druntime and phobos code, I'm not sure which stuff is
correct, which stuff needs to have the X86_64 version del
"Iain Buclaw via Digitalmars-d" wrote in message
news:mailman.4146.1420457999.9932.digitalmar...@puremagic.com...
That is correct for user code, but not druntime C bindings.
GDC can compile the test in 3568 thanks to the GCC backend providing
the va_list struct a name (__va_list_tag).
Howeve
"Daniel Murphy" wrote in message news:m8dv1g$1cg4$1...@digitalmars.com...
Druntime and phobos rely on va_list converting to void*. Should this
a) be allowed on platforms where va_list is a pointer
b) always be allowed
c) never be allowed
???
And what about explicit casts?
On 5 January 2015 at 11:21, Daniel Murphy via Digitalmars-d
wrote:
> "Iain Buclaw via Digitalmars-d" wrote in message
> news:mailman.4143.1420452193.9932.digitalmar...@puremagic.com...
>
>> That depends on how we agree to go forward with this. From memory, we
>> each do / did things differently.
"Iain Buclaw via Digitalmars-d" wrote in message
news:mailman.4143.1420452193.9932.digitalmar...@puremagic.com...
That depends on how we agree to go forward with this. From memory, we
each do / did things differently.
I have no doubt that the way I've done it is a kludge at best, but
I'll ex
On 5 January 2015 at 09:23, Daniel Murphy via Digitalmars-d
wrote:
> "Iain Buclaw via Digitalmars-d" wrote in message
> news:mailman.4141.1420448690.9932.digitalmar...@puremagic.com...
>
>> void foo(int bar, ...)
>> {
>> va_list* va = void;
>> va_list[1] __va_argsave;
>> va = &__va_argsave;
On 2015-01-05 05:04, Brian Schott wrote:
Getting dub to turn on optimizations is easier than getting it to turn
off debugging.
dub build --build=release ?
--
/Jacob Carlborg
"Iain Buclaw via Digitalmars-d" wrote in message
news:mailman.4141.1420448690.9932.digitalmar...@puremagic.com...
void foo(int bar, ...)
{
va_list* va = void;
va_list[1] __va_argsave;
va = &__va_argsave;
...
}
The above being compiler generated by DMD.
Should that be va = &__va_arg
On 5 January 2015 at 08:28, Daniel Murphy via Digitalmars-d
wrote:
> "David Nadlinger" wrote in message
> news:qlzdmlnzlklofmlkq...@forum.dlang.org...
>
>> It is. It breaks vararg cross-platform compatibility (e.g. Linux x86 vs.
>> Linux x86_64) and GDC/LDC will never need it. It's something that
"David Nadlinger" wrote in message
news:qlzdmlnzlklofmlkq...@forum.dlang.org...
It is. It breaks vararg cross-platform compatibility (e.g. Linux x86 vs.
Linux x86_64) and GDC/LDC will never need it. It's something that we
really to be fixed sooner than later. The only reason why the current
On Monday, 5 January 2015 at 03:41:17 UTC, Daniel Murphy wrote:
Hmm, __va_argsave might be a dmd-specific hack.
It is. It breaks vararg cross-platform compatibility (e.g. Linux
x86 vs. Linux x86_64) and GDC/LDC will never need it. It's
something that we really to be fixed sooner than later. T
On Monday, 5 January 2015 at 03:46:00 UTC, Daniel Murphy wrote:
"Brian Schott" wrote in message
news:cmqleuoppesrhchnn...@forum.dlang.org...
Also, DMD didn't like the body of the halt() function.
Only if you compile with with -O and -debug together.
Getting dub to turn on optimizations is
"Brian Schott" wrote in message
news:cmqleuoppesrhchnn...@forum.dlang.org...
Also, DMD didn't like the body of the halt() function.
Only if you compile with with -O and -debug together.
"Brian Schott" wrote in message
news:erlwjgsltofsjmscp...@forum.dlang.org...
DMD 2.066.1 and LDC 0.15.1.
Ah ok, I've only tested it with master.
Most of it involved adding some ulong -> uint casts and
Looks like I forgot to test it on linux and 64-bit
https://github.com/D-Programming-La
Also, DMD didn't like the body of the halt() function.
On Monday, 5 January 2015 at 03:01:11 UTC, Daniel Murphy wrote:
"Brian Schott" wrote in message
news:phwlklufefyocyuli...@forum.dlang.org...
Looks like it's time to spend some more time with perf:
http://i.imgur.com/k50dFbU.png
Nice!
I had to hack the ddmd code to get it compile (more "13
"Brian Schott" wrote in message
news:phwlklufefyocyuli...@forum.dlang.org...
Looks like it's time to spend some more time with perf:
http://i.imgur.com/k50dFbU.png
Nice!
I had to hack the ddmd code to get it compile (more "1337 h4x" were
required to compile with LDC than with DMD), so I h
Looks like it's time to spend some more time with perf:
http://i.imgur.com/k50dFbU.png
X-axis: Meaningless (Phobos module file names)
Y-axis: Time in "hnsecs" (Lower is better)
I had to hack the ddmd code to get it compile (more "1337 h4x"
were required to compile with LDC than with DMD), so I
On Monday, 5 January 2015 at 00:50:57 UTC, Brian Schott wrote:
http://i.imgur.com/k50dFbU.png
Some notes:
1) If you use D-Scanner or DCD on a regular basis, you really
should compile it with gdc or ldc.
2) Everybody can guess which module 14 is.
42 matches
Mail list logo
