Hi,

Just formulating some ideas that may well go into a DIP.

=== A ===

I raised this back in early 2013 [1], and so I might as well be the necromancer and raise it again.

The cent and ucent keywords have been reserved since... well... certainly before the first D1 (as opposed to D0.xx) release [2].  But that's all they have ever seemed to be.  Just reserved keywords that give odd errors when you try to use them.

It was only until 2.061 that any valid semantic meaning (and errors) were actually given to them. [3]

Now we have DDMD approaching fast round the corner, with it comes the prospect of leveraging the many library types in D for use in the compiler frontend; BigInt, CustomFloat, HalfFloat; and preferring the deterministic accuracy of them over native types that:
1) May produce different results on each host platform (true for floating-point).
2) Restricts readily-supported backends to a precision that only the host can do (true for all types).

BigInt is certainly on the cards for making native 128-bit support possible, but it still needs to be set apart from global and function symbols.  For that, it needs to finally be given a mangled identifier.

Now, since last writing, 'N' has been used up by wild(T) types, leaving only 'z' and 'Q' left.  Now, I feel that it is very wasteful at this point to give away these last remaining digits to cent/ucent, so it has *got* to be a two-digit mangle identifier.  For instance zi/zk for cent/ucent respectively.

Grammar is simple enough and doesn't cause conflicts in demangling.

TypeCent:
	zi

TypeUcent:
	zk

However the thought does strike me that this might be wasteful too, and we've now only got the single letter left before we'd be forced to start breaking ABI to refactor things round and make new room for potential future additions.  Afterall, we have no idea what may add in the future.

I'd also like to be quite favourable towards supporting native types for non-x86 processors, these themselves would need a reserved space to fall into, which leads me onto the second topic in this subject, vendor types support in D.

[1] http://forum.dlang.org/post/gnxgxasvacgblwqjnjeg@forum.dlang.org
[2] http://forum.dlang.org/post/cftnob$1e11$1@digitaldaemon.com
[3] https://github.com/D-Programming-Language/dmd/commit/2e70bcac262e879769f3236a05ce9bc46483a429

=== B ===

Now, I realise that I may be misquoting Walter here, and on re-reading the discussion in which I will *QUOTE* from *OUT OF CONTEXT* [4], it certainly seems that when he refers to the word 'native', he actually means 'x87'.  But if he wants to use that argument to defend native x87, I'll use the same argument to fight for native non-x87.

**BEGIN QUOTE TAKEN OUT OF CONTEXT**
D is a systems programming language, and ought to give access to the native data types supported by the CPU.
**END QUOTE TAKEN OUT OF CONTEXT** [5]

Alright, so my train of thought goes as follows:
- We have D support on ARM.
- ARM supports natively the half-float type, and what with D being a systems programming language, it ought to give access to this native data type.
- We can't use it in extern(D) code unless it is given an appropriate mangle code that doesn't cause conflicts with other types.

So here's where TypeVendor or TypeExtended comes in.

From a grammar point of view, there are two choices:

TypeVendor:
	Q Alpha

So we could define halffloat as being 'Qh', this gives us the ability to add up to 52 additional types (which is ok).

or

TypeVendor:
	Q Number Name

So we could define halffloat as being 'Q1h' or 'Q2hf', this gives us the ability to add an arbituary number of types into the system (which is better).


So what support would be beneficial from allowing compilers to extend the native type-system?  Other use-cases that come into mind:

- float80: For those who *strictly* want to use an 80-bit type on x86 (on GDC for instance, real can vary in size).
- float128: For those who *strictly* want to use an 128-bit type on x86 (on GDC, you can use -mlong-double-128bit, at the risk of breaking ABI).
- PowerPC has 'vector bool' and 'vector pixel' types that don't quite fit into D's existing vector support.
- Haven't looked into ARM Neon/Poly vector types enough to see if they warrant any specific distinction from normal D vectors, I suspect no.
- 24-bit float, though maybe not...

[4] https://github.com/D-Programming-Language/druntime/pull/863#issuecomment-49096430
[5] There, I hope I have my back covered with all the BIG WARNING TEXT. ;)


That pretty much ends my Sunday rambling, destroy.

Regards
Iain

Iain Buclaw:

> BigInt is certainly on the cards for making native 128-bit support possible, but it still needs to be set apart from global and function symbols.  For that, it needs to finally be given a mangled identifier.

Is a mangled identifier also useful for partially library defined checked integrals (currently 4 types)?

Bye,
bearophile

On Sunday, 27 July 2014 at 13:17:42 UTC, Iain Buclaw wrote:
> Now we have DDMD approaching fast round the corner, with it comes the prospect of leveraging the many library types in D for use in the compiler frontend; BigInt, CustomFloat, HalfFloat;

I would point out that every time I've seen compiler devs discuss using Phobos in dmd, there has been a large reluctance to do so (if not outright a desire to avoid it entirely) in order to avoid the circular dependencies that would ensue (Daniel Murphy in particular really doesn't seem to like the idea). It's much easier to control what's going on with dmd if it doesn't rely on Phobos. So, while it may very well be that ddmd eventually uses Phobos, I suspect that you have an uphill battle in trying to make it happen. It's more likely that ddmd would end up with some simplified copies of the necessary functionality from Phobos within its own source code in order to avoid any such dependencies.

- Jonathan M Davis

