from:"Daniel Murphy"

Re: C++ to D converter based on clang

2016-06-01 Thread Daniel Murphy via Digitalmars-d-announce


On 1/06/2016 9:40 PM, Jacob Carlborg wrote:

Yes I could. Like I could participate to VisualD/cpp2d or magicport2
projects.


Anything that is not using a real front end is a lost cause.



Haha that really depends on your goals.

Re: Battle-plan for CTFE

2016-05-19 Thread Daniel Murphy via Digitalmars-d-announce


On 19/05/2016 3:50 AM, Stefan Koch wrote:

I am currently designing an IR to feed into the CTFE Evaluator.
I am aware that this could potentially make it harder to get things
merged since DMD already has the glue-layer.



It's always more difficult to justify merging more complexity.  But if 
you can present a working and superior solution the specific 
implementation is less important.  It is still important that it matches 
the existing style of the compiler, especially with respect to adding 
dependencies.


Also be aware that even with agreement on the eventual goal, it is still 
very slow to get big changes approved.  eg ddmd took more than twice as 
long as it should have.  This is why I suggested looking for incremental 
improvements, so you can overlap getting earlier things merged and 
developing later parts.  I would be on the lookout for things that can 
be justified on their own (untangling AssignExp :) ) and try to push 
those through first.

Re: Battle-plan for CTFE

2016-05-18 Thread Daniel Murphy via Digitalmars-d-announce

On 18/05/2016 9:01 AM, Martin Nowak wrote:

Yes, this
https://github.com/dlang/dmd/blob/7d00095301c4780b41addcfeb50f4743a9a6c5d4/src/dinterpret.d#L3418
is really ugly and complex, but you won't get rid of this inherent
complexity. The e2ir code for AssingExp looks almost the same
https://github.com/dlang/dmd/blob/7d00095301c4780b41addcfeb50f4743a9a6c5d4/src/e2ir.c#L2466.

IMO this is a different problem, that AssignExp is stupidly complex and
needs to be split up.

You might imagine that it's easier to work with syntax trees than to
start from scratch but I'm certain that's not true. I'm pretty sure that
the simplest approach is to use the simplest possible
machine-independent bytecode that you can come up with. I had got to the
point of starting that, but I just couldn't face doing it in C++.

All I'm saying is that interpreting the AST to generate bytecode is
going to be as complex as interpreting the AST directly, but then you
still a bytecode interpreter and later might still want a JIT.

The bytecode generator and bytecode interpreter can be debugged (and
tested!) independently. So the total amount of code will increase but
the components themselves will be better isolated and easier to work with.

I don't think a possible future need for a JIT is a good reason to avoid
an bytecode interpreter. A large part of the work of adding a new (JIT)
backend is pinning down the semantics, and adding a bytecode interpreter
will certainly help to do that.

Using dedicated value types during interpretation instead of recycling
the AST for that will also make the transitions clearer and get rid of
some of the lifetime complexities in the current code.

Meh, sure. But this feels just as difficult as switching to a simple
bytecode, without all the benefits.

Re: Battle-plan for CTFE

2016-05-16 Thread Daniel Murphy via Digitalmars-d-announce


On 16/05/2016 9:20 PM, Martin Nowak wrote:

On Monday, 16 May 2016 at 10:01:47 UTC, Kagamin wrote:

Wasn't it possible to enable GC for entire compiler? There can be
hybrid approach: 1) first allocate from bump heap 2) when it reaches,
say, 200MB, switch to GC.


Well, I wouldn't use D's GC for that dedicated heap.
Allocation of CTFE values are completely independent and call be freed
once the evaluation is finished.


Maybe you wouldn't, but you certainly could...

Re: Battle-plan for CTFE

2016-05-15 Thread Daniel Murphy via Digitalmars-d-announce


On 15/05/2016 11:25 PM, Martin Nowak wrote:

On 05/15/2016 02:17 PM, Daniel Murphy wrote:


For simple types that's true.  For more complicated reference types...

Variable indexes are not enough, you also need heap memory, but slices
and pointers (and references) can refer to values either on the heap or
the stack, and you can have a slice of a member static array of a class
on the stack, etc.  Then there are closures...


So we do need a GC or RC for arrays, structs, classes (anything
heapish). Values for those could be allocated by a simple bump/region
allocator or a dedicated allocator that support individual freeing (via
RC or GC).

In any case struct Pointer { int index; /* 2B positive values for stack,
2B negative for heap*/ } wouldn't be much more complicated than a raw
pointer (and a bit simpler to garbage collect).



The problem is, if index refers to a single variable on the stack, then 
it's insufficient to refer to a variable inside an aggregate on the 
stack.  Then you need to start building constructs for member of struct 
in array of struct pointers and it gets fairly messy...  It's all 
solvable, I'm not sure the simplicity would survive.



Neither e2ir or s2ir are actually that complex.  A lot of the mess there
comes from the backend IR interface being rather difficult to work with.


Think of a simple switch statement where you even need to introduce
relocations (or keep a list of fixup addresses) b/c you don't know the
jump addresses in advance.


This is not exactly difficult to do.


In a visitor you simply test the cases and execute the first case body.

