July 08, 2017
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*) //reinterpret

However is is not yet hooked up to newCTFE.
As I need to think about the interface.

Either I can go with a Cast and BitCast function
(which are prone to strange behavior, if they used with the lowered IR)
Or
Add the more explicit
F32ToF64, F64To32,
F32ToSI, SIToF32, UIToF32,
F64ToSI, SIToF64, UIToF64,

Which adds 8 calls to the IR-API and looks unsightly.


July 12, 2017
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 in it's own right)
Slices are generally represented as 16Byte SliceDescriptors
of the form
struct SliceDesc
{
  uint Base; // T* really. but always 4 bytes regardless
  uint Length;
  uint Capcity; // unused for now.
  uint ExtraFlags // unused will be important for array-casts
}

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
}

Now Slices inside of structs are stored by injecting the corresponding sliceDescriptor
Meaning:
AS { uint[] a; uint aLen; } => {  uint[4] aDesc; uint aLen }
However the code that is repsonsible for converting newCTFE-ABI values to DMD-expressions was still assuming this data-layout
AS { uint[] a; uint aLen; } => { (uint[4])* aDescPtr; uint aLen }
which caused it to do an extra derefence and and actually interpreting the sliceBase as a descriptor pointer.

Which of course produced complete garbage.

The reason why this took me so long to fix is because I suspected that the conversion was using the new convention and the byte-code generator was at fault.
And in my attemptes to fix the bytecode generation I introduced even more ABI bugs.

long story short:
This is now fixed.
and
ABI bugs are HELL!

Cheers,
Stefan




July 12, 2017
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 like that? This won't work on non-x86 architectures that don't allow unaligned memory access.
July 12, 2017
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 doing in more general terms. Answering the question, what will the new CTFE bring to us all and when should we start preparing a big celebration for the time it gets part of DMD?
July 12, 2017
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; // offset: 12
>>   ubyte m4; // offset: 16
>> }
>
> Do you plan to keep it like that? This won't work on non-x86 architectures that don't allow unaligned memory access.
For the time being, yes I plan to keep it.
It is 4 byte aligned which is plenty of alignment.

For architectures which do not allow unaligned access we would split the ulong into hi and lo parts.
64bit arithmetic can generally be assumed to take a slower path in newCTFE.


July 12, 2017
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 a newbie, could you please point to a post describing what you are doing in more general terms. Answering the question, what will the new CTFE bring to us all and when should we start preparing a big celebration for the time it gets part of DMD?

Here is a blog-port describing the project.
http://dlang.org/blog/2017/04/10/the-new-ctfe-engine/

newCTFE will reduce the time taken for ctfe by roughly 10x
And, more importantly it reduces the memory-usage.
Instead of a few gigabyte it will not even allocate more then a megabyte.
(Currently it is hard capped to a maximum of 64K stack space and 16M heap).

July 12, 2017
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 together the actual source-code which is being executed.

templates are a pain in the butt!

July 12, 2017
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 (test/runnable/template8.d)
>
> This is again hard to debug because I have to piece together the actual source-code which is being executed.
>
> templates are a pain in the butt!

stop advertising yourself and polluting this thread.
seek help - no down-payments in Germany!!
July 12, 2017
On Thu, Jul 13, 2017 at 01:23:53AM +0000, 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 it's a joke ?

Or a troll.  Just ignore it.


T

-- 
Debian GNU/Linux: Cray on your desktop.
July 13, 2017
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
https://github.com/UplinkCoder/dmd/tree/newCTFE_on_master
and compiling tests/runnable/template8.d