Re: New assembly language instructions to support OO languages?

Louis Krupp wrote:
(snip)


> As I understand it, Unisys MCP machines use a version of the segmented
> model that Burroughs Large Systems have used for over 40 years. Arrays
> are indexed through descriptors that hold the array size and the address
> of the first element. Link words on either side of the array are tagged
> so that user programs can't access them. This is all part of the
> overall model (no assembler, all object programs must be produced by a
> trusted compiler).


I used to do this with OS/2 1.2 (and even 1.0 before that). The
addressing mechanism is segment selector and offset into the segment.
Normal malloc() would allocate segments and return a selector and
offset. Instead, I directly allocated a segment from OS/2 with the
exact length needed and offset of zero. This was very useful in
debugging array access when compilers didn't do bounds checking.
(That was in C, and even now it is hard to find compilers that will do
bounds checking for C pointers.)


Two dimensional arrays are arrays of pointers (usual in C) such that
the individual arrays weren't larger than 64K. That was plenty big
enough at the time.


I believe the WATCOM compilers will generate large model 32 bit code
(16 bit segment selector and 32 bit offset) but I don't know any OS
that supports code like that.


That would have allowed access to over 4G of address space if intel
hadn't followed that logic by a 32 bit wide MMU. With 32 bit offsets,
the segmented model isn't so bad. (Also, a segment descriptor cache
to speed up loading of segment registers would have helped.) If it
had been done right, it could have delayed the need for 64 bit
processors by some years.


Then again, recently there were Itanium 2 machines with 10GB of RAM on
eBay for $100. They will probably be back, it seems that someone has
many of them to sell.


Itanium, a nice challenge for writers of code generators...


> I wouldn't expect this to do much for performance, but it goes a
> long way to provide a more secure computer. Just think, no buffer
> overruns...


Yes. That would be nice.


-- glen

Return to the comp.compilers page.
Search the comp.compilers archives again.