[fpc-devel] Re: fpc-devel Digest, Vol 94, Issue 14

[steve smithers]

> Hans-Peter Diettrich <DrDiettrich1 at aol.com> wrote on Tue, 07 Feb 2012 09:12:53 +0100
> 
> > Base / Displacement consists of a 16 bit value, the first 4 bits enumerate a
> > register, and the other 12 bits hold a displacement from 0 to 4095. The actual
> > or Effective address for each storage operand is calculated as the unsigned
> > addition of the value held in the base register to the displacement from the
> > instruction itself.
> 
> This reminds me of 8086 "real" mode, and 16 bit mode with (far) 
> addresses splitted into segment:offset. Using an 16 bit compiler and 
> syntax (near/far pointers and seg:off notation) would be easier to 
> support a segmented-memory architecture. I also don't see right now how 
> data structures > 4KB could be addressed, without subroutines to map 
> virtual into physical (here seg:off) addresses.

There are certain similarities, but System 360  onwards are true 32-bit
processors.  It's compilers, and there must be hunderds of them by now
are 32-bit compilers.  (Probably 64 bit too, I have never worked on the
64 bit types, so I don't know)

Data structures -> see episode 5!
 
> When I had a first look at the 8086 CPU, decades ago, I didn't 
> understand how to handle such a memory architecture in an compiler. Only 
> when I came across the Microsoft compilers and their memory models, I 
> saw how "hints" in the source code would allow an compiler to create 
> efficient machine code. But all these syntax externsions have been 
> stripped from nowadays compilers and languages, so that it will be very 
> hard to support such a dinosaur architecture in an 32/64 bit compiler.

These systems have had had 32 bit compilers since the mid 1960's, it's not
rocket science, just computer science.  A version of C was implemented on 360
machines at Bell Labs long before it became a portable system.  The architecture 
produces problems, but these are surmountable.  I won't have answers to
everything;  I don't know enough (actually hardly anything) about the internals
of the FreePascal code generator.  I am confident enough in my abilities to
know that these items are soluble;  After all VS/Pascal solved them;  GCC
solved them (and there is a version of GCC available for 370 processors) etc