Multiple address spaces

[cr1901]

I've been seeking a C replacement for my vintage programming (since I don't care much for asm), and I'd at some point to try Cowgol. I've been multitasking a bit too poorly to learn Cowgol lately, especially since it's Ada inspired and I don't actually know Ada. But I figured I'd ask while it's on my mind:

How difficult would it be to support multiple address spaces to Cowgol (with the consequence that two pointers in different address spaces do not compare equal)? My immediate use case is to create 8086/8 binaries with more than 64kB of .text and .data. But other archs such as AVR, 65816, and PIC could benefit too.

Minddump

Don't mind me, this is just me writing down my thoughts for later so I can come back to them :D! None of this is particularly well thought through. I will also do more research for how e.g. Turbo C and Watcom C handle __near, __far, and their absence on pointers, functions, and data, since that precedent exists for "high-level" langs w/ multiple addr space support.

I'm not sure what the syntax for such pointers would look like, but maybe __near and __far would work as reserved words.

• All __near pointers with the same value (offset) would compare equal. The compiler chooses which address space (segment in 8086-land) in which near code, near data, and the near pointers point to.
• All __far pointers would each represent a different address space. You can make a __far pointer and choose the address space (segment) it lives in. If you don't, the compiler chooses for you. __far pointers (including fn pointers) only compare equal if their address space and value (offset) are equal.
• Addresses to far data (i.e. taking the address of globals) don't ever compare equal because the compiler has to choose the address space they live in and the compiler can't know apriori whether two pieces of data will share the same address space.

[davidgiven]

I think this should be relatively doable. There's actually some support for address spaces already, known as workspaces --- the 6502 has three: zero page, normal data, and static data; these are used for allocating variable storage. You can see the 6502 frontend decide which workspace a variable should be in here: https://github.com/davidgiven/cowgol/blob/master/src/cowfe/arch6502.coh#L54

One problem is that the backend distinguishes between types by size alone (which is a known issue). It doesn't know or care whether a two-byte value is a 16-bit pointer or a 16-bit integer. So all near pointers would have to be one size and all far pointers would have to be another size if you wanted them to generate different code. For near pointers, the address space is known at compile time, so the front-end would need to track that, but that's only an extra byte in the PointerType structure: https://github.com/davidgiven/cowgol/blob/master/src/cowfe/types.coh#L25

I'll add that two near pointers to different address spaces can never compare equal; this can be determined statically. They will, in fact, not be type-compatible. Unfortunately the frontend doesn't do structured type comparisons yet, and each value can only have a single pointer type to it --- it's cached in the pointerto variable: https://github.com/davidgiven/cowgol/blob/master/src/cowfe/types.coh#L56

So, I'd say this is doable, but will require a (hopefully small amount) of rearchitecture.