[ABI] 128bit integers and other vendor types

[Iain Buclaw via Digitalmars-d]

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