D design problem on platforms with <32 bit pointer width

[Walter Bright]

Thanks for taking the time to sum up the issues.

I have a ton of experience with 16 bit code. Abandoning it was an explicit 
decision for D, mainly to make code portable. Writing code that was portable 
between 16 and 32 bit was always a major effort for non-trivial code. 
Fortunately, these days, porting between 32 and 64 bit is trivial.

Some things are impractical for 16 bit code:

1. exception handling
2. garbage collection
3. typeinfo
4. classes (unless using the far memory model)
5. likely the bulk of druntime

I.e. sticking with betterC is more practical.

Some things are impractical for D:

1. mixed near/far pointers

It's fine if a D targeted at 16 bit code has somewhat different semantics. I 
oppose changing the semantics of 32/64 bit D, as it would break everything.

32 bit integer arithmetic is going to be too slow and consume too much code 
space, likely unnecessarily.

You correctly identified integer promotion as the cause of most trouble.

So, I propose the following modification for 16 bit code generation:

Keep integer promotion, but have it promote to short rather than int. I haven't 
thought about it deeply, but first impression says that it will resolve most of 
the issues.

This will require changing many of the ints in the source code to shorts. How 
onerous that would be, I do not know. One could do something like:

     version (SixteenBit)
         alias xint = short;
     else
         alias xint = int;

which would make the source code more portable, but keep in mind that integer 
overflow in the 16 bit world is a major source of unintended problems. 32 bit D 
code converted to 16 bit will need a thorough review.

Programs targeted at 16 bits are, naturally, going to be small programs. I doubt 
many D programs are that small. So there shouldn't be too much source code that 
needs modifying.

Anyhow, it seems like a fun project you're working on!