Fantastic exchange from DConf

[Johannes Pfau via Digitalmars-d]

On Thursday, 18 May 2017 at 08:24:18 UTC, Walter Bright wrote:
> On 5/17/2017 10:07 PM, Patrick Schluter wrote:
>> D requires afaict at least a 32 bit system
>
> Yes.
>

You've said this some times before but never explained why 
there's such a limitation? I've actually used GDC to run code on 
8bit AVR as well as 16bit MSP430 controllers.

The only thing I can think of is 'far pointer' support, but the 
times have changed in this regard as well:

TI implements 16bit or 20bit pointers for their 16 bit MSP 
architecture, but they never mix pointers: [1]

> The problem with a "medium" model, or any model where size_t 
> and sizeof(void *)
> are not the same, is that they technically violate the ISO C 
> standard. GCC has
> minimal support for such models, and having done some in the 
> past, I recommend against it.

AVR for a long time only allowed access to high memory using 
special functions, no compiler support [2]. Nowadays GCC supports 
named address spaces [3] but I think we could implement this 
completely in library code: Basically using a type wrapper 
template should work. The only difficulty is making it work with 
volatile_load and if we can't find a better solution we'll need a 
new intrinsic data_load!(Flags = volatile, addrSpace = 
addrspace(foo),...)(address).


Then there's the small additional 'problem' that slices will be 
more expensive on these architectures: If you already need 2 
registers to fit a pointer and 2 for size_t a slice will need 4 
registers. So there may be some performance penalty but OTOH 
these RISC machines usually have more general purpose registers 
available than X86.

[1] 
https://e2e.ti.com/support/development_tools/compiler/f/343/t/451127
[2] http://www.nongnu.org/avr-libc/user-manual/pgmspace.html
[3] https://gcc.gnu.org/onlinedocs/gcc/Named-Address-Spaces.html

-- Johannes