Угу, OS/360 же рассчитана только на пакетную обработку, поэтому общаться с ней приходится на JCL. Ну, с помощью команды оператора START можно запустить каталогизированную процедуру, но сия процедура -- тот же JCL, вид сбоку. Хотя, в принципе, с их помощью можно было бы обеспечить возможность трансляции и запуска программы без "ручного" использования JCL.
Небольшое добавление: хелловорлд на Коболе -- не на абы каком Коболе, а на Коболе под OS/360 (она же ОС ЕС), причём наряду с текстом программы оказался и текст задания на её трансляцию.
Ну а если без шуток, писать экономические программы под пакетную обработку (типа всяких там расчётов зарплат и распечатки длиннющих "простыней" всяких там платёжных ведомостей" было легко и просто. Хотя для привыкших к современным языкам выглядит, конечно, весьма странно :)
Можно добавить и ещё одну проблему VLIW: процессор не всегда живёт и работает в тепличных условиях.
Если это DSP-процессор, работающий в связке в процессором общего назначения, условия для DSP будут близки в тепличным: всю побочную работу выполняет процессор общего назначения, а DSP остаётся лишь перемалывать данные. А вот если VLIW-процессор оказывается единственным в системе, сразу возникает куча отвлекающих факторов.
В частности, даже если компилятор всё верно предсказал, сформировал необходимые команды предзагрузки данных для их последующего использования и т.д., эти данные вовсе не обязательно к моменту необходимости в них окажутся для процессора доступными -- и тогда он вынужден будет стоять и ждать. А недоступными они могут, например, оказаться из-за того, что параллельно выполняются интенсивные операции ввода-вывода, и память постоянно занята обменом с контроллерами дисков и т.д. и т.п., оставляя процессор "на голодном пайке". Традиционный суперскалярный процессор с внеочередным выполнением команд в такой ситуации может продолжать работу, пока не упрётся в некие ограничения (команда, для которой нет данных, будет находиться в ожидании, но последующие будут выполняться, если они не завязаны с ожидающей командой), но традиционный VLIW будет стоять. Нет, конечно, и там можно реализовать внеочередное выполнение и т.д. и т.п. -- но это напрочь убьёт относительную простоту и энергоэффективность.
В общем, идея интересная, но именно что нишевая -- не для задач общего назначения.
Вообще, когда говорят про шину данных, имеют в виду сопряжение процессора с внешним миром. Что творится внутри процессора -- это его личное дело, и решения там могут быть самые разнообразные, никак не связанные с его внешним интерфейсом.
Внутри -- да, 8088 и 8086 почти ничем не отличаются. Снаружи отличий побольше будет, и, в частности, шина данных -- 8-разрядная. Вот, например, скриншот из даташита на 8088, где совмещённые ноги адреса и данных заканчиваются на AD7, дальше идут лишь ноги адреса.
Уверен. И Нортона мне читать ни к чему -- электроникой и системным программированием я занимаюсь уже лет эдак 35, и уж что-что, а в разрядностях шин не плаваю.
Если бы SS United States шёл на полном ходу, то разрыв показателей между рекордами его и RMS Queen Mary был бы намного больше.
"Намного" -- не был бы, раз он и так шёл на 2/3 мощности. Увеличение скорости в два раза требует, в первом приближении, увеличении мощности в восемь раз (кубическая зависимость).
Вообще, ТурбоВижн появился позже переделки интерфейса на ПК, насколько помню (т.е. версия 3 была, как на Роботроне-1715, версия то ли 4, то ли 5 -- ещё без ТурбоВижна, но уже иной интерфейс, а с появлением ТурбоВижна интерфейс приобрёл свой законченный вид -- вроде, это 6-я версия была). Впрочем, могу ошибаться, лет-то сколько прошло :)
Ещё можно вспомнить, что у оригинального IBM PC минимальный объём ОЗУ составлял всего 16 Кбайт (и работа только со встроенным Бейсиком с сохранением информации на кассетном магнитофоне), а максимальный -- 256 Кбайт. А пресловутые 640 Кбайт, которых хватит всем, не были обязательны даже на IBM PC/AT: базовый вариант имел 512 Кбайт (что могло быть сокращено до 256 Кбайт); чтобы получить 640, требовалось установить плату расширения, содержащую недостающие 128 Кбайт.
Так что в плане объёма ОЗУ Роботрон-1715 был вполне сопоставим с ранними IBM PC, но по производительности был всё ж медленней (8-разрядная шина данных -- это лишь часть факторов, влияющих на производительность; скажем, у 8088 есть команды умножения и деления 16-разрядных чисел, а у Z80 их нет, а подпрограммы выполняют те же операции медленно и печально, ну и т.д.).
У ТТЛ(Ш) логики нет "внутренней подтяжки входов к питанию". Неподключенный вход она считает имеющим лог. 1, поскольку для неё лог. 0 -- это стекание достаточно большого тока через вход на землю, ну а когда вход висит в воздухе, то ток, понятно дело, не течёт.
Вендоры, которые разрабатывают Option ROM для PCIe-устройств, также могут создавать свои меню. Их легко интегрировать в BIOS, и меню будут выглядеть чужеродно.
Ещё маленький косяк обнаружил при более внимательном прочтении: надо полагать, меню не будет выглядеть чужеродно.
Я, когда ковырялся с ранними реализациями ACPI (чисто для собственного удовольствия, моя работа никогда с подобным связана не была), регулярно натыкался на багоглюки, но надеялся, что в будущем вылижут-таки всякие косяки. В общем, наивный чукотский юноша (ещё один (с))
Но, вообще говоря, удручает, что такое огромное количество ошибок сохраняется в совершенно базовых вещах (типа длиннющих Эррат на микроконтроллеры, причём многие ошибки не исправляются годами и переносятся в новые модели). Ощущение такое, что развитие идёт... в неправильном направлении. Погоня за сиюминутной выгодой, "и так сойдёт" и т.д. и т.п. Но это уже философия.
Ну а "серийный" -- обычный, не имеющий каких-то особых требований и особого набора железа на борту. Грубо говоря, берёшь эталонную реализацию от разработчика процессора, добавляешь пару светодиодиков (непременно разноцветных для подсветки системника!), клеишь свой лохотип и продаёшь.
Представьте себе, пробовал. И даже работало. В том числе на упомянутом Вами iMX6 с DDR3. Вот с DDR4 и более поздними не доводилось и вряд ли доведётся, да и особого желания нет: общие идеи и так понятны, а зарываться в специфику очередного проца и прочая нецелесообразно, да и сами такие процы мне не нужны ни по работе, ни для личного удовольствия.
Угу, OS/360 же рассчитана только на пакетную обработку, поэтому общаться с ней приходится на JCL. Ну, с помощью команды оператора START можно запустить каталогизированную процедуру, но сия процедура -- тот же JCL, вид сбоку. Хотя, в принципе, с их помощью можно было бы обеспечить возможность трансляции и запуска программы без "ручного" использования JCL.
Небольшое добавление: хелловорлд на Коболе -- не на абы каком Коболе, а на Коболе под OS/360 (она же ОС ЕС), причём наряду с текстом программы оказался и текст задания на её трансляцию.
Ну а если без шуток, писать экономические программы под пакетную обработку (типа всяких там расчётов зарплат и распечатки длиннющих "простыней" всяких там платёжных ведомостей" было легко и просто. Хотя для привыкших к современным языкам выглядит, конечно, весьма странно :)
Хм... а что революционного в словах песни? Про любовь было сказано, по меньшей мере, на ~2000 лет раньше.
Но по существу вопроса, в целом, согласен :)
Можно добавить и ещё одну проблему VLIW: процессор не всегда живёт и работает в тепличных условиях.
Если это DSP-процессор, работающий в связке в процессором общего назначения, условия для DSP будут близки в тепличным: всю побочную работу выполняет процессор общего назначения, а DSP остаётся лишь перемалывать данные. А вот если VLIW-процессор оказывается единственным в системе, сразу возникает куча отвлекающих факторов.
В частности, даже если компилятор всё верно предсказал, сформировал необходимые команды предзагрузки данных для их последующего использования и т.д., эти данные вовсе не обязательно к моменту необходимости в них окажутся для процессора доступными -- и тогда он вынужден будет стоять и ждать. А недоступными они могут, например, оказаться из-за того, что параллельно выполняются интенсивные операции ввода-вывода, и память постоянно занята обменом с контроллерами дисков и т.д. и т.п., оставляя процессор "на голодном пайке". Традиционный суперскалярный процессор с внеочередным выполнением команд в такой ситуации может продолжать работу, пока не упрётся в некие ограничения (команда, для которой нет данных, будет находиться в ожидании, но последующие будут выполняться, если они не завязаны с ожидающей командой), но традиционный VLIW будет стоять. Нет, конечно, и там можно реализовать внеочередное выполнение и т.д. и т.п. -- но это напрочь убьёт относительную простоту и энергоэффективность.
В общем, идея интересная, но именно что нишевая -- не для задач общего назначения.
Подозреваю, что это не производители матерей, а производители процов (и чипсетов).
Вообще, когда говорят про шину данных, имеют в виду сопряжение процессора с внешним миром. Что творится внутри процессора -- это его личное дело, и решения там могут быть самые разнообразные, никак не связанные с его внешним интерфейсом.
Внутри -- да, 8088 и 8086 почти ничем не отличаются. Снаружи отличий побольше будет, и, в частности, шина данных -- 8-разрядная. Вот, например, скриншот из даташита на 8088, где совмещённые ноги адреса и данных заканчиваются на AD7, дальше идут лишь ноги адреса.
Уверен. И Нортона мне читать ни к чему -- электроникой и системным программированием я занимаюсь уже лет эдак 35, и уж что-что, а в разрядностях шин не плаваю.
"Намного" -- не был бы, раз он и так шёл на 2/3 мощности. Увеличение скорости в два раза требует, в первом приближении, увеличении мощности в восемь раз (кубическая зависимость).
Вообще, ТурбоВижн появился позже переделки интерфейса на ПК, насколько помню (т.е. версия 3 была, как на Роботроне-1715, версия то ли 4, то ли 5 -- ещё без ТурбоВижна, но уже иной интерфейс, а с появлением ТурбоВижна интерфейс приобрёл свой законченный вид -- вроде, это 6-я версия была). Впрочем, могу ошибаться, лет-то сколько прошло :)
"знак денежной единицы" (с) документация на ОС-РВ, в девичестве RSX-11M
Ещё можно вспомнить, что у оригинального IBM PC минимальный объём ОЗУ составлял всего 16 Кбайт (и работа только со встроенным Бейсиком с сохранением информации на кассетном магнитофоне), а максимальный -- 256 Кбайт. А пресловутые 640 Кбайт, которых хватит всем, не были обязательны даже на IBM PC/AT: базовый вариант имел 512 Кбайт (что могло быть сокращено до 256 Кбайт); чтобы получить 640, требовалось установить плату расширения, содержащую недостающие 128 Кбайт.
Так что в плане объёма ОЗУ Роботрон-1715 был вполне сопоставим с ранними IBM PC, но по производительности был всё ж медленней (8-разрядная шина данных -- это лишь часть факторов, влияющих на производительность; скажем, у 8088 есть команды умножения и деления 16-разрядных чисел, а у Z80 их нет, а подпрограммы выполняют те же операции медленно и печально, ну и т.д.).
А ещё на нём была своя версия Турбо Паскаля -- ещё не в том виде, какой стал привычен на IBM PC/AT и её потомках, но, тем не менее.
Входы не подтянуты. Вещи надо называть своими именами.
У ТТЛ(Ш) логики нет "внутренней подтяжки входов к питанию". Неподключенный вход она считает имеющим лог. 1, поскольку для неё лог. 0 -- это стекание достаточно большого тока через вход на землю, ну а когда вход висит в воздухе, то ток, понятно дело, не течёт.
Дык совместимость же...
Ещё маленький косяк обнаружил при более внимательном прочтении: надо полагать, меню не будет выглядеть чужеродно.
Надежда умирает последней (c)
Я, когда ковырялся с ранними реализациями ACPI (чисто для собственного удовольствия, моя работа никогда с подобным связана не была), регулярно натыкался на багоглюки, но надеялся, что в будущем вылижут-таки всякие косяки. В общем, наивный чукотский юноша (ещё один (с))
Но, вообще говоря, удручает, что такое огромное количество ошибок сохраняется в совершенно базовых вещах (типа длиннющих Эррат на микроконтроллеры, причём многие ошибки не исправляются годами и переносятся в новые модели). Ощущение такое, что развитие идёт... в неправильном направлении. Погоня за сиюминутной выгодой, "и так сойдёт" и т.д. и т.п. Но это уже философия.
Ну а "серийный" -- обычный, не имеющий каких-то особых требований и особого набора железа на борту. Грубо говоря, берёшь эталонную реализацию от разработчика процессора, добавляешь пару светодиодиков (непременно разноцветных для подсветки системника!), клеишь свой лохотип и продаёшь.
Эм... Что, даже на обычных "серийных" ПК до сих пор с ACPI проблемы бывают?
Представьте себе, пробовал. И даже работало. В том числе на упомянутом Вами iMX6 с DDR3. Вот с DDR4 и более поздними не доводилось и вряд ли доведётся, да и особого желания нет: общие идеи и так понятны, а зарываться в специфику очередного проца и прочая нецелесообразно, да и сами такие процы мне не нужны ни по работе, ни для личного удовольствия.