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
