I just released a new version of DVM, 0.4.0. The only thing new in this
release in the compile command. This allows to compile DMD, druntime
and Phobos from github. Create a folder, clone DMD, druntime and Phobos
in the newly create folder, run dvm compile folder to compile
everything. The
On 06/01/2012 21:29, Jacob Carlborg wrote:
I just released a new version of DVM, 0.4.0. The only thing new in this
release in the compile command. This allows to compile DMD, druntime
and Phobos from github. Create a folder, clone DMD, druntime and Phobos
in the newly create folder, run dvm
Jacob Carlborg d...@me.com wrote in message
news:je7p3p$1pl1$1...@digitalmars.com...
I just released a new version of DVM, 0.4.0. The only thing new in this
release in the compile command. This allows to compile DMD, druntime and
Phobos from github. Create a folder, clone DMD, druntime and
Robert Clipsham rob...@octarineparrot.com wrote in message
news:je7qkg$1s8f$1...@digitalmars.com...
Would it be possible to get something like this working?
$ dvm install git-master # install everything from git master
$ dvm update git-master # update to the latest dmd/druntime/phobos
On 1/5/2012 5:42 PM, Manu wrote:
So I've been hassling about this for a while now, and Walter asked me to pitch
an email detailing a minimal implementation with some initial thoughts.
Takeaways:
1. SIMD behavior is going to be very machine specific.
2. Even trying to do something with + is
On Fri, 06 Jan 2012 07:22:55 +0100, Walter Bright
newshou...@digitalmars.com wrote:
On 1/5/2012 7:42 PM, Manu wrote:
Perhaps I misunderstand, I can't see the problem?
In the function preamble, you just align it... something like:
mov reg, esp ; take a backup of the stack pointer
and
On Fri, Jan 6, 2012 at 2:43 AM, Walter Bright
newshou...@digitalmars.com wrote:
On 1/5/2012 5:42 PM, Manu wrote:
So I've been hassling about this for a while now, and Walter asked me to
pitch
an email detailing a minimal implementation with some initial thoughts.
Takeaways:
1. SIMD
On Mon, 02 Jan 2012 20:20:55 +0100, Martin Nowak d...@dawgfoto.de wrote:
I think that I'll defer the support for runtime loading of shared
library (plugins)
in favor of getting linked shared library support done now.
There are several issues that require more thoughts.
- Per-thread
Would this tie SIMD support directly to x86/x86_64, or would it
possible to also support NEON on ARM (also 128 bit SIMD, see
http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0409g/index.html
) ?
(Obviously not for DMD, but if the syntax wasn't directly tied to
x86/64, GDC and
a Wrote:
Would this tie SIMD support directly to x86/x86_64, or would it
possible to also support NEON on ARM (also 128 bit SIMD, see
http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0409g/index.html
) ?
(Obviously not for DMD, but if the syntax wasn't directly tied to
Walter Bright Wrote:
which provides two functions:
__v128 simdop(operator, __v128 op1);
__v128 simdop(operator, __v128 op1, __v128 op2);
You would also need functions that take an immediate too to support
instructions such as shufps.
One caveat is it is typeless; a __v128 could
Hi,
just bringing into the discussion how Mono does it.
http://tirania.org/blog/archive/2008/Nov-03.html
Also have a look at pages 44-53 from the presentation slides.
--
Paulo
Walter Bright wrote in message news:je6c7j$2ct0$1...@digitalmars.com...
On 1/5/2012 5:42 PM, Manu wrote:
So I've
On Friday, 6 January 2012 at 03:17:55 UTC, Walter Bright wrote:
Something about the way you are posting is breaking the
threading of these message threads.
This is because the mailing list gateway assigns new Message IDs
to posts forwarded from the mailing list to the newsgroup.
Mailing list
On 6 January 2012 10:43, Walter Bright newshou...@digitalmars.com wrote:
On 1/5/2012 5:42 PM, Manu wrote:
So I've been hassling about this for a while now, and Walter asked me to
pitch
an email detailing a minimal implementation with some initial thoughts.
Takeaways:
1. SIMD behavior is
Walter:
One caveat is it is typeless; a __v128 could be used as 4 packed ints or 2
packed doubles. One problem with making it typed is it'll add 10 more types
to
the base compiler, instead of one. Maybe we should just bite the bullet and
do
the types:
What are the disadvantages of
On Fri, 06 Jan 2012 09:43:30 +0100, Walter Bright
newshou...@digitalmars.com wrote:
On 1/5/2012 5:42 PM, Manu wrote:
So I've been hassling about this for a while now, and Walter asked me
to pitch
an email detailing a minimal implementation with some initial thoughts.
Takeaways:
1. SIMD
On 6 January 2012 14:54, bearophile bearophileh...@lycos.com wrote:
Walter:
One caveat is it is typeless; a __v128 could be used as 4 packed ints or
2
packed doubles. One problem with making it typed is it'll add 10 more
types to
the base compiler, instead of one. Maybe we should just
On Fri, 06 Jan 2012 13:56:58 +0100, Martin Nowak d...@dawgfoto.de wrote:
On Fri, 06 Jan 2012 09:43:30 +0100, Walter Bright
newshou...@digitalmars.com wrote:
On 1/5/2012 5:42 PM, Manu wrote:
So I've been hassling about this for a while now, and Walter asked me
to pitch
an email detailing
On 6 January 2012 12:16, a a...@a.com wrote:
Walter Bright Wrote:
which provides two functions:
__v128 simdop(operator, __v128 op1);
__v128 simdop(operator, __v128 op1, __v128 op2);
You would also need functions that take an immediate too to support
instructions such as
On 6 January 2012 14:56, Martin Nowak d...@dawgfoto.de wrote:
On Fri, 06 Jan 2012 09:43:30 +0100, Walter Bright
newshou...@digitalmars.com wrote:
One caveat is it is typeless; a __v128 could be used as 4 packed ints or
2 packed doubles. One problem with making it typed is it'll add 10 more
On 2012-01-05 14:59, Vladimir Panteleev wrote:
On Thursday, 5 January 2012 at 13:40:20 UTC, Jacob Carlborg wrote:
The pragma is a standard way to expose non-standard features. You just
need to wrap it in version statements because the compiler will
otherwise complain about unrecognized pragmas.
On Thursday, 5 January 2012 at 23:08:14 UTC, Vladimir Panteleev
wrote:
On Thursday, 5 January 2012 at 22:53:10 UTC, Stewart Gordon
wrote:
Or is it really not an online compiler, but rather an online
interface to a collection of compilers that the author has on
his computer?
Um... yes.
What
On 2012-01-05 15:04, Robert Clipsham wrote:
On 05/01/2012 13:41, Jacob Carlborg wrote:
On 2012-01-05 11:00, Nick Sabalausky wrote:
Joshua Reuschyos...@arkandos.de wrote in message
news:je26q8$19oo$1...@digitalmars.com...
OT: Why does dmd ignore the pragma(lib, ...) in the etc.c.curl module
On 6 January 2012 08:22, Walter Bright newshou...@digitalmars.com wrote:
On 1/5/2012 7:42 PM, Manu wrote:
Perhaps I misunderstand, I can't see the problem?
In the function preamble, you just align it... something like:
mov reg, esp ; take a backup of the stack pointer
and esp, -16 ;
Manu:
To make it perform float4 math, or double2 match, you either write the
pseudo assembly you want directly, but more realistically, you use the
__float4 type supplied in the standard library, which will already
associate all the float4 related functionality, and try and map it across
Manu:
I can paste some disassemblies if you don't have VC...
Pasting it is useful for all other people reading this thread too, like me.
Bye,
bearophile
I see. While you design, you need to think about the other features of D :-)
Is it possible to mix CPU SIMD with D vector ops?
__float4[10] a, b, c;
c[] = a[] + b[];
And generally, if the D compiler receives just D vector ops, what's a good way
for the compiler to map them efficiently
I am planning doing a bit more work on the SCons support for D. In
terms of strategy the following question arises: Are the object files
produced by DMD, GDC and LDC mutually compatible? i.e. can some sources
be compiled with DMD, some with GDC, and some with LDC and all the
object files linked
On 6 January 2012 16:06, bearophile bearophileh...@lycos.com wrote:
Manu:
To make it perform float4 math, or double2 match, you either write the
pseudo assembly you want directly, but more realistically, you use the
__float4 type supplied in the standard library, which will already
On Fri, 2012-01-06 at 16:35 +0200, Manu wrote:
[...]
I don't see any issue with this. An array of vectors makes perfect sense,
and I see no reason why arrays/slices/etc of hardware vectors should be any
sort of problem.
This particular expression should be just as efficient as if it were an
From what I see in HPC conferences papers and webcasts, I think it might be
already too late for D
in those scenarios.
Russel Winder wrote in message
news:mailman.107.1325862128.16222.digitalmar...@puremagic.com...
On Fri, 2012-01-06 at 16:35 +0200, Manu wrote:
[...]
Currently GPGPU is
On 6 January 2012 16:12, bearophile bearophileh...@lycos.com wrote:
I see. While you design, you need to think about the other features of D
:-) Is it possible to mix CPU SIMD with D vector ops?
__float4[10] a, b, c;
c[] = a[] + b[];
And generally, if the D compiler receives just D
On Fri, 2012-01-06 at 16:09 +0100, Paulo Pinto wrote:
From what I see in HPC conferences papers and webcasts, I think it might be
already too late for D
in those scenarios.
Indeed, for core HPC that is true: if you aren't using Fortran, C, C++,
and Python you are not in the game. The point
On 6 January 2012 17:01, Russel Winder rus...@russel.org.uk wrote:
On Fri, 2012-01-06 at 16:35 +0200, Manu wrote:
[...]
I don't see any issue with this. An array of vectors makes perfect sense,
and I see no reason why arrays/slices/etc of hardware vectors should be
any
sort of problem.
Please don't start a flame war on this, I am just expressing an opinion.
I think that for heterougenous computing we are better of with a language
that supports functional programming concepts.
From what I have seen in papers, many imperative languages have the issue
that they are too tied to
Someone wanted the 'in' operator to work for array literals on IRC.
This has been discussed before but ultimately rejected. Still, there
are ways to achieve similar syntax via some cool D tricks. Here's
mine:
module test;
import std.algorithm;
import std.stdio;
import std.range;
import std.conv;
That Cuda is used more is probably true, OpenCL is fugly C and
no fun.
Microsoft's upcoming C++ AMP looks interesting as it lets you
write GPU and CPU code in C++. The spec is open so hopefully it
becomes common to implement it in other C++ compilers.
SSE intrinsics in C++ are pretty
No. Each has a separate runtime, etc.
Sent from my iPhone
On Jan 6, 2012, at 6:29 AM, Russel Winder rus...@russel.org.uk wrote:
I am planning doing a bit more work on the SCons support for D. In
terms of strategy the following question arises: Are the object files
produced by DMD, GDC and
On Fri, 2012-01-06 at 09:30 -0800, Sean Kelly wrote:
No. Each has a separate runtime, etc.
OK, thanks.
I had sort of been hoping that because DMD and GDC can both compile to
object code that can be linked with GCC that there might be a hope of
interworking. But it seems that the link-time
From an ABI perspective, I know GDC used to not pass the first function
argument in EAX on x32 (ie. the calling convention for extern (C) and extern
(D) were identical). I imagine this is still true, but one of the GDC folks
would have to say for sure. The goal however is certainly to make
This whole area we have got to fix or .dll/.so support is fairly meaningless.
The compilers output need to be
interoperable.
On 1/6/2012 10:05 AM, Sean Kelly wrote:
From an ABI perspective, I know GDC used to not pass the first function
argument in EAX on x32 (ie. the calling convention for
On Fri, 06 Jan 2012 14:44:53 +0100, Manu turkey...@gmail.com wrote:
On 6 January 2012 14:56, Martin Nowak d...@dawgfoto.de wrote:
On Fri, 06 Jan 2012 09:43:30 +0100, Walter Bright
newshou...@digitalmars.com wrote:
One caveat is it is typeless; a __v128 could be used as 4 packed ints
or
2
On 1/6/2012 12:43 AM, Walter Bright wrote:
Declare one new basic type:
__v128
which represents the 16 byte aligned 128 bit vector type. The only operations
defined to work on it would be
construction and assignment. The __ prefix signals that it is non-portable.
Then, have:
Okay, so I was trying to link to a C lib, and I realised... DMD doesn't
support/produce VS compatible libs.
I should have realised this sooner, noting the cv debuginfo.
So like... WTF?
How am I supposed to use DMD in Windows in anything other than trivial,
self-contained programs?
VisualC is the
2012/1/6 Manu turkey...@gmail.com:
Okay, so I was trying to link to a C lib, and I realised... DMD doesn't
support/produce VS compatible libs.
I should have realised this sooner, noting the cv debuginfo.
So like... WTF?
How am I supposed to use DMD in Windows in anything other than trivial,
On 1/6/2012 3:32 AM, Vladimir Panteleev wrote:
On Friday, 6 January 2012 at 03:17:55 UTC, Walter Bright wrote:
Something about the way you are posting is breaking the threading of these
message threads.
This is because the mailing list gateway assigns new Message IDs to posts
forwarded from
On 1/6/2012 6:05 AM, Manu wrote:
On 6 January 2012 08:22, Walter Bright newshou...@digitalmars.com
mailto:newshou...@digitalmars.com wrote:
On 1/5/2012 7:42 PM, Manu wrote:
Perhaps I misunderstand, I can't see the problem?
In the function preamble, you just align it...
Am 06.01.2012, 19:27 Uhr, schrieb Manu turkey...@gmail.com:
Okay, so I was trying to link to a C lib, and I realised... DMD doesn't
support/produce VS compatible libs.
I should have realised this sooner, noting the cv debuginfo.
So like... WTF?
Welcome to the jungle ^^
Your options are:
1)
On 6 January 2012 20:17, Martin Nowak d...@dawgfoto.de wrote:
There is another benefit.
Consider the following:
__vec128 addps(__vec128 a, __vec128 b) pure
{
__vec128 res = a;
if (__ctfe)
{
foreach(i; 0 .. 4)
res[i] += b[i];
}
else
{
asm
On 6 January 2012 20:25, Brad Roberts bra...@puremagic.com wrote:
How is making __v128 a builtin type better than defining it as:
align(16) struct __v128
{
ubyte[16] data;
}
Where in that code is the compiler informed that your structure should
occupy a SIMD registers, and apply SIMD
On 6 January 2012 20:53, Walter Bright newshou...@digitalmars.com wrote:
On 1/6/2012 6:05 AM, Manu wrote:
On 6 January 2012 08:22, Walter Bright newshou...@digitalmars.com
mailto:newshound2@**digitalmars.com newshou...@digitalmars.com
wrote:
On 1/5/2012 7:42 PM, Manu wrote:
On 1/6/2012 7:36 AM, Russel Winder wrote:
It just strikes me as an opportunity to get D front and centre by having
it provide a better development experience for these heterogeneous
systems that are coming.
At the moment, I have no idea what such support might look like :-(
There's a COFF 2 OMF tool somewhere on digitalmars.com. Don't know how
good it is though, and can't say anything about reverse conversion.
There is indeed a coff2omf tool for static libs and here's the funny
thing: you have to pay for it :D
Like it wasn't enough to torture people with
Manu turkey...@gmail.com wrote in message
news:mailman.118.1325874486.16222.digitalmar...@puremagic.com...
Okay, so I was trying to link to a C lib, and I realised... DMD doesn't
support/produce VS compatible libs.
I should have realised this sooner, noting the cv debuginfo.
So like... WTF?
On 1/6/2012 3:32 AM, Vladimir Panteleev wrote:
On Friday, 6 January 2012 at 03:17:55 UTC, Walter Bright wrote:
Something about the way you are posting is breaking the threading of these
message threads.
This is because the mailing list gateway assigns new Message IDs to posts
forwarded
On 1/6/2012 10:25 AM, Brad Roberts wrote:
How is making __v128 a builtin type better than defining it as:
align(16) struct __v128
{
ubyte[16] data;
}
Then the back end knows it should be mapped onto the XMM registers rather than
the usual arithmetic set.
On 1/6/2012 11:06 AM, Manu wrote:
On 6 January 2012 20:25, Brad Roberts bra...@puremagic.com
mailto:bra...@puremagic.com wrote:
How is making __v128 a builtin type better than defining it as:
align(16) struct __v128
{
ubyte[16] data;
}
Where in that code is
2012/1/6 Trass3r u...@known.com:
There is indeed a coff2omf tool for static libs and here's the funny thing:
you have to pay for it :D
Didn't notice it's from a non-free package.
The problem: On windows, DMD uses the Optlink linker. Optlink only
supports OMF right now (OMF used to be commonly used by Borland, IIRC).
Optlink was written entirely in asm so changing it is difficult. But
Walter has been,
piece-by-piece, porting it to C (and then he'll port it to D).
I
On 6 January 2012 21:06, Nick Sabalausky a@a.a wrote:
Yea, OMF is actually #1 PITA on Windows right now, unfortunately.
The problem: On windows, DMD uses the Optlink linker. Optlink only supports
OMF right now (OMF used to be commonly used by Borland, IIRC). Optlink was
written entirely in
On Friday, 6 January 2012 at 19:20:35 UTC, Manu wrote:
The link must
surely be the simplest+easiest of those 3 jobs...?
The painful part is more getting dmd to output coff than
writing a linker (can always use a third party linker anyway).
Adding coff support is a bit of a mess and super
On 1/6/2012 5:44 AM, Manu wrote:
The type safety you're imagining here might actually be annoying when working
with the raw type and opcodes..
Consider this common situation and the code that will be built around it:
__v128 vec = { floatX, floatY, floatZ, unsigned int packedColour ); // pack
On 1/6/2012 6:29 AM, Russel Winder wrote:
I am planning doing a bit more work on the SCons support for D. In
terms of strategy the following question arises: Are the object files
produced by DMD, GDC and LDC mutually compatible? i.e. can some sources
be compiled with DMD, some with GDC, and
On 1/6/2012 10:27 AM, Manu wrote:
I was hoping to start a project using D as a front end language interacting with
my C/C++ engine lib... but I can't.
... and now that I think if it... how do ANY programs built with DMD actually
work? .. How does it link to system32.lib, user32.lib, etc?
With
On 1/6/2012 8:39 AM, Andrej Mitrovic wrote:
Works at CTFE too! Note that I've had to use .dup to assign from stack
to heap, this is only because I get an ICE with the following code:
http://www.ideone.com/SIfLP
The ICE is: Internal error: ..\ztc\cgcs.c 354
Please post to bugzilla!
On Jan 5, 2012, at 3:56 PM, Walter Bright wrote:
On 1/5/2012 2:57 PM, Sean Kelly wrote:
For the record, some compilers do optimize across asm blocks. It's simply
DMD/DMC that doesn't. Though the lack of volatile makes doing this unsafe
in D as a general rule.
dmd does keep track of
- Link with Unilink instead of DMD/Optlink.
Why not use this instead of Optlink if it works?
I'll check it out... though VisualD doesn't support this.
Cause its status is.. nebulous.
Closed-source, no homepage, just an ftp.
You have no guarantee it doesn't get abandoned one day.
Also what if
On 1/6/2012 11:08 AM, Manu wrote:
I think we should take this conversation to IRC, or a separate thread?
I'll generate some examples from VC for you in various situations. If you can
write me a short list of trouble cases as you see them, I'll make sure to
address them specifically...
Have you
Am 06.01.2012, 20:26 Uhr, schrieb Walter Bright
newshou...@digitalmars.com:
Long term, I hope to get a better solution, but this is where we're at
at the moment.
What's the current state of the plan?
Can we hope for a switch to COFF?
The ICE is: Internal error: ..\ztc\cgcs.c 354
Please post to bugzilla!
http://d.puremagic.com/issues/show_bug.cgi?id=4414
On 6 January 2012 21:21, Walter Bright newshou...@digitalmars.com wrote:
On 1/6/2012 5:44 AM, Manu wrote:
The type safety you're imagining here might actually be annoying when
working
with the raw type and opcodes..
Consider this common situation and the code that will be built around it:
On 6 January 2012 21:34, Walter Bright newshou...@digitalmars.com wrote:
On 1/6/2012 11:08 AM, Manu wrote:
I think we should take this conversation to IRC, or a separate thread?
I'll generate some examples from VC for you in various situations. If you
can
write me a short list of trouble
On Fri, 06 Jan 2012 10:27:58 -0800, Manu turkey...@gmail.com wrote:
Okay, so I was trying to link to a C lib, and I realised... DMD doesn't
support/produce VS compatible libs.
I should have realised this sooner, noting the cv debuginfo.
So like... WTF?
How am I supposed to use DMD in Windows
On Friday, 6 January 2012 at 20:03:01 UTC, Adam Wilson wrote:
On Fri, 06 Jan 2012 10:27:58 -0800, Manu turkey...@gmail.com
wrote:
Okay, so I was trying to link to a C lib, and I realised...
DMD doesn't
support/produce VS compatible libs.
I should have realised this sooner, noting the cv
Trass3r u...@known.com wrote in message news:op.v7ofwpwh3ncmek@enigma...
The problem: On windows, DMD uses the Optlink linker. Optlink only
supports OMF right now (OMF used to be commonly used by Borland, IIRC).
Optlink was written entirely in asm so changing it is difficult. But
Walter has
On 1/6/2012 11:53 AM, Manu wrote:
... this sounds bad. Shall I start another thread? ;)
So you're saying it's impossible to align a stack based buffer to, say, 128
bytes... ?
No, it's not impossible. Here's what you can do now:
char[128+127] buf;
char* pbuf = cast(char*)(((size_t)buf.ptr +
On 06/01/2012 13:58, Jacob Carlborg wrote:
The only time pragma(lib) works is when the file it's in is provided on
the command line. rdmd can work around this as it invokes dmd twice,
there's not a lot that can be done otherwise though.
You mean it doesn't work for .di files, I'm aware of
Manu turkey...@gmail.com wrote in message
news:mailman.126.1325877634.16222.digitalmar...@puremagic.com...
Lame. Surely Optlink is not the only linker in the world...?
I'm also surprised that someone capable of writing a compiler and
optimiser
for a complex language isn't capable of writing
Is should be possible to use debug info of a library to generate D or
other language bindings. Current approaches are SWIG, htod and/or manual
coding. The first two do not always work as expected (try using them to
make OpenCV bindings) as parser-based converters do not always support
all
On Fri, 6 Jan 2012, Walter Bright wrote:
On 1/6/2012 11:16 AM, Brad Roberts wrote:
However, a counter example, it'd be a lot easier to write a memcpy routine
that uses them
without having to resort to asm code under this theoretical model.
I would seriously argue that individuals not
Adam Wilson flybo...@gmail.com wrote in message
news:op.v7ohzbof707...@apollo.hra.local...
All DMD needs to do is output the COFF files, any number of linkers
available on Windows can handle it from there. It doesn't have to replace
OMF and it doesn't even have to be the default option, but
On 1/6/2012 11:41 AM, Manu wrote:
On 6 January 2012 21:21, Walter Bright newshou...@digitalmars.com
mailto:newshou...@digitalmars.com wrote:
On 1/6/2012 5:44 AM, Manu wrote:
The type safety you're imagining here might actually be annoying when
working
with the raw
Robert Clipsham rob...@octarineparrot.com wrote in message
news:je7lcu$1ggl$1...@digitalmars.com...
On 06/01/2012 13:58, Jacob Carlborg wrote:
The only time pragma(lib) works is when the file it's in is provided on
the command line. rdmd can work around this as it invokes dmd twice,
there's
On Fri, 06 Jan 2012 20:00:15 +0100, Manu turkey...@gmail.com wrote:
On 6 January 2012 20:17, Martin Nowak d...@dawgfoto.de wrote:
There is another benefit.
Consider the following:
__vec128 addps(__vec128 a, __vec128 b) pure
{
__vec128 res = a;
if (__ctfe)
{
foreach(i; 0 ..
On 6 January 2012 21:21, Walter Bright newshou...@digitalmars.com wrote:
1. the language does typechecking, for example, trying to add a vector of
4 floats to 16 bytes would be (and should be) an error.
I want to sell you on the 'primitive SIMD regs are truly typeless' point.
(which I thought
Trass3r wrote:
2) use GDC, then you also get 64Bit:
wait... I was under the impression GDC and LDC can't build 64bit
apps for Windows. Or are you talking about the compiler
executing/linking in 64bit?
Manu wrote:
- Use LDC or GDC instead of DMD. I think those work with COFF.
VisualD
On Fri, 06 Jan 2012 21:16:40 +0100, Walter Bright
newshou...@digitalmars.com wrote:
On 1/6/2012 11:53 AM, Manu wrote:
... this sounds bad. Shall I start another thread? ;)
So you're saying it's impossible to align a stack based buffer to, say,
128
bytes... ?
No, it's not impossible.
On 06/01/2012 20:35, Nick Sabalausky wrote:
Did you mean that last line to be dmd a.obj b.obj?
Uuurrr, oops. Yes I did, sorry about that.
--
Robert
http://octarineparrot.com/
What you will get is completely platform-dependent.
The only proper solution is using something like clang to write a
C++-D converter.
First only headers, later source code.
On Friday, 6 January 2012 at 20:45:11 UTC, F i L wrote:
wait... I was under the impression GDC and LDC can't build
64bit apps for Windows.
I thought so. Haven't tried it though cause I'm on Linux now.
I recommend using Mono-D for D development
DDT is also shaping up nicely.
On 01/01/2012 04:02 PM, Steve Teale wrote:
On Sat, 31 Dec 2011 20:28:43 -0800, bls wrote:
Not yet available. In case that Steve Teale (and he did a dammed
good Job, as well as Piotr) will add std.database this will not change
the situation significantly. 'Cause std.database will contain
On 01/06/12 20:53, Manu wrote:
What about GCC? Will/does it support arbitrary alignment?
For sane arbitrary values (ie powers of two) it looks like this:
import std.stdio;
struct S { align(65536) ubyte[64] bs; alias bs this; }
pragma(attribute, noinline) void
Vladimir Panteleev wrote:
On Monday, 26 December 2011 at 17:37:17 UTC, Piotr Szturmaj wrote:
Yes. Here are the results: http://pastebin.com/rD8kiaQy. This is
observed only with Windows DMD.
I'd be more interested in seeing the code.
Sorry for late answer. For memcpy cases code is the same
On 6 January 2012 03:17, Walter Bright newshou...@digitalmars.com wrote:
Something about the way you are posting is breaking the threading of these
message threads.
I think it may have just been that one off post?
--
Iain Buclaw
*(p e ? p++ : p) = (c 0x0f) + '0';
On 1/6/12 1:11 PM, Walter Bright wrote:
On 1/6/2012 10:25 AM, Brad Roberts wrote:
How is making __v128 a builtin type better than defining it as:
align(16) struct __v128
{
ubyte[16] data;
}
Then the back end knows it should be mapped onto the XMM registers
rather than the usual arithmetic
Robert Clipsham rob...@octarineparrot.com wrote in message
news:je7mss$1j23$1...@digitalmars.com...
On 06/01/2012 20:35, Nick Sabalausky wrote:
Did you mean that last line to be dmd a.obj b.obj?
Uuurrr, oops. Yes I did, sorry about that.
I see. Now it makes more sense :)
On 6 January 2012 22:36, Walter Bright newshou...@digitalmars.com wrote:
To me, the advantage of making the SIMD types typed are:
1. the language does typechecking, for example, trying to add a vector
of 4
floats to 16 bytes would be (and should be) an error.
The language WILL do
On 6 January 2012 22:40, Martin Nowak d...@dawgfoto.de wrote:
On Fri, 06 Jan 2012 20:00:15 +0100, Manu turkey...@gmail.com wrote:
On 6 January 2012 20:17, Martin Nowak d...@dawgfoto.de wrote:
There is another benefit.
Consider the following:
__vec128 addps(__vec128 a, __vec128 b) pure
On 01/06/2012 12:34 PM, Piotr Szturmaj wrote:
Is should be possible to use debug info of a library to generate D or
other language bindings. Current approaches are SWIG, htod and/or manual
coding. The first two do not always work as expected (try using them to
make OpenCV bindings) as
On 6 January 2012 23:23, Andrei Alexandrescu
seewebsiteforem...@erdani.orgwrote:
On 1/6/12 1:11 PM, Walter Bright wrote:
On 1/6/2012 10:25 AM, Brad Roberts wrote:
How is making __v128 a builtin type better than defining it as:
align(16) struct __v128
{
ubyte[16] data;
}
Then the back
1 - 100 of 189 matches
Mail list logo
