newCTFE Status August 2017

Stefan Koch via Digitalmars-d digitalmars-d at puremagic.com
Tue Aug 1 21:41:31 PDT 2017


On Tuesday, 1 August 2017 at 21:27:32 UTC, Stefan Koch wrote:
> Sadly I temporarily broke the support for string-members in 
> structs.

Fixed now.

The issue was ABI related.
we used to store pointers to sliceDescriptors, but I changed that 
to store the sliceDescriptors directly. Because otherwise slicing 
of initializes of type string does not work.

I am happy I thought about this briefly two months ago, and to 
have had the foresight to put in stubs for that, otherwise this 
would have gotten much messier.

Another issue I want to deal with are void initalized struct 
members.
In a few instances we can statically determine that they are 
always initialized.
i.e. when there are no branches.
In most instances this is not the case though .... this requires 
us to store a bitfield next to the this pointer of the struct 
which indicated if a paricular member has been initialized or not.
Luckily we only need to do that for `= void` members. So I think 
we can get away with 32bit.

I should mention that newCTFE does currently not support structs 
with more then 96 member-variables anyway.
So far I have not come close to hitting that limit.

Talking about limits, this are the current limits I am aware of.
you can only use 16000 local variables per function.
you can only allocate around 265 Megabyte of heap-space per 
evaluation.
Only functions with up to 64 parameters are supported.
you can only have up to 65535 instructions per function (roughly 
16000 lines of code)
The call-stack can only be 2000 calls deep. (This is an artifical 
limtation that the old interpreter imposed because it would die 
and use insane amounts of memery wehen it went over that limit. 
(With newCTFE you can safely bump that limit up to 5000 levels of 
recursion .... but in order to pass all unittests we need to keep 
the old limit))
You can only have about 12000 different struct types per 
evaluation.
And only about 16000 assertions.
Similarly there may only be 7000 array-literals per function.

I don't see anyone reaching those limits soon.

Cheers,
Stefan



More information about the Digitalmars-d mailing list