captain cobalt написал(а) ...

Я протестую лишь против приведённых примеров, которые являются примером неправильного проектирования (например прибавление единицы к произвольному объекту).
При таком подходе из-за ошибок программирования может возникать "неожиданный полиморфизм" (бич некоторых языков программирования) - ситуация, когда корректная операция применяется к корректному объекту и вызывает некорректный (возможно, разрушительный) результат.

captain cobalt написал(а) ...

Разумеется, ответ зависит от предположений насчёт языка программирования. Возможны следующие предположения:

1. Язык программирования поддерживает перегрузку операторов - синтаксический сахар над вызовами методов, в данном случае оператор инкрементного сложения.
1.1. Язык программирования требует, что тип Object, являющийся подразумеваемым базовым суперклассом всех других классов бла-бла-бла...
1.2. Язык использует динамическую типизацию. бла-бла-бла...
1.3. Язык использует статическую типизацию. бла-бла-бла...
2. Язык не поддерживает перегрузку операторов. бла-бла-бла...

captain cobalt написал(а) ...
Про "формирование адресной части команд" до сих пор ничего не понятно.
Например?

captain cobalt написал(а) ...

Одна проверка типа == одно сравнение - весьма немного.

captain cobalt написал(а) ...

Разумеется, это должна делать программа. Тогда процессор может быть проще, и, следовательно, может быть сделан быстрее, что приведёт к общему повышению производительности.

captain cobalt написал(а) ...

Возьмём, например, E2K.
Разработчики утверждают, что EPIC/VLIW должен вытеснить суперскаляры.
Суперскаляры - это машины которые динамически аппаратно во время выполнения выполняют instruction scheduling - выбирают подходящий порядок исполнения инструкций, меняют их местами и т. п. Это требует вычислительных ресурсов и серьёзно препятствует повышению параллелизма.
В EPIC/VLIW машинах instruction scheduling, в том числе распараллеливание, выполняет компилятор (естественно программно).

Вот оно будущее - очень быстрая и очень "тупая" машина с массовым параллелизмом и "умный" компилятор.
Осталось только взять с собой "умный" язык программирования.
И Bluebottle.

Rygoravich написал(а) ...
2Dron: а идейка действительно любопытная . Использовать время простоя процессора для самообучения...

Rygoravich написал(а) ...
Фактически в этом случае будем иметь ИИ...

batu написал(а) ...
Вопрос то без ответа. На ассемблере представили такой кусок программы? Какая команда должна применятся? Что на месте адресов операндов в команде должно стоять? Или там много команд должно сгенерироваться? И куча команд для проверки типа, а потом в зависимости от типа данных разные команды? А если допускается перегрузка операторов еще и вызов процедуры с перегруженым оператором. Правильно? Это сколько команд для выполнения получается? А теперь вдумайся в мое предложение проверять типы на этапе выполнения (в случае если они не были проверены и не сформирована адресная часть операндов на этапе 0-выполнения при компиляции и тогда ничего по скорости не теряется.) . Вместо вот этой кучи команд формируется только одна! Вдумался. И не обязательно это должна быть новая архитектура машины. Все это прекрасно можно эмулировать на любой машине генерала Фон Неймана. Что я и делаю сейчас.

batu написал(а) ...
Я не канонизирую E2K. но там есть интересные моменты. Например, память при выделении очищается, и при записи данных в ячейку устанвливатся аппаратно бит с признаком наличия данных. Таким образом, при обращении для чтения к отсутствующим данным возникает ошибка. Программное решение этой проблемы гораздо сложнее, требует массу ресурсов, и я не знаю надежного решения (может вы в курсе?).

batu написал(а) ...
Второе-Там реализован аппаратно механизм програмирования последовательности выполнения команд процессорами. И программы перетранслируются на разное число процессоров. Без этого механизма добавленияе процессоров не эффективно в общем случае. Конечно молотить скаляры и матрицы на многопроцессорной машине приятно, но усилия затраченые на програмирование такого "обмолота" я считаю слишком велики. Решение E2K этого вопроса считаю весьма удачным.

Vadim Ushakov написал(а) ...
Если же говорить о сильнотипизированных языках, то вот вполне конкретный ответ на ваш вопрос:

/* "мать всех объектов" с заглушками чисто-виртуальных методов */
class BaseObject{
public:
// bla-bla-bla
virtual BaseObject& operator+=(const BaseObject&) = 0;
// bla-bla-bla
private:
// bla-bla-bla
};
/* реализация интерфейса BaseObject */
class A1 : public BaseObject{
public:
virtual BaseObject& operator+=(const BaseObject&){
// bla-bla-bla
return *this;
}
};
void main(void){
BaseObject *obj1 = new A1(), *obj2 = new A1();
*obj1 += *obj2;
delete obj1, obj2;
}

Вот, собственно и все. НИКАКИХ проверок типа во время исполнения не производится. Только переход по v-таблице и вызов переопределенного метода. Честно говоря, здесь только половина решения, поскольку при вызове метода operator+= класса A1 нам известен только тип левого операнда. Потом мы используем двойную передачу (double dispatch) и узнаем точный тип второго операнда. Итого два перехода по v-таблице.
Если вам так уж важно "на ассемблере представить такой кусок программы", то вот что мне выдала IDA:
mov edx, [ebp+var_24]
mov [ebp+var_14], edx
mov eax, [ebp+var_14]
mov [ebp+var_8], eax
mov ecx, [ebp+var_8]
push ecx
mov edx, [ebp+var_4]
mov eax, [edx]
mov ecx, [ebp+var_4]
call dword ptr [eax]

Vadim Ushakov написал(а) ...

А обращения к нулевому указателю легко отлавливаются такими средствами аппаратуры, как страничная защита. И тоже нет никаких проверок во время исполнения.


А вот об этом впервые слышу. Можно поподробнее? Что это такое и с чем его едят.

Dron написал(а) ...
У-у-у... куда меня занесло...
То есть программирование превратиться в правильную постановку задачи.