У Агата-7 очень гибко с памятью было. Минимальный объём -- 32 килобайта на материнской плате, но и на ней могло быть больше, и в разъёмы расширения ставились платы допОЗУ и псевдоПЗУ. У нас в школе было не меньше 64 Кбайт в сумме, но, кажется, больше -- но сейчас уже и не вспомню точно.
А вот видеорежимы -- да, с Эплом-2 совсем никак не совместимы до появления Агата-9.
6502 изготовлен по технологии n-MOS, и вряд ли "в лоб" её можно перенести на арсенид галлия -- впрочем, со схемотехникой логики на нём я не знаком. Даже на КМОП (CMOS), по которой делаются 99,9% современных цифровых микросхем, совсем "в лоб" не перенесёшь, нужно подпиливать схему.
В то же время, можно посмотреть на сие дело с другой стороны. Типичный 6502 имел тактовую частоту 1 МГц, современные процессоры имеют, грубо говоря, 4 ГГц (и при этом намного сложней внутри). Соответственно, в качестве первого приближения можно считать, что 6502 можно разогнать в 4000 раз, оставаясь на кремнии, но сменив технологию с тогдашнего н-МОП на современный КМОП.
Но, если я правильно Вас понял, здесь умножение-деление -- не обычные команды процессора, выполняемые в его собственных рамках, а "прибитые сбоку" в виде отдельного, пусть и обязательного устройства. Это мне напоминает ранние PDP-11, где умножения-деления (и многоразрядных сдвигов) как команд не было, но можно было подключить по обычной шине дополнительное "внешнее устройство" EAE -- расширитель арифметики. В него обычными MOVами записывались исходные данные, а потом считывался результат.
Нет, декодер -- вещь относительно небольшая, а для той же Системы 360 и иже с ней попроще будет, чем, скажем, для ARM (CISC -- это далеко не всегда ужас-ужас-ужас в кодировке, как на интеловских процах). Тут управление процессом обработки в целом. В первых RISCах, например, никаких умножений-делений не было -- они сложные, поэтому и были выброшены. (В ARMах, кстати, целочисленное умножение стало появляться лишь в версии ARMv4, и то не во всех вариантах, а деление -- лишь в современных микроконтроллерах, т.е. в архитектуре ARMv7-M).
Эм... наверное, тогда уже не оверлеи, а именно что загрузочные модули. (Оверлеи тоже могли быть, но они входят в состав одного модуля, а не являются отдельными независимыми модулями.)
Про подзадачи я выше написал -- что это, в современной терминологии, поток. Подозреваю, что часть команд самого Примуса именно так и была сделана, но ковырять его возможности особой не было.
А в ПЛ/1, подозреваю, можно было и просто породить подзадачу: скорей всего, там были подпрограммы-обёртки для основных макрокоманд супервизора.
Как уже отметили, сам Примус запускался через JCL как обычное задание. Из него что-либо запускалось либо, опять-таки, через JCL, либо в качестве его собственной подзадачи (потока, в современной терминологии). А вот просто взять и запустить скомпилированную программу и запустить как отдельную сущность без JCL (либо в виде полноценного задания, либо через каталогизированную процедуру) нельзя.
Путаница с архитектурами и микроархитектурами -- это вообще беда; очень многим лениво несколько буковок напечатать (а некоторые, наверное, и не видят разницы).
RISC упрощает "конвейеризацию", но не является необходимым условием. Скажем, такие типичные CISCи, как IBMовские мэйнфреймы от Системы 360 и до современных z/Architecture (хоть самой IBM, хоть некоторые наши ЕСки) благополучно использовали и используют что конвейер, что суперскалярность. В частности, на нашей последней действительно серийной машине -- ЕС-1130 -- простые команды "регистр-регистр" и "регистр-память" имели эффективное время выполнения 1 такт (160 нс, если правильно помню длительность -- всё ж, 30+ лет прошло), ну а "тяжёлые" команды выполнялись традиционным микропрограммным образом. Формально, кстати, там и простые команды были микропрограммными -- но их микропрограмма содержала всего одну микрокоманду.
Возможно, упадку RISCов поспособствовало и то, что появилась возможность впихнуть конвейер, а затем и суперскалярность на один кристалл и для CISCов, что в 1980-е было невозможно -- а соответственно, RISC лишился преимущества в скорости (по сути, в тактовой частоте), обусловленной однокристальной конструкцией.
Ну а сейчас ARMы идут вперёд за счёт мобильного сегмента -- думается, благодаря меньшему энергопотреблению на тот же объём работы. Плюс, здесь нет груза совместимости со 100500 приложениями под IA-32.
Ну а невыровненный доступ... IBM ввела его в Системе 370 за 10+ лет до появления MIPS (одно из расширений по сравнению с Системой 360). Она, случаем, ничего не нарушила?
Угу, OS/360 же рассчитана только на пакетную обработку, поэтому общаться с ней приходится на JCL. Ну, с помощью команды оператора START можно запустить каталогизированную процедуру, но сия процедура -- тот же JCL, вид сбоку. Хотя, в принципе, с их помощью можно было бы обеспечить возможность трансляции и запуска программы без "ручного" использования JCL.
Небольшое добавление: хелловорлд на Коболе -- не на абы каком Коболе, а на Коболе под OS/360 (она же ОС ЕС), причём наряду с текстом программы оказался и текст задания на её трансляцию.
Ну а если без шуток, писать экономические программы под пакетную обработку (типа всяких там расчётов зарплат и распечатки длиннющих "простыней" всяких там платёжных ведомостей" было легко и просто. Хотя для привыкших к современным языкам выглядит, конечно, весьма странно :)
Можно добавить и ещё одну проблему VLIW: процессор не всегда живёт и работает в тепличных условиях.
Если это DSP-процессор, работающий в связке в процессором общего назначения, условия для DSP будут близки в тепличным: всю побочную работу выполняет процессор общего назначения, а DSP остаётся лишь перемалывать данные. А вот если VLIW-процессор оказывается единственным в системе, сразу возникает куча отвлекающих факторов.
В частности, даже если компилятор всё верно предсказал, сформировал необходимые команды предзагрузки данных для их последующего использования и т.д., эти данные вовсе не обязательно к моменту необходимости в них окажутся для процессора доступными -- и тогда он вынужден будет стоять и ждать. А недоступными они могут, например, оказаться из-за того, что параллельно выполняются интенсивные операции ввода-вывода, и память постоянно занята обменом с контроллерами дисков и т.д. и т.п., оставляя процессор "на голодном пайке". Традиционный суперскалярный процессор с внеочередным выполнением команд в такой ситуации может продолжать работу, пока не упрётся в некие ограничения (команда, для которой нет данных, будет находиться в ожидании, но последующие будут выполняться, если они не завязаны с ожидающей командой), но традиционный VLIW будет стоять. Нет, конечно, и там можно реализовать внеочередное выполнение и т.д. и т.п. -- но это напрочь убьёт относительную простоту и энергоэффективность.
В общем, идея интересная, но именно что нишевая -- не для задач общего назначения.
Вообще, когда говорят про шину данных, имеют в виду сопряжение процессора с внешним миром. Что творится внутри процессора -- это его личное дело, и решения там могут быть самые разнообразные, никак не связанные с его внешним интерфейсом.
Внутри -- да, 8088 и 8086 почти ничем не отличаются. Снаружи отличий побольше будет, и, в частности, шина данных -- 8-разрядная. Вот, например, скриншот из даташита на 8088, где совмещённые ноги адреса и данных заканчиваются на AD7, дальше идут лишь ноги адреса.
Уверен. И Нортона мне читать ни к чему -- электроникой и системным программированием я занимаюсь уже лет эдак 35, и уж что-что, а в разрядностях шин не плаваю.
У Агата-7 очень гибко с памятью было. Минимальный объём -- 32 килобайта на материнской плате, но и на ней могло быть больше, и в разъёмы расширения ставились платы допОЗУ и псевдоПЗУ. У нас в школе было не меньше 64 Кбайт в сумме, но, кажется, больше -- но сейчас уже и не вспомню точно.
А вот видеорежимы -- да, с Эплом-2 совсем никак не совместимы до появления Агата-9.
6502 изготовлен по технологии n-MOS, и вряд ли "в лоб" её можно перенести на арсенид галлия -- впрочем, со схемотехникой логики на нём я не знаком. Даже на КМОП (CMOS), по которой делаются 99,9% современных цифровых микросхем, совсем "в лоб" не перенесёшь, нужно подпиливать схему.
В то же время, можно посмотреть на сие дело с другой стороны. Типичный 6502 имел тактовую частоту 1 МГц, современные процессоры имеют, грубо говоря, 4 ГГц (и при этом намного сложней внутри). Соответственно, в качестве первого приближения можно считать, что 6502 можно разогнать в 4000 раз, оставаясь на кремнии, но сменив технологию с тогдашнего н-МОП на современный КМОП.
Ну, на СМках под ОС-РВ (RSX-11) Паскаль был.
Но, если я правильно Вас понял, здесь умножение-деление -- не обычные команды процессора, выполняемые в его собственных рамках, а "прибитые сбоку" в виде отдельного, пусть и обязательного устройства. Это мне напоминает ранние PDP-11, где умножения-деления (и многоразрядных сдвигов) как команд не было, но можно было подключить по обычной шине дополнительное "внешнее устройство" EAE -- расширитель арифметики. В него обычными MOVами записывались исходные данные, а потом считывался результат.
Нет, декодер -- вещь относительно небольшая, а для той же Системы 360 и иже с ней попроще будет, чем, скажем, для ARM (CISC -- это далеко не всегда ужас-ужас-ужас в кодировке, как на интеловских процах). Тут управление процессом обработки в целом. В первых RISCах, например, никаких умножений-делений не было -- они сложные, поэтому и были выброшены. (В ARMах, кстати, целочисленное умножение стало появляться лишь в версии ARMv4, и то не во всех вариантах, а деление -- лишь в современных микроконтроллерах, т.е. в архитектуре ARMv7-M).
Эм... наверное, тогда уже не оверлеи, а именно что загрузочные модули. (Оверлеи тоже могли быть, но они входят в состав одного модуля, а не являются отдельными независимыми модулями.)
Про подзадачи я выше написал -- что это, в современной терминологии, поток. Подозреваю, что часть команд самого Примуса именно так и была сделана, но ковырять его возможности особой не было.
А в ПЛ/1, подозреваю, можно было и просто породить подзадачу: скорей всего, там были подпрограммы-обёртки для основных макрокоманд супервизора.
Динозавров -- нет. А вот времена, когда деревья были маленькими, а компьютеры -- большими...
Насколько знаю, нет.
Как уже отметили, сам Примус запускался через JCL как обычное задание. Из него что-либо запускалось либо, опять-таки, через JCL, либо в качестве его собственной подзадачи (потока, в современной терминологии). А вот просто взять и запустить скомпилированную программу и запустить как отдельную сущность без JCL (либо в виде полноценного задания, либо через каталогизированную процедуру) нельзя.
Путаница с архитектурами и микроархитектурами -- это вообще беда; очень многим лениво несколько буковок напечатать (а некоторые, наверное, и не видят разницы).
RISC упрощает "конвейеризацию", но не является необходимым условием. Скажем, такие типичные CISCи, как IBMовские мэйнфреймы от Системы 360 и до современных z/Architecture (хоть самой IBM, хоть некоторые наши ЕСки) благополучно использовали и используют что конвейер, что суперскалярность. В частности, на нашей последней действительно серийной машине -- ЕС-1130 -- простые команды "регистр-регистр" и "регистр-память" имели эффективное время выполнения 1 такт (160 нс, если правильно помню длительность -- всё ж, 30+ лет прошло), ну а "тяжёлые" команды выполнялись традиционным микропрограммным образом. Формально, кстати, там и простые команды были микропрограммными -- но их микропрограмма содержала всего одну микрокоманду.
Возможно, упадку RISCов поспособствовало и то, что появилась возможность впихнуть конвейер, а затем и суперскалярность на один кристалл и для CISCов, что в 1980-е было невозможно -- а соответственно, RISC лишился преимущества в скорости (по сути, в тактовой частоте), обусловленной однокристальной конструкцией.
Ну а сейчас ARMы идут вперёд за счёт мобильного сегмента -- думается, благодаря меньшему энергопотреблению на тот же объём работы. Плюс, здесь нет груза совместимости со 100500 приложениями под IA-32.
Ну а невыровненный доступ... IBM ввела его в Системе 370 за 10+ лет до появления MIPS (одно из расширений по сравнению с Системой 360). Она, случаем, ничего не нарушила?
Может, и мне язык изобрести? К зиме борода такая, что принимают за гибрид попа и деда мороза :)
Угу, OS/360 же рассчитана только на пакетную обработку, поэтому общаться с ней приходится на JCL. Ну, с помощью команды оператора START можно запустить каталогизированную процедуру, но сия процедура -- тот же JCL, вид сбоку. Хотя, в принципе, с их помощью можно было бы обеспечить возможность трансляции и запуска программы без "ручного" использования JCL.
Небольшое добавление: хелловорлд на Коболе -- не на абы каком Коболе, а на Коболе под OS/360 (она же ОС ЕС), причём наряду с текстом программы оказался и текст задания на её трансляцию.
Ну а если без шуток, писать экономические программы под пакетную обработку (типа всяких там расчётов зарплат и распечатки длиннющих "простыней" всяких там платёжных ведомостей" было легко и просто. Хотя для привыкших к современным языкам выглядит, конечно, весьма странно :)
Хм... а что революционного в словах песни? Про любовь было сказано, по меньшей мере, на ~2000 лет раньше.
Но по существу вопроса, в целом, согласен :)
Можно добавить и ещё одну проблему VLIW: процессор не всегда живёт и работает в тепличных условиях.
Если это DSP-процессор, работающий в связке в процессором общего назначения, условия для DSP будут близки в тепличным: всю побочную работу выполняет процессор общего назначения, а DSP остаётся лишь перемалывать данные. А вот если VLIW-процессор оказывается единственным в системе, сразу возникает куча отвлекающих факторов.
В частности, даже если компилятор всё верно предсказал, сформировал необходимые команды предзагрузки данных для их последующего использования и т.д., эти данные вовсе не обязательно к моменту необходимости в них окажутся для процессора доступными -- и тогда он вынужден будет стоять и ждать. А недоступными они могут, например, оказаться из-за того, что параллельно выполняются интенсивные операции ввода-вывода, и память постоянно занята обменом с контроллерами дисков и т.д. и т.п., оставляя процессор "на голодном пайке". Традиционный суперскалярный процессор с внеочередным выполнением команд в такой ситуации может продолжать работу, пока не упрётся в некие ограничения (команда, для которой нет данных, будет находиться в ожидании, но последующие будут выполняться, если они не завязаны с ожидающей командой), но традиционный VLIW будет стоять. Нет, конечно, и там можно реализовать внеочередное выполнение и т.д. и т.п. -- но это напрочь убьёт относительную простоту и энергоэффективность.
В общем, идея интересная, но именно что нишевая -- не для задач общего назначения.
Подозреваю, что это не производители матерей, а производители процов (и чипсетов).
Вообще, когда говорят про шину данных, имеют в виду сопряжение процессора с внешним миром. Что творится внутри процессора -- это его личное дело, и решения там могут быть самые разнообразные, никак не связанные с его внешним интерфейсом.
Внутри -- да, 8088 и 8086 почти ничем не отличаются. Снаружи отличий побольше будет, и, в частности, шина данных -- 8-разрядная. Вот, например, скриншот из даташита на 8088, где совмещённые ноги адреса и данных заканчиваются на AD7, дальше идут лишь ноги адреса.
Уверен. И Нортона мне читать ни к чему -- электроникой и системным программированием я занимаюсь уже лет эдак 35, и уж что-что, а в разрядностях шин не плаваю.