Plus all this pointer juggling would have been more or less ok (or not ok, but doable) when programming in assembly, but for a compiler it would have been a recipe for disaster...
I'm sure a modern compiler would have no problem with it, but in 1980 optimizer technology wasn't there yet. Modern compilers use more memory that engineers would dare dream of in 1980.
By having no problem I mean we know enough about writing an optimizer to write such a thing. I don't think any compiler does, just that they could.
I recall turbo (Pascal I guess but I was a kid and this was 40 years ago) having options, small for all in one. Then code and data in different segments, but only one each. Then code in one but multiple data, and finally multitude of both. I probably remember the options a bit off but there is enough to state that compilers could handle segments. Though they didn't optimize it well and so the smallest option was fastest
Turbo Pascal 3.x always had a single code segment, a single data segment, a single stack segment + a heap. Heap allocations were paragraph aligned (ofs=0). All pointers were far pointers.
Turbo Pascal 4.0 and up had one code segment per module (that they called units). It still had a single data segment and a single stack segment + a heap. Heap allocations were still paragraph aligned and all pointers were still far pointers.
Turbo/Borland Pascal 7.0 also supported 16-bit protected mode. I don't know if heap allocations had ofs=0 there.
None of them had "huge" arrays/pointers where pointers can point to things bigger than 64K -- at the cost of a lot of instructions for pointer arithmetic and array indexing.
By having no problem I mean we know enough about writing an optimizer to write such a thing. I don't think any compiler does, just that they could.