Плюс, там были короткие команды для доступа к нулевой странице памяти (0000-00FF), которые работали быстрей обычных, длинных. Плюс, типичное применение машинок на процах такого уровня -- выполнение всего одной задачи, а значит, вся память -- её, повторная входимость обычно не нужна и т.д. и т.п. Так что вызовы подпрограмм нередко выполнялись по "гибридной модели", так сказать: сам вызов технически использовал стек для адреса возврата (команды JSR и RTS), а параметры нередко лежали в предопределённых ячейках памяти.
Лично я предпочитаю иметь модель примерно как в ARM: где я сам могу либо традиционным "стековым" образом вызывать подпрограммы, либо сделать, как в Системе 360, либо некое промежуточное решение. В общем, когда есть гибкость. Правда, она востребована, только если пишешь на ассемблере -- а сейчас это редкость.
Насчёт бесстекового способа вставлю свои пять копеек.
Исторически в OS/360 каждое динамическое выделение памяти производилось путём обращения к супервизору (грубо говоря, к ядру ОС): ассемблерная программа, желающая получить память, использовала макрокоманду GETMAIN ("main" -- от названия "основная память", main storage, использовавшейся и использующейся поныне для обозначения ОЗУ в IBMовских мэйнфреймах), ну а эта макрокоманда разворачивалась в загрузку параметров (в первом приближении -- требуемого объёма памяти) в регистры процессора и выдачу команды SVC, приводящей к прерыванию по вызову супервизора. Сейчас такой способ кажется диким: прерывание на современных процессорах -- очень долгий процесс по сравнению с простым выполнением команд, но тогда, в середине 1960-х и в 1970-х, особой разницы во времени выполнения не было.
Такая достаточно современная архитектура, как ARM, хотя и имеет стек, позволяет реализовать вызов подпрограмм без его использования: команда BL, вызывающая подпрограмму, сохраняет адрес возврата в регистре LR, а не записывает его в стек, как это делает, скажем, CALL на IA-32 (x86). Соответственно, потенциально можно реализовать ту же схему вызова, что и в IBMовских мэйнфреймах. Правда, в ARM адрес возврата заносится всегда в один и тот же регистр, а в мэйнфреймах можно использовать любой из 16 регистров общего назначения, но это уже технические детали.
Насчёт этого я не знаю, никогда не интересовался. Но в плане несовместимости слышал лишь про видеоадаптер -- так что, возможно, управление банками организовано одинаково.
Ну и, по большому счёту, наша Рапира -- это, по сути, Паскаль на русском, насколько помню. Её я видел, но не ковырял: первым у меня был Бейсик на Агате, вторым -- встроенный в него же ассемблер 6502, ну а третьим стала СМ-4 и затем СМ-1420 с Фортраном, Паскалем и ассемблером -- ну и пошло-поехало; после этого на агатах я вёл школьный кружок, сам ещё будучи школьником, но серьёзно на них ничего не делал: у меня ж был доступ к настоящей машине :)
У Агата-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). Она, случаем, ничего не нарушила?
Хм... так бюджетного или игрового? :)
Плюс, там были короткие команды для доступа к нулевой странице памяти (0000-00FF), которые работали быстрей обычных, длинных. Плюс, типичное применение машинок на процах такого уровня -- выполнение всего одной задачи, а значит, вся память -- её, повторная входимость обычно не нужна и т.д. и т.п. Так что вызовы подпрограмм нередко выполнялись по "гибридной модели", так сказать: сам вызов технически использовал стек для адреса возврата (команды JSR и RTS), а параметры нередко лежали в предопределённых ячейках памяти.
Лично я предпочитаю иметь модель примерно как в ARM: где я сам могу либо традиционным "стековым" образом вызывать подпрограммы, либо сделать, как в Системе 360, либо некое промежуточное решение. В общем, когда есть гибкость. Правда, она востребована, только если пишешь на ассемблере -- а сейчас это редкость.
Не было. Там самый что ни на есть обычный стек, только объём всего 256 байт.
Но она новее и мэйнфреймов (анонс в 1964 году, продажи -- с 1965), и 8086/88, из коего выросла IA-32 (1977-й, если память не изменяет).
Спорная вещь. Но, замечу, на ARMе отдельные стеки для адресов возврата и для, скажем, данных сделать элементарно как раз благодаря его системе команд.
Резюмируя классическим образом, "если какая-то неприятность может случиться, она случается" (с)
Насчёт бесстекового способа вставлю свои пять копеек.
Исторически в OS/360 каждое динамическое выделение памяти производилось путём обращения к супервизору (грубо говоря, к ядру ОС): ассемблерная программа, желающая получить память, использовала макрокоманду GETMAIN ("main" -- от названия "основная память", main storage, использовавшейся и использующейся поныне для обозначения ОЗУ в IBMовских мэйнфреймах), ну а эта макрокоманда разворачивалась в загрузку параметров (в первом приближении -- требуемого объёма памяти) в регистры процессора и выдачу команды SVC, приводящей к прерыванию по вызову супервизора. Сейчас такой способ кажется диким: прерывание на современных процессорах -- очень долгий процесс по сравнению с простым выполнением команд, но тогда, в середине 1960-х и в 1970-х, особой разницы во времени выполнения не было.
Такая достаточно современная архитектура, как ARM, хотя и имеет стек, позволяет реализовать вызов подпрограмм без его использования: команда BL, вызывающая подпрограмму, сохраняет адрес возврата в регистре LR, а не записывает его в стек, как это делает, скажем, CALL на IA-32 (x86). Соответственно, потенциально можно реализовать ту же схему вызова, что и в IBMовских мэйнфреймах. Правда, в ARM адрес возврата заносится всегда в один и тот же регистр, а в мэйнфреймах можно использовать любой из 16 регистров общего назначения, но это уже технические детали.
Дык и производство самого 6502 продолжается :)
Насчёт этого я не знаю, никогда не интересовался. Но в плане несовместимости слышал лишь про видеоадаптер -- так что, возможно, управление банками организовано одинаково.
Ну и, по большому счёту, наша Рапира -- это, по сути, Паскаль на русском, насколько помню. Её я видел, но не ковырял: первым у меня был Бейсик на Агате, вторым -- встроенный в него же ассемблер 6502, ну а третьим стала СМ-4 и затем СМ-1420 с Фортраном, Паскалем и ассемблером -- ну и пошло-поехало; после этого на агатах я вёл школьный кружок, сам ещё будучи школьником, но серьёзно на них ничего не делал: у меня ж был доступ к настоящей машине :)
У Агата-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). Она, случаем, ничего не нарушила?
Может, и мне язык изобрести? К зиме борода такая, что принимают за гибрид попа и деда мороза :)