From: alexfrunews@gmail.com   
      
   On Friday, April 22, 2022 at 1:41:02 PM UTC-7, muta...@gmail.com wrote:   
   > On Saturday, April 23, 2022 at 2:25:13 AM UTC+10, Alexei A. Frounze wrote:   
   >   
   > > One typical solution is to split the compiler into several   
   > > stages, each executing the other as a separate program   
   > > with the communication between them done via files   
   > > containing intermediate results.   
   > Ok, but that requires the programmer to change the   
   > way they program, because the code they would   
   > naturally write exceeds 64k of machine code.   
      
   Correct.   
      
   > My question is - is the 8086 the only processor that   
   > still has 16-bit registers, but allows the naturally-written   
   > program with more than 64k of machine code, to   
   > be built by a compiler?   
   >   
   > Or is there some other technique that would work on   
   > the Commodore 128 or some other machine that   
   > allowed more than 64k of memory with only 16-bit   
   > or 8-bit registers?   
      
   Dunno. There's yet another approach, which I did on a MIPS32   
   microcontroller with just 128KB of RAM. I made a small   
   MIPS32 emulator that demand-loads portions of the large   
   code section, caches them, and emulates the cached code.   
   Virtual memory it is.   
   This makes things pretty slow, but not too slow if your CPU   
   runs at about 100 MHz (the microcontroller ran at 80 MHz)   
   and you do those things relatively infrequently (which compiling is).   
      
   In principle, you could introduce a wider "virtual" IP/PC (or   
   introduce fake 8086-like segmentation) to extend the allowed   
   code size beyond 64 KB, and then do something like I described   
   above.   
      
   Btw, Smaller C's huge memory model supports code size   
   larger than 64 KB, the only restriction being that individual   
   subroutines each fit into 64 KB. With this every C function   
   resides in a separate segment and is far-callable.   
   You could turn SubC's pointers into far pointers (and probably   
   make plain ints 32-bit as well as I think the two types are   
   expected to be the same size just as in Smaller C) and solve   
   the problem similarly. IOW, just use far pointers everywhere   
   while restricting individual object and function size to 64 KB   
   (ditto for arrays).   
      
   Alex   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)