OOP, и это облегчает разработку?

1>> машина является стековой, причем стек является статически типизированным; это означает, что в каждой точке программы JIT-compiler должен иметь возможность статически определить типы содержимого всех ячеек стека.

2>>На практике это означает, например, невозможность написать код, кладущий в цикле значения на стек

из 1 не следует 2. Можно завести, например, несколько типизированных стеков, каждый своим типом и запросто "ложить значения на стек"

> Stack-based vs register-baseed - это древний холивор :)

и на каком консенсусе сошлась мировая мысль? Мне чисто умозрительно с трудом представляется реальная железная архитектура (кроме спарков с регистровыми окнами или чего-то подобного), на которой стек может работать быстрее регистров.

>>> 2. когда реально нужно множественное наследование, в каких ситуациях.

> Если "нужно" значит "выгодно", то это случаи, когда объединяются 2 иерархии.

но не 2 произвольных иерархии, так? с интерфейсами -- понятно, речь о нормальных неабстрактных классах.

Чтобы например одинаковые методы не перекрывались. То есть, есть иерархии, которые объединять полезно, и которые сложно/бесполезно. То есть, возникает паттерн, который можно применять когда это полезно (и антипаттерн, когда МН применять не нужно).

То есть, если эту штуку (МН) делать в рантайме, возникает какой-то паттерн, алгоритм, интерфейс в MOP (или аспектах), когда это МН имеет смысл

> Опять же, определи, что значит "нужно".

да просто хочется определить, когда нужно множественное наследование классов, так чтобы без него прям совсем никак, всё сложно было. Нормальных классов, не интерфейсов/шаблонов/поведения.

Вот множественное наследование экземпляров в ООБД нужно, если отношения не сильно тривиальные. Потом иногда удобно считать, что объект принадлежит сразу нескольким разным типам (смотреть на один и тот же объект с разных точек зрения, какой лучше подходит в данный момент)

А point был в том, что часто наследование лепят куда не надо вместо агрегации, вот и МН в том числе тоже. (может правда, хотят полиморфизмом воспользоваться нахаляву, унаследованным классом вместо базовых(всех перечисленных)) Вот и определить паттерн, когда его стоит применять, а когда не стоит.

> множественное наследование - это признак неправильно спланированной иерархии.

тут согласен (в большинстве случаев а не 100%)

>Одно наследование реализации и множество интерфейсов - это каноническое правило.

тут несогласен. Во-первых, МН интерфейсов -- это то же МН абстрактных базовых классов (без членов). Вот с классами с членами в статике и с экземплярами в динамике -- не всё ясно, зачем эта фича нужна, в каких случаях без неё прям жизни нет.

> Но и "правильное" "планирование иерархии" в ООП ИМХО утопия. Боле того, оно просто ошибочно, типа веры в то, что любое алгебраическое уравнение можно решить в радикалах: и не нужно, и не так.

получается, есть случаи когда уравнение хорошо решать в радикалах, а когда -- по другому. То есть, аналогично, раз глобально, навека спланировать иерархию не удастся, значит, полезно иметь возможность посмотреть на ту же иерархию в другом ракурсе (или выстроить новую). Аспектами, рефлексией, MOP. А вот каким боком тут Мн. наследование может пригодиться?

> MS сама говорит, что они создали VM, учитывающую специфику именно Windows.

интересно, и в чем же там специфика именно виндовз? что CreateThread выполняется быстрее CreateProcess и форка нет?

> LLVM - регистровая машина. Компилить под неё всё же несколько труднее чем под стековую. Ну да поскольку компиляторов ты не писал никогда, таких тонкостей ты тоже не понимаешь.

а тебе надо чтобы быстро компилятор написать или чтобы VM работала эффективнее? Покажи мне реальный процессор, в котором стек работает быстрее регистров

>> Stack-based vs register-baseed - это древний холивор :)

> и на каком консенсусе сошлась мировая мысль?

В холиворах не бывает консенсуса. Пока что стековые ведут по очкам - собственно, кроме Parrot (и вроде LLVM?), я и не знаю регистровых VM.

> Мне чисто умозрительно с трудом представляется реальная железная архитектура (кроме спарков с регистровыми окнами или чего-то подобного), на которой стек может работать быстрее регистров.

Для стековых несколько проще писать компиляторы.

> да просто хочется определить, когда нужно множественное наследование классов

Определи, тебе будет благодарна куча народу. Я такого критерия не знаю.

> с регистровыми же машинами вообще абзац, отображение одного набора регистров на другой - задача вычислительно крайне тяжелая.

вроде процессоры уже сами умеют переименование регистров ?

> собственно, кроме Parrot (и вроде LLVM?), я и не знаю регистровых VM.

трехадресная Dis в Inferno.

>да просто хочется определить, когда нужно множественное наследование классов, так чтобы без него прям совсем никак, всё сложно было.

Строуструпа не читал (чего его читать?), но у него вроде бы есть один пример с "TemporarySecretary" где он сам для себя решил что MH в С++ - быть.

В <iostream> используется даже ромбическая иерархия - std::istream и std::ostream виртуально наследуются от std::basic_ios. А std::iostream множественно наследуется от их обоих.

>OOP, и это облегчает разработку?

Неуч. Виски облегчает разработку. man "Пик Баллмера". WOP в массы!

Никто не мешает JIT-компилировать из стековой в регистровую. Собственно, так все JIT-ы и делают.

> Никто не мешает JIT-компилировать из стековой в регистровую. Собственно, так все JIT-ы и делают.

Да, только вот на сколько оптимально (особенно в плане быстродействия получаемого кода) JIT-компиляция использует (не при самой компиляции, а в выходно коде) _все_ регистры "хостового" процессора (особенно если он какой х64)?

Серьёзно я этим вопросом займусь летом, но по-моему вполне эффективно. Хотя лучше почитайте научные работы, их вроде хватает.

> Серьёзно я этим вопросом займусь летом, но по-моему вполне эффективно. Хотя лучше почитайте научные работы, их вроде хватает.

Я не работы хочу сразу начать читать а для начала увидеть конечный результат, подтверждающий полноценное использование всех регистров jitc какой-либо vm :)

> увидеть конечный результат, подтверждающий полноценное использование всех регистров jitc какой-либо vm :)

.NET использует AOT, найди его native code экзешники и посмотри :)

> .NET использует AOT, найди его native code экзешники и посмотри :)

А .NET "чисто"-стековая VM без виртуальных регистров?

> А .NET "чисто"-стековая VM без виртуальных регистров?

Да.

picojava может довольно быстро работать (за счёт кольцевого стека в процессоре и склеивании стековых команд в RISC).
Но про него давно ничего не слышно

http://www.osp.ru/os/1999/01/179635/

Ну из того что нарыл "поверхностно" - таки да, заявляется что регистры используются "по полной" :)

P.S. Дождаться завтра релиза llvm и посмотреть как там обстоят дела :)