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/[email protected]
[2] http://forum.dlang.org/post/[email protected]
[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
