From: | "Tony" <tony@my.net> |
Newsgroups: | comp.compilers,comp.arch |
Date: | Fri, 5 Dec 2008 02:04:30 -0600 |
Organization: | at&t http://my.att.net/ |
References: | 08-12-014 08-12-016 |
Keywords: | architecture, OOP |
Posted-Date: | 05 Dec 2008 10:17:04 EST |
"bert" <bert.hutchings@btinternet.com> wrote in message
> On 4 Dec, 18:09, "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 implemention of OO languages easier? (Not just necessarily the
>> function thing, but anything).
>
> I don't know about new ones, but how about resurrecting some old ones?
> At least two different computers of the 1960's had an 'indirect' bit
> at the high end of an address word, meaning that it pointed to another
> word containing an address. In its turn, that might have the high bit
> set, etcetera. An instruction to load a datum or an address would
> follow such a chain of indirections until it reached the
> actually-wanted item. I know this was very good for Prolog
> implementations.
OK, good. My mind immediately thought about vptrs after reading that, but I
have a feeling it won't help with what I am trying to do. I am fuzzily
thinking about (from time to time) whether there is a way to avoid vptrs in
objects or some better way of implementing polymorphism (especially or at
least for "interfaces").
(Aside, I'm *starting* to understand assembly language!). :)
> [Indirect addressing was quite common through the 1970s. The PDP-11
> and VAX had it. But I gather that it's a challenge to implement
> efficiently, and if the machine has a lot of registers, it doesn't gain
> you much. -John]
I don't like just pushing complexity to another level in general, but
I'm not sure if I feel that way about it if it gets pushed all the way
to the assembly, machine or hardware level. (?) Probably though.
Tony
Return to the
comp.compilers page.
Search the
comp.compilers archives again.