Probably if you haven't heard of CHERI and can't be bothered to Google it when one of the most respected systems architects around tells you it's worth looking at, you aren't going to put in the effort needed to read the CHERI tech reports so you can have an informed opinion on the performance cost of putting this kind of protection into hardware. And if the only historical "OO" processors you can think of are Rekursiv and iAPX432, and not the Dorado or the Symbolics line or the B5000/B5500/ClearPath line, it sounds like you have a lot of reading to do to get to having an informed opinion.
The Symbolics 3600, the B5000, and the Smalltalk microcode for the Dorado all had generic operation dispatching in hardware, though they varied in how flexible it was. The iAPX432 and the Rational R1000, as far as I can tell, didn't. Generic late-bound operation dispatching is the essential core of OO.
For many years AMD64 CPUs have had hardware acceleration for this sort of thing in the form of a "branch target buffer", so in this very important sense they're more OO than the iAPX432, though they don't have the hardware bounds-checking and dynamic type checking that all of the other architectures we're discussing did.
Of these, only the Smalltalk microcode for the Dorado came close to the level of hardware support for OO that something like SiliconSqueak has.
You're just repeating buzzwords rather than taking the time to understand what they refer to.
> The Symbolics 3600, the B5000, and the Smalltalk microcode for the Dorado all had generic operation dispatching in hardware
Regarding the symbolics, that seems highly unlikely as lisp is not an object oriented language unless the MOP is draped over it (which is multi-dispatch IIRC and that's not going into hardware). Please provide some links to show I'm wrong.
> The iAPX432 and the Rational R1000, as far as I can tell, didn't.
"9.4.2 Procedure Call and Context Objects
To transfer control to a procedure, a program executes a
CALL instruction, causing the procedure to be invoked. On exe-
cution of a CALL instruction, the hardware constructs a new
context object. The context object is the procedure invocation
record and defines the dynamic addressing environment in
which the procedure executes. All addressing of objects and
scalars occurs through the context object, and the context is
the root of all objects reachable by the procedure."
Oh give me a break, this is just branch prediction and a little caching, it's nothing to do with OO/dispatch because there is no generic dispatch involved. It's just an optimisation for normal dispatch, nothing else. If you don't understand what a branch predictor actually does... ech
> Dorado
I'm not familiar with Dorado, can you provide a link showing this and preferably a bit more information as well actually stating this clearly.
> You're just repeating buzzwords rather than taking the time to understand what they refer to.
I do get tired of HN, I come to learn, I get dragged down by clammy seaweed posts like this, just claims, no concrete anything ("as far as I can tell"), from people who know even less than me ("Generic late-bound operation dispatching .... For many years AMD64 CPUs have had hardware acceleration for this sort of thing in the form of a 'branch target buffer' OMG just stop talking). Don't lecture me until you can deliver the goods, then and only then, lecture away because then I'll be listening.
> Regarding the symbolics, that seems highly unlikely as lisp is not an object oriented language
The Symbolics Genera operating system is largely written in object-oriented style using the Flavors OO-extension. Since the early machines had a micro-programmable CPU, there were with new operating system releases also new CPU extensions to support new Lisp, OOP or logic language (Prolog) features.
Beyond that: Lisp originally used 'generic operations' in a non-OO sense. For example the + operation works for all the kinds of numbers (integer + integer, float + float, integer + float, integer + complex, ... and so on). The CPU determines at runtime which operation runs. Thus there is only one generic ADD instruction and not per-type instructions.
"Dynamic addressing environment" in this context refers to the stack frame in which the procedure stores its local variables (and which may contain, for example, a link to the stack frame of an enclosing procedure, as in Pascal). Lots of things can be dynamic, which is to say, determined at run-time; method dispatch is just one of them. This is a good example of you repeating buzzwords without understanding what they refer to, although in this case the buzzword is also a technical term with a precise meaning.
Intel liked to use the term "object-oriented" to describe the iAPX432 because it was fashionable, but their idea of "objects" was more like CLU "clusters" as filtered through Ada, not the Smalltalk approach the term "object-oriented" was invented to describe.
You're also confusing CLOS and Flavors with CLOS's MOP.
> If you don't understand what a branch predictor actually does...
Possibly in five or ten years if you read this conversation again you will be in a better position to learn from it; right now you seem to be too full of ego to take advantage of the opportunity. Save a bookmark and maybe put a reminder in your calendar.
> Please provide some links to show I'm wrong.
Helping you stop being wrong is not really my responsibility :)
You're treating knowledge as a repulsive medicine that needs to be forced on you, not a precious treasure that merits seeking out. The problem with this is that if you only change your mind when it's profitable for someone else to talk you out of your mistakes, you'll just end up being exploited (and continuing to parrot half-understood nonsense in technical discussions). It isn't society's responsibility to give you the cognitive tools you need to realize your potential; it's yours.
How would you suggest rephrasing a complete, sweeping dismissal of someone's comments, on the basis that they evidently have no relevant knowledge, so that it doesn't come across as rude?
I took a bad situation and made it worse. I have reasons but it shouldn't have happened. I am not happy that I clearly and unnecessarily annoyed you, and would prefer that we put out this fire and move on with a better mood for both of us, and hopefully I can do better next time.
