Re: New assembly language instructions to support OO languages?

On Dec 4, 8:09 pm, "Tony" <t...@my.net> wrote:
> To me, it seems like "reducing everything to a function" may be a bit
> dated given that OO languages are the thing nowadays. Can anyone
> imagine any new potential assembly language instructions that would
> make implementation of OO languages easier? (Not just necessarily the
> function thing, but anything).


    Well, when I learned OO, a method was thought as a message sent to
an object, not a function!-)


    I do not see any connection between easy compilation of OO languages
and machine instructions - creating the actual code is one of the
easiest parts of a compiler. If you mean making the OO programs run
faster, a different memory model can help very much.


    In C++ we deal with a lot of very short chunks of memory, many of
them independent. We can replace the standard flat memory access and
cache lines with constant size with segmented memory and cache lines
of different sizes. Thus, we wouldn't have too much "garbage" in the
cache, and in addition we'll have much better memory protection. This
means that the "new" operator will receive a ptr to a segment of given
size (probably using a machine instruction), any access to a part of
an object/array will use segment and offset, and in addition to the
page table and TLB the processor will have the segment table and
segment cache. Note that the processor can use the free segment cache
to allocate new memory segments.


    This means that you can add two instructions:


    get_mem Base_addr, size ; allocates a segment of 'size'
bytes
    delete_mem Base_addr ; deletes a segment


    Now, on every access to memory the processor can check if the access
is off segment when it computes the "real" address. In addition, if we
keep the physical addresses in the segment table, we can use the page
table "offline" and remove the TLB from the processor. When a page is
swapped out, all its segments have to be invalidated.


    I understand that some ancient computers (in the 2nd millennium)
used segmented memory. If we could implement this and show that it
runs most of the programs faster, somebody would be able to build such
a processor. Unfortunately, for "scientific" computations (PDEs,
matrices) the flat memory model might be more efficient. From the
other side, having a possibility to define smaller or larger segments
can also help to matrix multiplication etc. - with larger segments
much more memory will be preloaded on sequential access.


    Michael

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