On 7/12/17 9:20 PM, H. S. Teoh via Digitalmars-d wrote:
On Thu, Jul 13, 2017 at 01:23:53AM +, Stefan Koch via Digitalmars-d wrote:
On Wednesday, 12 July 2017 at 21:05:28 UTC, watcher wrote:
stop advertising yourself and polluting this thread.
seek help - no down-payments in Germany!!
I
On Thu, Jul 13, 2017 at 01:23:53AM +, Stefan Koch via Digitalmars-d wrote:
> On Wednesday, 12 July 2017 at 21:05:28 UTC, watcher wrote:
> >
> > stop advertising yourself and polluting this thread.
> > seek help - no down-payments in Germany!!
>
> I am not sure what you mean ...
> I assume
On Wednesday, 12 July 2017 at 21:05:28 UTC, watcher wrote:
stop advertising yourself and polluting this thread.
seek help - no down-payments in Germany!!
I am not sure what you mean ...
I assume it's a joke ?
If you are indeed offering help, you can reproduce this by
checking out
On Wednesday, 12 July 2017 at 18:57:12 UTC, Stefan Koch wrote:
On Thursday, 16 February 2017 at 21:05:51 UTC, Stefan Koch
wrote:
[ ... ]
Another ABI issue just pooped on my Wednesday.
this time it manifests while doing concatenation inside a
template
the test failing is
On Thursday, 16 February 2017 at 21:05:51 UTC, Stefan Koch wrote:
[ ... ]
Another ABI issue just pooped on my Wednesday.
this time it manifests while doing concatenation inside a template
the test failing is (test/runnable/template8.d)
This is again hard to debug because I have to piece
On Wednesday, 12 July 2017 at 09:57:21 UTC, Martin Tschierschke
wrote:
On Wednesday, 12 July 2017 at 07:58:30 UTC, Stefan Koch wrote:
On Thursday, 16 February 2017 at 21:05:51 UTC, Stefan Koch
wrote:
[ ... ]
long story short:
This is now fixed.
and
ABI bugs are HELL!
Cheers,
Stefan
As being
On Wednesday, 12 July 2017 at 09:46:39 UTC, Kagamin wrote:
On Wednesday, 12 July 2017 at 07:58:30 UTC, Stefan Koch wrote:
Whereas A struct is always stored __packed__ and aligned to 4
byte boundaries
struct S // size: 20
{
ubyte m1; // offset: 0
ulong m2; // offset: 4
ubyte m3; //
On Wednesday, 12 July 2017 at 07:58:30 UTC, Stefan Koch wrote:
On Thursday, 16 February 2017 at 21:05:51 UTC, Stefan Koch
wrote:
[ ... ]
long story short:
This is now fixed.
and
ABI bugs are HELL!
Cheers,
Stefan
As being a newbie, could you please point to a post describing
what you are
On Wednesday, 12 July 2017 at 07:58:30 UTC, Stefan Koch wrote:
Whereas A struct is always stored __packed__ and aligned to 4
byte boundaries
struct S // size: 20
{
ubyte m1; // offset: 0
ulong m2; // offset: 4
ubyte m3; // offset: 12
ubyte m4; // offset: 16
}
Do you plan to keep it
On Thursday, 16 February 2017 at 21:05:51 UTC, Stefan Koch wrote:
[ ... ]
Hey Guys I just fixed an ABI issue concerning slices and structs.
This issue took 2.5 weeks to find and fix.
So let me describe what was going on.
As you may know newCTFE defines it's own ABI (since it is a
platform
On Thursday, 16 February 2017 at 21:05:51 UTC, Stefan Koch wrote:
[ ... ]
Hi Guys,
It's been a while since my last post.
I have now prepared the interpreter to support
float <=> double casts
as well as float <=> long
double <=> long
(int*) <=> (float*) // reinterpret
(long*) <=> (double*)
On Monday, 3 July 2017 at 06:15:44 UTC, Stefan Koch wrote:
On Thursday, 16 February 2017 at 21:05:51 UTC, Stefan Koch
wrote:
[ ... ]
This code works now as well ;)
int maxFloat()
{
float prev = 1;
foreach(int i; 0 .. int.max)
{
if (i == prev++)
return i;
}
return int.max;
On Thursday, 16 February 2017 at 21:05:51 UTC, Stefan Koch wrote:
[ ... ]
Hi Guys,
I am very pleased indeed about the following code now running in
ctfe.
int maxFloat()
{
float prev = 0;
float fOne = 1;
foreach(int i; 1 .. int.max)
{
if (i == prev)
return i-1;
else
On Thursday, 16 February 2017 at 21:05:51 UTC, Stefan Koch wrote:
[ ... ]
I ran in trouble with floating point.
This will probably take a week.
The debugger will take probably a month (without gui).
On 6/29/17 4:24 AM, Stefan Koch wrote:
On Thursday, 16 February 2017 at 21:05:51 UTC, Stefan Koch wrote:
[ ... ]
I just "discovered" a bug in my debugging system.
Which caused me to debug the wrong function for about 5 hours.
Since I really could not see why the codegen would produce such
On Thursday, 16 February 2017 at 21:05:51 UTC, Stefan Koch wrote:
[ ... ]
I just "discovered" a bug in my debugging system.
Which caused me to debug the wrong function for about 5 hours.
Since I really could not see why the codegen would produce such
vastly different code.
(Almost as if it
On Wed, Jun 28, 2017 at 04:19:02PM +, Stefan Koch via Digitalmars-d wrote:
> On Thursday, 16 February 2017 at 21:05:51 UTC, Stefan Koch wrote:
> > [ ... ]
>
> Hi There,
>
> I just wrote the first parts of the ctfe debugger.
> Ctfe-Breakpoints are working :)
>
> It looks like we will be able
On Thursday, 16 February 2017 at 21:05:51 UTC, Stefan Koch wrote:
[ ... ]
Hi There,
I just wrote the first parts of the ctfe debugger.
Ctfe-Breakpoints are working :)
It looks like we will be able to have greatly enhanced debugging
experience soon.
(okay soonish ... since there are still a
On Thursday, 16 February 2017 at 21:05:51 UTC, Stefan Koch wrote:
[ ... ]
I finally came around and implemented 64bit as a hacky extension
to the interpreter.
ulong[5] testArrayAssignL()
{
typeof(return) arr = 12;
arr[3] = 4;
arr[0] = 1;
return arr;
}
static immutable arrL
On Thursday, 16 February 2017 at 21:05:51 UTC, Stefan Koch wrote:
[ ... ]
I just figured out howto fix the defaultArg situation.
We just have to check at or slightly before we emit the Call
instruction,
if we have enough arguments for the function.
If we don't we pull the missing ones from
On Tuesday, 20 June 2017 at 19:37:47 UTC, David Nadlinger wrote:
But how much of the std.math code are you actually executing
with newCTFE? What I meant is that if the std.math{,special}
implementations of the various mathematical functions work,
there shouldn't be any egregious issues. I'm
On Tuesday, 20 June 2017 at 19:01:06 UTC, Stefan Koch wrote:
On Tuesday, 20 June 2017 at 18:58:36 UTC, David Nadlinger wrote:
On Tuesday, 20 June 2017 at 17:35:28 UTC, Stefan Koch wrote:
Hit me with brittle numeric code please!
[…]
Unfortunately this also broke the phobos unitttests since now
On Tuesday, 20 June 2017 at 17:35:28 UTC, Stefan Koch wrote:
At the same time 64bit integer support was expanded.
Such that we can now return long and ulong values.
Unfortunately this also broke the phobos unitttests since now
more of is attempted to be evaluated.
The reason this broke was
On Tuesday, 20 June 2017 at 18:58:36 UTC, David Nadlinger wrote:
On Tuesday, 20 June 2017 at 17:35:28 UTC, Stefan Koch wrote:
Hit me with brittle numeric code please!
[…]
Unfortunately this also broke the phobos unitttests since now
more of is attempted to be evaluated.
Just making sure
On Tuesday, 20 June 2017 at 17:35:28 UTC, Stefan Koch wrote:
Hit me with brittle numeric code please!
[…]
Unfortunately this also broke the phobos unitttests since now
more of is attempted to be evaluated.
Just making sure that the Phobos unit tests pass at compile time
(with 64 bit reals,
On Tuesday, 20 June 2017 at 12:07:00 UTC, Stefan Koch wrote:
On Thursday, 16 February 2017 at 21:05:51 UTC, Stefan Koch
wrote:
[ ... ]
limited Support for 32bit floating point ops [+, -, *, /, %]
has just landed in newCTFE.
float fmadd(float a, float b, float c)
{
return b + a * c;
}
On Tue, Jun 20, 2017 at 12:07:00PM +, Stefan Koch via Digitalmars-d wrote:
> On Thursday, 16 February 2017 at 21:05:51 UTC, Stefan Koch wrote:
> > [ ... ]
>
> limited Support for 32bit floating point ops [+, -, *, /, %] has just
> landed in newCTFE.
Awesome!
> float fmadd(float a,
On Tuesday, 20 June 2017 at 12:07:00 UTC, Stefan Koch wrote:
limited Support for 32bit floating point ops [+, -, *, /, %]
has just landed in newCTFE.
Nice!
On Tuesday, 20 June 2017 at 12:07:00 UTC, Stefan Koch wrote:
On Thursday, 16 February 2017 at 21:05:51 UTC, Stefan Koch
wrote:
[ ... ]
limited Support for 32bit floating point ops [+, -, *, /, %]
has just landed in newCTFE.
float fmadd(float a, float b, float c)
{
return b + a * c;
}
On Thursday, 16 February 2017 at 21:05:51 UTC, Stefan Koch wrote:
[ ... ]
limited Support for 32bit floating point ops [+, -, *, /, %] has
just landed in newCTFE.
float fmadd(float a, float b, float c)
{
return b + a * c;
}
pragma(msg, fmadd(6.7, 8.9, 1.3)/* == 17.61f*/);
pragma(msg,
On Thursday, 16 February 2017 at 21:05:51 UTC, Stefan Koch wrote:
[ ... ]
newCTFE specific tests are now included in my version of the
test-suite.
No more silent breakage. (Atleast for anything covered by the
test.)
For this to work I introduced a __trait which returns true if
newCTFE
On Thursday, 16 February 2017 at 21:05:51 UTC, Stefan Koch wrote:
[ ... ]
Slice Assignment bugs fixed!
With that we are green again.
I am going to improve concat a little such that it computes the
buffer lengths if it can.
And allocs the needed amount upfront.
The alternative is lazy
On Thursday, 16 February 2017 at 21:05:51 UTC, Stefan Koch wrote:
[ ... ]
Hi there,
I just pulled another all nighter.
I found a bug in the code that was supposed to adjust the values
of || and &&.
As will as a mixup in the error messages for overlapping
slice-assignment.
Both are fixed.
I
On Tue, Jun 06, 2017 at 03:35:11PM -0400, Steven Schveighoffer via
Digitalmars-d wrote:
[...]
> I can characterize memory corruption bugs as errors that occur
> randomly and can manifest in any kind of behavior. Even more nasty is
> sometimes they happen in code that you didn't even touch,
On 6/6/17 2:51 PM, H. S. Teoh via Digitalmars-d wrote:
On Tue, Jun 06, 2017 at 02:23:59PM -0400, Steven Schveighoffer via
Digitalmars-d wrote:
On 6/6/17 12:39 PM, H. S. Teoh via Digitalmars-d wrote:
On Tue, Jun 06, 2017 at 02:03:46AM +, jmh530 via Digitalmars-d wrote:
On Tuesday, 6 June
On Tuesday, 6 June 2017 at 18:51:58 UTC, H. S. Teoh wrote:
Things like this make you *really* appreciate D features
and the oft-maligned but life-saving GC.
+1000! GC is an opportunity, not a burden! :-P
/Paolo
On Tue, Jun 06, 2017 at 02:23:59PM -0400, Steven Schveighoffer via
Digitalmars-d wrote:
> On 6/6/17 12:39 PM, H. S. Teoh via Digitalmars-d wrote:
> > On Tue, Jun 06, 2017 at 02:03:46AM +, jmh530 via Digitalmars-d wrote:
> > > On Tuesday, 6 June 2017 at 00:46:00 UTC, Stefan Koch wrote:
> > > >
On 6/6/17 12:39 PM, H. S. Teoh via Digitalmars-d wrote:
On Tue, Jun 06, 2017 at 02:03:46AM +, jmh530 via Digitalmars-d wrote:
On Tuesday, 6 June 2017 at 00:46:00 UTC, Stefan Koch wrote:
Time to find this: roughly 2 weeks.
Damn. That's some commitment.
2 weeks is not bad for subtle
On Tuesday, 6 June 2017 at 16:39:07 UTC, H. S. Teoh wrote:
On Tue, Jun 06, 2017 at 02:03:46AM +, jmh530 via
Digitalmars-d wrote:
On Tuesday, 6 June 2017 at 00:46:00 UTC, Stefan Koch wrote:
>
> Time to find this: roughly 2 weeks.
>
Damn. That's some commitment.
2 weeks is not bad for
On Tue, Jun 06, 2017 at 02:03:46AM +, jmh530 via Digitalmars-d wrote:
> On Tuesday, 6 June 2017 at 00:46:00 UTC, Stefan Koch wrote:
> >
> > Time to find this: roughly 2 weeks.
> >
>
> Damn. That's some commitment.
2 weeks is not bad for subtle bugs in complex code like this one. In my
day
On Tuesday, 6 June 2017 at 04:11:33 UTC, Stefan Koch wrote:
On Tuesday, 6 June 2017 at 02:03:46 UTC, jmh530 wrote:
On Tuesday, 6 June 2017 at 00:46:00 UTC, Stefan Koch wrote:
Time to find this: roughly 2 weeks.
Damn. That's some commitment.
There is no other way, really.
These things
On Tuesday, 6 June 2017 at 02:03:46 UTC, jmh530 wrote:
On Tuesday, 6 June 2017 at 00:46:00 UTC, Stefan Koch wrote:
Time to find this: roughly 2 weeks.
Damn. That's some commitment.
There is no other way, really.
These things need to be fixed.
On Tuesday, 6 June 2017 at 00:46:00 UTC, Stefan Koch wrote:
Time to find this: roughly 2 weeks.
Damn. That's some commitment.
On Monday, 5 June 2017 at 20:51:03 UTC, Stefan Koch wrote:
On Thursday, 16 February 2017 at 21:05:51 UTC, Stefan Koch
wrote:
[ .. ]
Hi Guys,
I am still working on the buggy Slice-Assignment.
Just now I fixed a bug where an [Bytecode-Assert]
would flip it's the condition ... and trigger
On Thursday, 16 February 2017 at 21:05:51 UTC, Stefan Koch wrote:
[ .. ]
Hi Guys,
I am still working on the buggy Slice-Assignment.
Just now I fixed a bug where an [Bytecode-Assert]
would flip it's the condition ... and trigger whenever it was
true instead of false.
Assertions are one of
On Sunday, 28 May 2017 at 22:26:18 UTC, Stefan Koch wrote:
On Thursday, 16 February 2017 at 21:05:51 UTC, Stefan Koch
wrote:
[ ... ]
Hi Guys,
I just fixed the sliceAssignment!
now overlapping assignments are correctly detected.
I also re-enabled a bailout on struct-member operation which
On Thursday, 16 February 2017 at 21:05:51 UTC, Stefan Koch wrote:
[ ... ]
Hi Guys,
I just fixed the sliceAssignment!
now overlapping assignments are correctly detected.
I also re-enabled a bailout on struct-member operation which are
not simple integers.
Which means I chose to ignore some
On Tuesday, 23 May 2017 at 17:46:23 UTC, Petar Kirov [ZombineDev]
wrote:
Seems like you need to make -bc-ctfe the default in your dmd
branch :P
That is what I usually do, however I re-enabled the switch in
order to test which error messages the current Interpreter throws
out.
On Tuesday, 23 May 2017 at 17:26:01 UTC, Stefan Koch wrote:
On Sunday, 21 May 2017 at 14:49:32 UTC, Stefan Koch wrote:
Huh apparently I fixed this issue.
But I cannot rememberer when or how I did it.
This test will now magically work.
This concerns me.
I finally figured out what was going
On Sunday, 21 May 2017 at 14:49:32 UTC, Stefan Koch wrote:
Huh apparently I fixed this issue.
But I cannot rememberer when or how I did it.
This test will now magically work.
This concerns me.
I finally figured out what was going on.
I forgot to activate the -bc-ctfe switch
A few days of
On Tuesday, 16 May 2017 at 13:44:27 UTC, Stefan Koch wrote:
On Thursday, 16 February 2017 at 21:05:51 UTC, Stefan Koch
wrote:
[ ... ]
So ...
I just encountered more ABI issues; related to slices which are
part of structures.
struct R
{
uint[] s1;
uint[] s2;
}
like this.
R
On Thursday, 16 February 2017 at 21:05:51 UTC, Stefan Koch wrote:
...
|| works also fine now ... on it's own.
As soon as || and && are mixed wired things happen.
I am happy that the combinations I tried do at least expose the
issue.
This is one of the things that you can totally overlook if
On Thursday, 16 February 2017 at 21:05:51 UTC, Stefan Koch wrote:
[ ... ]
So I just verified that the following code runs fine with newCTFE.
int[2] aaa2(bool b1, bool b2, bool b3)
{
int x = 0;
if (b1 && ++x && b2 && x++ && b3 && x++)
{
return [x, 1];
}
else
{
return [x,
On Tuesday, 16 May 2017 at 13:44:27 UTC, Stefan Koch wrote:
[ ... ]
The reason ABI issues.
Where exactly ? No Idea.
Not just abi issues ...
There are more fundamental problems where we sometimes forget to
allocate space, for locals (of composite types).
On Thursday, 16 February 2017 at 21:05:51 UTC, Stefan Koch wrote:
[ ... ]
So ...
I just encountered more ABI issues; related to slices which are
part of structures.
struct R
{
uint[] s1;
uint[] s2;
}
like this.
R returnSlices(int[] s1, int[] s2)
{
return R(s1[], s2[]);
}
static
On Thursday, 16 February 2017 at 21:05:51 UTC, Stefan Koch wrote:
[ ... ]
So I have fixed a few cases of outer function evaluation.
Unfortunately this exposed some hard to track down bugs in how
expressions are handled.
The JIT and Debugger features are on ice, until those bugs are
On Friday, 12 May 2017 at 11:21:56 UTC, Stefan Koch wrote:
...
anyway.
I am happy this is fixed now.
Now I am less happy.
The fallout of this fix causes code in std.ascii to miscompile.
Apperantly we don't make sure our function list is cleared before
finalization.
On Thursday, 16 February 2017 at 21:05:51 UTC, Stefan Koch wrote:
[ ... ]
Hi Guys,
Outer function arguments are now supperted.
meaning this code will now work:
int[] filterBy(int[] arr , bool function(uint) fn)
{
int[] result = [];
uint resultLength;
result.length = arr.length;
On Thursday, 16 February 2017 at 21:05:51 UTC, Stefan Koch wrote:
[ ... ]
Thanks to Daniel Murphy's input; '&&' works now in my
experimental version.
I hope to get it to pass the auto-tester soon!
This is a big step :)
Thanks Daniel.
On Sunday, 30 April 2017 at 19:52:27 UTC, H. S. Teoh wrote:
On Sun, Apr 30, 2017 at 01:26:09PM +, Stefan Koch via
Digitalmars-d wrote:
On Thursday, 16 February 2017 at 21:05:51 UTC, Stefan Koch
wrote:
> [ ... ]
Big news!
The first step to include debug info has been done.
Yes this means
On Wednesday, 3 May 2017 at 07:35:56 UTC, Stefan Koch wrote:
On Wednesday, 3 May 2017 at 06:10:22 UTC, Adrian Matoga wrote:
So you're going to reinvent TCP in your debugging protocol?
No. there is no need for a full blown recovery mechanism.
For the typical usecase a lossless orderd
On Wednesday, 3 May 2017 at 07:35:56 UTC, Stefan Koch wrote:
For the typical usecase a lossless orderd connection can be
assumed.
- udp is not connection oriented, i.e. there is no connection
- udp is not lossless and pretending it is means setting yourself
up for a headache down the road
-
On Wednesday, 3 May 2017 at 04:22:00 UTC, Stefan Koch wrote:
[...]
I think any ordering should be done explicitly at the debugging
protocol level.
for example when sending sourceline messages the order is given
by the line number and ordering can be done by the application.
It's the same for
On Wednesday, 3 May 2017 at 08:23:54 UTC, Nordlöw wrote:
On Wednesday, 3 May 2017 at 07:35:56 UTC, Stefan Koch wrote:
On Wednesday, 3 May 2017 at 06:10:22 UTC, Adrian Matoga wrote:
So you're going to reinvent TCP in your debugging protocol?
No. there is no need for a full blown recovery
An article about LLVM jit:
https://webkit.org/blog/5852/introducing-the-b3-jit-compiler/
On Sunday, 30 April 2017 at 13:26:09 UTC, Stefan Koch wrote:
On Thursday, 16 February 2017 at 21:05:51 UTC, Stefan Koch
wrote:
[ ... ]
Big news!
The first step to include debug info has been done.
Yes this means you will be able to step through ctfe code while
the compiler executes it.
On Wednesday, 3 May 2017 at 07:35:56 UTC, Stefan Koch wrote:
On Wednesday, 3 May 2017 at 06:10:22 UTC, Adrian Matoga wrote:
So you're going to reinvent TCP in your debugging protocol?
No. there is no need for a full blown recovery mechanism.
For the typical usecase a lossless orderd
On Wednesday, 3 May 2017 at 06:10:22 UTC, Adrian Matoga wrote:
So you're going to reinvent TCP in your debugging protocol?
No. there is no need for a full blown recovery mechanism.
For the typical usecase a lossless orderd connection can be
assumed.
And most things are not order dependent
On Wednesday, 3 May 2017 at 04:22:00 UTC, Stefan Koch wrote:
On Tuesday, 2 May 2017 at 22:08:31 UTC, Moritz Maxeiner wrote:
[...]
Using TCP would just remove any potential future headache from
the equation.
I think any ordering should be done explicitly at the debugging
protocol level.
for
On Tuesday, 2 May 2017 at 22:08:31 UTC, Moritz Maxeiner wrote:
On Tuesday, 2 May 2017 at 09:55:56 UTC, Stefan Koch wrote:
[...]
I intended for the debugging functionality to be exposed via a
udp socket listening on localhost.
Such that a debug-ui does not have to deal with ipc
difficulties.
On Tuesday, 2 May 2017 at 09:55:56 UTC, Stefan Koch wrote:
[...]
I intended for the debugging functionality to be exposed via a
udp socket listening on localhost.
Such that a debug-ui does not have to deal with ipc
difficulties.
Hm, rationale for UDP over TCP here? I would assume one
On Tue, May 02, 2017 at 09:55:56AM +, Stefan Koch via Digitalmars-d wrote:
[...]
> I intended for the debugging functionality to be exposed via a udp
> socket listening on localhost.
> Such that a debug-ui does not have to deal with ipc difficulties.
> I am strictly against building a debugger
On Monday, 1 May 2017 at 19:06:24 UTC, H. S. Teoh wrote:
On Mon, May 01, 2017 at 06:23:08PM +, Stefan Koch via
Digitalmars-d wrote:
[...]
I'm not sure about providing a debugger UI inside the compiler
itself... it's certainly possible, and could lead to
interesting new ways of using a
On Mon, May 01, 2017 at 06:23:08PM +, Stefan Koch via Digitalmars-d wrote:
> On Sunday, 30 April 2017 at 19:52:27 UTC, H. S. Teoh wrote:
> > On Sun, Apr 30, 2017 at 01:26:09PM +, Stefan Koch via Digitalmars-d
> > wrote:
> > > On Thursday, 16 February 2017 at 21:05:51 UTC, Stefan Koch
On Sunday, 30 April 2017 at 19:52:27 UTC, H. S. Teoh wrote:
On Sun, Apr 30, 2017 at 01:26:09PM +, Stefan Koch via
Digitalmars-d wrote:
On Thursday, 16 February 2017 at 21:05:51 UTC, Stefan Koch
wrote:
> [ ... ]
Big news!
The first step to include debug info has been done.
Yes this means
On Sun, Apr 30, 2017 at 01:26:09PM +, Stefan Koch via Digitalmars-d wrote:
> On Thursday, 16 February 2017 at 21:05:51 UTC, Stefan Koch wrote:
> > [ ... ]
>
> Big news!
> The first step to include debug info has been done.
>
> Yes this means you will be able to step through ctfe code while
On Thursday, 16 February 2017 at 21:05:51 UTC, Stefan Koch wrote:
[ ... ]
Big news!
The first step to include debug info has been done.
Yes this means you will be able to step through ctfe code while
the compiler executes it.
On Friday, 28 April 2017 at 17:53:04 UTC, Stefan Koch wrote:
On Thursday, 16 February 2017 at 21:05:51 UTC, Stefan Koch
wrote:
[ ... ]
Hi Guys, I just implemented sliceAssigment.
meaning the following code will now compile:
uint[] assignSlice(uint from, uint to, uint[] stuff)
{
uint[]
On Friday, 28 April 2017 at 08:47:43 UTC, Stefan Koch wrote:
On Thursday, 16 February 2017 at 21:05:51 UTC, Stefan Koch
wrote:
[ ... ]
After a little of exploration of the JIT, I have now determined
that a simple risc architecture is still the best.
(codegen for scaled loads is hard :p)
I
On Friday, 28 April 2017 at 17:53:04 UTC, Stefan Koch wrote:
On Thursday, 16 February 2017 at 21:05:51 UTC, Stefan Koch
wrote:
[ ... ]
Hi Guys, I just implemented sliceAssigment.
meaning the following code will now compile:
uint[] assignSlice(uint from, uint to, uint[] stuff)
{
uint[]
On Thursday, 16 February 2017 at 21:05:51 UTC, Stefan Koch wrote:
[ ... ]
Hi Guys, I just implemented sliceAssigment.
meaning the following code will now compile:
uint[] assignSlice(uint from, uint to, uint[] stuff)
{
uint[] slice;
slice.length = to + 4;
foreach (uint i; 0 .. to
On Friday, 28 April 2017 at 13:13:16 UTC, Stefan Koch wrote:
Do you mean no Jit?
Of course there will be a JIT.
Ah, I misunderstood you formulation.
But currently I am fixing busy bugs in the generated IR.
So the implementation of jit will have to wait a little.
Ok. Thanks.
On Friday, 28 April 2017 at 13:03:42 UTC, Nordlöw wrote:
On Friday, 28 April 2017 at 08:47:43 UTC, Stefan Koch wrote:
After a little of exploration of the JIT, I have now
determined that a simple risc architecture is still the best.
(codegen for scaled loads is hard :p)
Do you mean no Jit?
On Friday, 28 April 2017 at 08:47:43 UTC, Stefan Koch wrote:
After a little of exploration of the JIT, I have now determined
that a simple risc architecture is still the best.
(codegen for scaled loads is hard :p)
Do you mean no Jit?
On Thursday, 16 February 2017 at 21:05:51 UTC, Stefan Koch wrote:
[ ... ]
After a little of exploration of the JIT, I have now determined
that a simple risc architecture is still the best.
(codegen for scaled loads is hard :p)
I am now back to fixing non-compiling code,
such as :
struct S
On Thursday, 27 April 2017 at 08:51:17 UTC, Dmitry Olshansky
wrote:
On 4/27/17 4:15 AM, Stefan Koch wrote:
On Thursday, 16 February 2017 at 21:05:51 UTC, Stefan Koch
wrote:
[ ... ]
Hi Guys,
As you already probably know some work has been done in the
past week to
get an x86 jit rolling.
It
On 4/27/17 4:15 AM, Stefan Koch wrote:
On Thursday, 16 February 2017 at 21:05:51 UTC, Stefan Koch wrote:
[ ... ]
Hi Guys,
As you already probably know some work has been done in the past week to
get an x86 jit rolling.
It is designed to produce very simple code with _any_ optimization at
On Thursday, 27 April 2017 at 03:33:03 UTC, H. S. Teoh wrote:
Is it possible at all to use any of the backend (in particular
what parts of the optimizer that are pertinent), or is the API
not conducive for this?
T
It is of course possible to use dmds backend but not very
desirable, dmds
On Thu, Apr 27, 2017 at 02:15:30AM +, Stefan Koch via Digitalmars-d wrote:
> On Thursday, 16 February 2017 at 21:05:51 UTC, Stefan Koch wrote:
> > [ ... ]
> Hi Guys,
>
> As you already probably know some work has been done in the past week
> to get an x86 jit rolling.
>
> It is designed to
On Thursday, 16 February 2017 at 21:05:51 UTC, Stefan Koch wrote:
[ ... ]
Hi Guys,
As you already probably know some work has been done in the past
week to get an x86 jit rolling.
It is designed to produce very simple code with _any_
optimization at all.
Since optimization introduces
On Thursday, 16 February 2017 at 21:05:51 UTC, Stefan Koch wrote:
[ ... ]
Hi Guys,
I just fixed default initialization of structs.
So now a larger portion of code will be compiled and executed by
newCTFE.
my_struct MyStruct;
will now work, before it would trigger a bailout.
NOTE: this will
On Saturday, 15 April 2017 at 10:30:57 UTC, Moritz Maxeiner wrote:
On Saturday, 15 April 2017 at 10:10:54 UTC, Stefan Koch wrote:
On Thursday, 16 February 2017 at 21:05:51 UTC, Stefan Koch
wrote:
Hi Guys, due to the old CTFE status thread getting to page
30, I am now starting a new one.
On Saturday, 15 April 2017 at 10:10:54 UTC, Stefan Koch wrote:
On Thursday, 16 February 2017 at 21:05:51 UTC, Stefan Koch
wrote:
Hi Guys, due to the old CTFE status thread getting to page 30,
I am now starting a new one.
[...]
The llvm backend is back in a fully working state.
It's about
On Thursday, 16 February 2017 at 21:05:51 UTC, Stefan Koch wrote:
Hi Guys, due to the old CTFE status thread getting to page 30,
I am now starting a new one.
[...]
The llvm backend is back in a fully working state.
It's about 2times slower in my then my interpreter ;)
On Thursday, 16 February 2017 at 21:05:51 UTC, Stefan Koch wrote:
{ ... }
Wonderful news!
Most of the Byteocode macros are gone!
meaning less templates and faster bytecode generartion!
On Thursday, 16 February 2017 at 21:05:51 UTC, Stefan Koch wrote:
[ ... ]
Hi I want to share another story.
I was pretty happy to have recursive function calls working.
So happy in fact that I overlooked that they were actually
generated twice.
Let me illustrate what happend.
Suppose we
On Thursday, 16 February 2017 at 21:05:51 UTC, Stefan Koch wrote:
[ ... ]
Comma expressions should now work.
On Wed, Apr 12, 2017 at 01:18:13PM +, Stefan Koch via Digitalmars-d wrote:
> On Thursday, 16 February 2017 at 21:05:51 UTC, Stefan Koch wrote:
> > [ ... ]
>
> I just fixed the static assert((null ~ null) is null);
> Hence I can now enable string-concat!
[...]
Good news!
T
--
Век живи -
On Wednesday, 12 April 2017 at 09:19:39 UTC, Stefan Koch wrote:
On Thursday, 16 February 2017 at 21:05:51 UTC, Stefan Koch
wrote:
[ ... ]
I just found more states we get into, that should be impossible
to ever get into.
I am stumped.
Baffled.
And seriously befuddled!
So .. this is
On Thursday, 16 February 2017 at 21:05:51 UTC, Stefan Koch wrote:
[ ... ]
I just fixed the static assert((null ~ null) is null);
Hence I can now enable string-concat!
1 - 100 of 191 matches
Mail list logo