On 27 July 2014 14:35, bearophile via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> Iain Buclaw:
>
>
>> BigInt is certainly on the cards for making native 128-bit support possible, but it still needs to be set apart from global and function symbols.  For that, it needs to finally be given a mangled identifier.
>
>
> Is a mangled identifier also useful for partially library defined checked integrals (currently 4 types)?
>

I think not, and my reason for saying that is the mess of mangling C++ namespace std has on ABI.

Library types shouldn't be given special mangling treatment IMO.

Regards
Iain

On 28 July 2014 07:08, Jonathan M Davis via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> On Sunday, 27 July 2014 at 13:17:42 UTC, Iain Buclaw wrote:
>>
>> Now we have DDMD approaching fast round the corner, with it comes the prospect of leveraging the many library types in D for use in the compiler frontend; BigInt, CustomFloat, HalfFloat;
>
>
> I would point out that every time I've seen compiler devs discuss using Phobos in dmd, there has been a large reluctance to do so (if not outright a desire to avoid it entirely) in order to avoid the circular dependencies that would ensue (Daniel Murphy in particular really doesn't seem to like the idea). It's much easier to control what's going on with dmd if it doesn't rely on Phobos. So, while it may very well be that ddmd eventually uses Phobos, I suspect that you have an uphill battle in trying to make it happen. It's more likely that ddmd would end up with some simplified copies of the necessary functionality from Phobos within its own source code in order to avoid any such dependencies.
>

I was fairly reluctant initially given Phobos' track-record.  However someone did point out that if we don't use Phobos in DDMD, we might as well apply the brakes now to the project before its allowed to set sail.

Iain.

On 28 July 2014 07:24, Iain Buclaw <ibuclaw@gdcproject.org> wrote:
> On 28 July 2014 07:08, Jonathan M Davis via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>> On Sunday, 27 July 2014 at 13:17:42 UTC, Iain Buclaw wrote:
>>>
>>> Now we have DDMD approaching fast round the corner, with it comes the prospect of leveraging the many library types in D for use in the compiler frontend; BigInt, CustomFloat, HalfFloat;
>>
>>
>> I would point out that every time I've seen compiler devs discuss using Phobos in dmd, there has been a large reluctance to do so (if not outright a desire to avoid it entirely) in order to avoid the circular dependencies that would ensue (Daniel Murphy in particular really doesn't seem to like the idea). It's much easier to control what's going on with dmd if it doesn't rely on Phobos. So, while it may very well be that ddmd eventually uses Phobos, I suspect that you have an uphill battle in trying to make it happen. It's more likely that ddmd would end up with some simplified copies of the necessary functionality from Phobos within its own source code in order to avoid any such dependencies.
>>
>
> I was fairly reluctant initially given Phobos' track-record.  However someone did point out that if we don't use Phobos in DDMD, we might as well apply the brakes now to the project before its allowed to set sail.
>

And I can say (as of writing):

- Me and Daniel did discuss using a library-defined float-point type
in DDMD at DConf 2014
- Daniel is considering the use of BigInt for integer operations in DDMD.

Both will need work for support.  But it is not something that is being ignored.

Iain

"Jonathan M Davis"  wrote in message news:lfhsrrkauworheqmedhm@forum.dlang.org...

> I would point out that every time I've seen compiler devs discuss using Phobos in dmd, there has been a large reluctance to do so (if not outright a desire to avoid it entirely) in order to avoid the circular dependencies that would ensue (Daniel Murphy in particular really doesn't seem to like the idea).

Yes, and I'm still against it.  It's not about the circular dependency (that already exists with druntime and is manageable) it's that including phobos effectively massively increases the size of the dmd codebase.  Phobos is also tied to the release cycles in a different way than it looks like ddmd will be.  Druntime is much smaller and much less worrying (and impossible to avoid). 

"Iain Buclaw via Digitalmars-d"  wrote in message news:mailman.95.1406528707.16021.digitalmars-d@puremagic.com...

> I was fairly reluctant initially given Phobos' track-record.  However
> someone did point out that if we don't use Phobos in DDMD, we might as
> well apply the brakes now to the project before its allowed to set
> sail.

There are a huge number of nice things in D that you don't need phobos for. 

"Iain Buclaw via Digitalmars-d"  wrote in message news:mailman.96.1406529001.16021.digitalmars-d@puremagic.com...

> And I can say (as of writing):
>
> - Me and Daniel did discuss using a library-defined float-point type
> in DDMD at DConf 2014
> - Daniel is considering the use of BigInt for integer operations in DDMD.
>
> Both will need work for support.  But it is not something that is being ignored.

I am considering using BigInt, but my position on using phobos has not changed.

Being (mostly) self-contained is one of the nicest things about dmd's codebase, and I don't want to lose that. 

On Sunday, 27 July 2014 at 13:17:42 UTC, Iain Buclaw wrote:
> The cent and ucent keywords have been reserved since... well... certainly before the first D1 (as opposed to D0.xx) release [2].  But that's all they have ever seemed to be.  Just reserved keywords that give odd errors when you try to use them.
Yes, I truly wish those would be supported - not only to use them directly, but at least as fallback for e.g. safe multiplication (cent x = long * long; if(x > long.max) throw exception;)
From the language reference I had strongly expected that cent and ucent are supported - a look into phobos destroyed that hope :-/