Not to mention that we can reuse existing solutions from the current
interpreter (e.g. for gotos see
https://github.com/dlang/dmd/blob/0757504342e48e272372b7ac52cda5a333b2a2bc/src/dinterpret.d#L1014
and
https://github.com/dlang/dmd/blob/0757504342e48e272372b7ac52cda5a333b2a2bc/src/dinterpret.d#L1094).



Flow control is really not where the complexity lies IMO.  The weird 
ways in which different types of reference types can combine leads to 
either very complicated or very low level descriptions of memory.

Re: Battle-plan for CTFE

2016-05-15 Thread Daniel Murphy via Digitalmars-d-announce


On 15/05/2016 9:57 PM, Martin Nowak wrote:

On 05/15/2016 01:58 PM, Daniel Murphy wrote:

The biggest advantage of bytecode is not the interpreter speed, it's
that by lowering you can substitute VarExps etc with actual references
to memory without modifying the AST.

By working with something lower level than the AST, you should end up
with something much less complex and with fewer special cases.


Which is a bad assessment, you can stick variable indexes into
VarDeclaration (we already do that) and thereby access them in O(1).
Converting control flow and references into byte code is far from
trivial, we're talking about another s2ir and e2ir here.

-Martin



We really should have discussed this last week!

Re: Battle-plan for CTFE

2016-05-15 Thread Daniel Murphy via Digitalmars-d-announce


On 15/05/2016 9:57 PM, Martin Nowak wrote:

On 05/15/2016 01:58 PM, Daniel Murphy wrote:

The biggest advantage of bytecode is not the interpreter speed, it's
that by lowering you can substitute VarExps etc with actual references
to memory without modifying the AST.

By working with something lower level than the AST, you should end up
with something much less complex and with fewer special cases.


Which is a bad assessment, you can stick variable indexes into
VarDeclaration (we already do that) and thereby access them in O(1).
Converting control flow and references into byte code is far from
trivial, we're talking about another s2ir and e2ir here.

-Martin



For simple types that's true.  For more complicated reference types...

Variable indexes are not enough, you also need heap memory, but slices 
and pointers (and references) can refer to values either on the heap or 
the stack, and you can have a slice of a member static array of a class 
on the stack, etc.  Then there are closures...


Neither e2ir or s2ir are actually that complex.  A lot of the mess there 
comes from the backend IR interface being rather difficult to work with. 
 We can already save a big chunk of complexity by not having to 
translate the frontend types.  E.g.  implementing the logic in the 
interpreter to correctly unwind through destructors is unlikely to be 
simpler than lowering to an IR.

Re: Battle-plan for CTFE

2016-05-15 Thread Daniel Murphy via Digitalmars-d-announce


On 15/05/2016 8:29 PM, Martin Nowak wrote:


No need for a byte-code interpreter, it mostly just adds overhead and
complexity over an AST interpreter. If you want to go really fast you
need some sort of JIT anyhow, but a proper interpreter will be orders of
mangnitude faster than the current implementation.



The biggest advantage of bytecode is not the interpreter speed, it's 
that by lowering you can substitute VarExps etc with actual references 
to memory without modifying the AST.


By working with something lower level than the AST, you should end up 
with something much less complex and with fewer special cases.


The current goal is not a full JIT, just something that manages memory 
in a less insane way.

Re: unit-threaded v0.5.7 - advanced multi-threaded unit testing library

2016-02-13 Thread Daniel Murphy via Digitalmars-d-announce


On 9/02/2016 12:23 AM, Atila Neves wrote:

What's new:

Built-in unittest blocks can now have a name with just a string UDA:


@("test that does stuff") unittest {... }



I feel obliged to point out that this is going to be a disaster as soon 
as any other library decides that means something else.

Re: Vision for the first semester of 2016

2016-02-01 Thread Daniel Murphy via Digitalmars-d-announce


On 1/02/2016 8:46 AM, Iain Buclaw via Digitalmars-d-announce wrote:


I know, I've been hitting bug after bug in 2.067, and the answer has always
been to backport from 2.068.  I already have backported druntime's object.d
from 2.068 because 2.067's object module has drifted so far out of sync
with it's hidden implementation, I couldn't build anything!  So I might as
well backport the rest of the druntime library.  Nothing much has changed
as it was a "bugfix" release.



The process will be complete when you've backported the entirety of 2.068.

Re: Release D 2.069.0

2015-11-08 Thread Daniel Murphy via Digitalmars-d-announce


On 9/11/2015 10:25 AM, Jack Stouffer wrote:


Is there any reason why this isn't currently used in the front end?


Lack of testing, focus on matching c-dmd performance, it used to be 
blocked and nobody realized it wasn't any more etc.

Re: Release D 2.069.0

2015-11-08 Thread Daniel Murphy via Digitalmars-d-announce


On 8/11/2015 1:41 AM, Dmitry Olshansky wrote:


IMHO enabling D's GC in the frontend is better way to fix leaking in the
CTFE, but there are some issues with that (it segfaults if we enable GC).



Actually I think it's fixed now, just disabled.

It used to have problems with lib*/scan*, but those are in D now, and 
most of the allocations from the glue layer are being forwarded to the 
GC through rmem.


If anyone wants to try it they just need to add -version=GC to the DMD 
build flags and insert this function in root/rmem.d's version(GC) block.



extern (C) void* allocmemory(size_t m_size)
{
return GC.malloc(m_size);
}

1 2 >

1 - 100 of 135 matches

Mail list logo