Re: wishlist: support for shorter pointers

[waffl3x <waffl3x@protonmail.com>]

I want to preface this stating that I have little to no experience in compiler
development, I am only merely just getting into it. With that said, I have messed around
with library design a fair amount, and this seems like something that could be
implemented in a library. It might be slightly comfier implemented on the compiler side,
but I question how generally it could be implemented.

>In ARM world, the use of such pointers would require the use of an
>additional register (functionally being a "segment base address") to
>allow for data access using instructions like: "LD Rx, [Ry, Rz]" -
>meaning register index reference.

What you say here makes me feel like you should just be implementing this in
library. With how you're describing it, it seems like the compiler would have no idea
what the "segment base address" would actually be without additional annotation.
Since you would need that annotation anyway, it seems best implemented in library.

I think what you want to do (for 16 bit pointers) is have a struct that
internally is a fixed width 16 bit uint, and have an operator* that sets up the registers
for that particular segment. It would be a bit of an implementation task since you
have to do some inline ASM, but thats just the reality of implementing low level
libraries. Like I said before, and unless I'm mistaken, since the segments would need
annotations anyway, it probably makes the most sense to implement this in library as I'm
describing.
I believe these types would be referred to as "fancy pointers." 

Hopefully I'm not too mistaken as I don't have any experience with this field.
In general though, I believe that if something can be implemented in a reasonable
way in library, then it belongs in library, not in language or other extensions.

-Alex