Когда на однопоточных (одноядерных) системах начинают обзывать задачи потоками и говорить про параллельную работу, при чем опытные разработчики, немного корежит…
"при чём" в таком контексте пишется слитно, но это придирки. А вот термин "многозадачность" (multitasking) появился очень давно, и подразумевал он именно что выполнение программ, переключаемых планировщиком (диспетчером) системы -- то есть, по сути, применялся именно к потокам и/или к "процессопотокам", когда в некоторой ОС не было отдельных концепций, аналогичных процессу и потоку винды.
Скажем, в большинстве вариантов OS/360 (а это вторая половина 1960-х), кроме самых примитивных, были и процессы, и потоки, только то, что в винде включается в термин "процесс", размазывалось между разделом памяти и задачей пункта задания, а "потоками" были эта самая задача пункта задания (головной поток) и порождаемые ей подзадачи.
В RSX-11M -- "бабке" Винды (середина 1970-х) -- были лишь "процессопотоки", называемые, внезапно, задачами, и даже выполняемые файлы ("экзешники") имели расширение .TSK. И да, они выполнялись параллельно в режиме вытесняющей многозадачности.
В общем, простите, задачи -- исторически это и есть параллельная работа.
Для атомарного доступа, вместо отключения прерываний, в процессорных ядрах ARM Cortex M есть специализированное решение – инструкции эксклюзивного доступа LDREX/STREX. Этот механизм защищает конкретный адрес памяти от несанкционированного доступа – доступ из прерывания.
С этим тоже есть проблемы, причём, по меньшей мере, две:
есть ядра Cortex-M0 (архитектура ARMv6-M), у которых этих команд нет вообще;
есть двухъядерные микроконтроллеры STM32H745 и иже с ним, где у обоих ядер (Cortex-M7 и Cortex-M4) эти команды есть, но вот глобальный монитор монопольного доступа разработчик МК почему-то не реализовал, из-за чего эта парочка команд может использоваться весьма ограниченно -- только если она должна обеспечить атомарность при доступе строго для одного ядра; если к чему-то нужно атомарно обращаться кодом, выполняющимся на разных ядрах, -- всё, приходится делать что-то другое, например, использовать аппаратные семафоры (блок HSEM), неализованные на этом семействе МК.
На таких МК действительно критически важно быстро обработать прерывание, т.к. любое другое возникшее прерывание в момент обработки текущего будет проигнорировано.
Не будет оно проигнорировано -- оно будет сохранено в ожидании обработки, и его обработчик будет вызван, как только станет возможным. Точно то же самое имеет место и на ARMах с NVICом: если низкоприоритетное прерывание запрашивается в момент, когда выполняется обработчик высокоприоритетного прерывания, низкоприоритетное запоминается и ждёт.
Бейсиков было 100500 диалектов, плохо совместимых между собой, ну а полная переносимость могла быть достигнута, разве что, для программы уровня хелловорлда.
Некоторые утверждают, что программист, освоивший Бейсик, потерян для прогерского искусства безвозвратно
Дейкстра это утверждал. Как по мне, он -- один из наиболее переоцененных персонажей в компьютерной истории (вероятно, потому, что очень много и довольно остроумно болтал).
Первый ЯП высокого уровня
На самом деле, первым таким языком был разработанный Цузе для его компьютера. Но первым, пошедшим в массы, был действительно Фортран.
Кстати говоря, на фотке -- не код на Фортране, а какой-то отчёт транслятора или компоновщика, причём без строк исходного кода.
Хотя мой код и покрыт тестами, их разработка — дело очень тонкое. Тесты для SBC всегда были зеленые, но, видимо, я подобрал такие тестовые сценарии или вовсе выстраивал логику теста на основе того, какие значения должны получиться
Вообще, если уж покрывать тестами, в первую очередь нужно тестировать все граничные случаи (первое и последнее значения, когда некий флаг устанавливается, а затем первое и последнее, когда он сбрасывается, и т. д.). Применительно к переносу надо ещё постоянно держать в голове, что у разных архитектур при вычитании он ведёт себя по-разному: на одних устанавливается при возникновении заёма, а на других, наоборот, сбрасывается в такой ситуации; соответственно, нельзя "механически" перенести тест с одной архитектуры на другую, предварительно не убедившись, что логика изменения флагов у них совпадает.
Как водится, обходились тем, что было под рукой. Например, в конструкции превалировали микросхемы ИР16 — это четырёхразрядный сдвиговый регистр, бывший на тот момент в широком употреблении в стране. Восьмиразрядные появятся только годом позже, поэтому приходилось монтировать ИР16 парами.
Были 8-разрядные, были -- и К155ИР13, и КР580ИР82/83. Вероятно, их не было именно у этой конкретной конторы, а СССР -- это СССР, и поэтому нельзя было просто взять и купить даже при наличии бюджетов -- либо официально заказывай через всю бюрократическую машину и жди, пока все эти госпланы разродятся (нередко за несколько лет), либо "доставай" -- т.е., попросту говоря, воруй или покупай краденое.
Говорят, материнская плата сего изделия состояла из восьми слоёв, что выглядело феноменально на фоне советских ПЭВМ, которые насчитывали всего 2-3 слоя.
Учитывая, что Брестский завод участвовал в выпуске ЕС ЭВМ (хотя головным для него в этом деле был Минский завод), а почти все они, кроме ранних моделей малой и средней производительности, делались на многослойках, это неудивительно: к концу 1980-х технология была уже хорошо отработана, необходимые связи имелись...
Вот и меня примерно по таким же причинам ни одна из советских бытовых ЭВМ, как и Спектрум, не интересовали вообще: у меня был доступ и к СМ-1420, и к ЕС-1035, и на их фоне эти машинки... Да они банально скучны внутри, единственное достоинство -- недокартинку нарисовать на экране могут, и то не все (а недокартинок мне хватило на школьном Агате).
Предвыборка команды в том или ином виде, включая выборку новой команды одновременно с завершением предыдущей, много у кого есть, но это далеко не конвейеризация.
У 6502 тактирование однофазное, у 8080 -- да, двухфазное, но обе фазы имеют место на протяжении одного такта. AlexSpirit имеет в виду, что 6502 работает прям как нынешняя DDR-память -- выполняет операции и по фронту, и по спаду синхросигнала. (Хотя я в этом не уверен, это надо разбираться со схемой процессора, чтоб понять точно, как оно сделано).
Из которой следует, что теоритический максиммум у КР580ВМ80А был 625 тыс оп/с. Но я отчетливо помню, еще со студенчекого УМК-80, что в спецификации на этот микропроцессор была дана средная производительность в 125 тыс оп/сек при частоте 1 МГц. На MOS 6502 эта же средняя составляет 600 тыс оп/сек на 1 МГц.
Как считали эти 125 тысяч, мне неведомо. Но насчёт 6502 -- полная ерунда, у него теоретический предел на 1 МГц -- это 500 тыс оп/с, причём это будут либо межрегистровые пересылки, либо арифметико-логические с константой.
Ну и замечу, что терминами оперируют очень вольно. Быстродействие и производительность -- разные вещи. Скажем, для ЕС-1035 указывают производительность в 130-160 тыс. опс/с -- но это по какому-то из "Гибсонов", т.е. среднее число выполняемых команд на смеси, включающей самые разные команды, в том числе немалое количество операций с плавающей запятой. Ну а с какой производительностью плавающую запятую будет считать 6502 или 8080?
Ну, я это говорю больше ради точности: часто смешивают многотактовые процессоры со схемным управлением (типа того же К1801ВМ1) с реально микропрограммными, где управляющие сигналы формируются из информации, считываемой из памяти (а соответственно, можно поменять, скажем, систему команд, заменив содержимое памяти, но без внесения изменений в собственно схемотехнику).
Но, справедливости ради, микропрограммное управление само по себе тормозом не является -- всё зависит от конкретной реализации и общих аппаратных затрат. Скажем, процессор ЭВМ ЕС-1130 -- конвейерный (4 ступени, насколько помню), но с микропрограммным управлением. Выборка и декодирование команды, вычисление адресов операндов в памяти и даже выборка операндов из памяти реализованы схемно, а управление собственно выполнением команды -- микропрограммное. Как следствие, все простые команды типа сложения "регистр-регистр" и "регистр-память" (!) выполняются при заполненном конвейере за одну микрокоманду, т. е. за один такт (но для "регистр-память", естественно, требуется, чтобы содержимое нужной ячейки памяти уже лежало в кэше процессора, иначе потребуется обращение к физическому ОЗУ -- а это и несколько тактов, и возможная конкуренция с каналами ввода-вывода). Сложные команды, понятно, требовали многих микрокоманд, а поэтому выполнялись медленнее.
Строго говоря, "одинаково тормозила" -- неверное утверждение. Например, у 8080 доступы к шине предсказуемы, и после очередного обращения процессора можно сразу выполнять очередную регенерацию -- в это время процессор занят своими делами и точно к шине не полезет (вроде б, так сделано на Специалисте, причём регенерация совмещается с выборкой очередного байта для вывода на экран). У 6502 с его временем такта в 1000 нс в один такт можно впихнуть и обслуживание запроса процессора, и регенерацию. Но всё это требует, естественно, достаточно грамотного подхода при проектировании (и лишних деталей по сравнению с совсем примитивной реализацией "в лоб"); кроме того, работает лишь на простых системах, где, кроме процессора, активных устройств нет.
8080 на 2,5 МГц выдавал 625 тыс оп/с, 6502 на 1 МГц -- до 500 тыс, я выше кусок таблички с тактами выложил.
БК в этом отношении вообще телепается в хвосте. Его процессор К1801ВМ1 был очень многотактовым, в среднем на одну операцию требовалось 10 и более тактов.
У самом проца по справочникам максимальная частота -- 5 МГц. В БК изрядным тормозом было видео, поскольку отдельной видеопамяти как таковой не было, и любое обращение для вывода на экран тормозило процессор. Плюс, частота процессора сильно ниже максимально возможной.
Не было там "микрокода", если уж на то пошло, хотя все утверждают именно это. Там было чисто схемное управление -- управляющие сигналы на каждый такт вырабатывались схемой (матрицей), а не считывались из памяти микропрограмм, как при настоящем микропрограммном управлении..
А вот у настоящих PDPшек, как и у наших СМок -- как правило, ещё более сложных (ВМ1 -- это LSI-11, т. е. огрызок архитектуры) -- было настоящее микропрограммное управление с настоящим ПЗУ микрокоманд.
MicroVAX -- это уже про VAX, а не про PDP-11. И у ДЕКа микропроцессорные реализации ПДПшек тоже были -- сначала из нескольких специализированных микросхем, потом и до одной дошли. Ну а скорость нужна не всегда и не везде; тот же К1801ВМ1 вполне сопоставим, если не быстрей, чем СМ-1300 -- но одна микросхема, а не целая плата.
500 тысяч (два такта) на пересылках регистр-регистр и на арифметико-логических с константой, 333 тысячи (три такта) на арифметико-логических при размещении второго операнда на нулевой странице, 250 тысяч (четыре такта) при размещении в произвольном месте памяти и прямой (абсолютной) адресации:
В то же время не забываем, что у PDP-11/LSI-11 для любых видов косвенной адресации используются регистры, а ещё есть автоинкремент/автодекремент, поэтому при последовательной обработке массивов у них будет одна команда там, где у 6502 может потребоваться десяток.
Шина 16-разрядная, поэтому "вдвое больше байтов" проблемы не создают сами по себе. Это у IBM PC 16-разрядные операции с памятью медленнее 8-разрядных их-за того, что сам процессор -- 16-разрядный, но шина у него -- 8-разрядная.
Это под вопросом, так сказать. Надо либо проводить тщательный теоретический анализ (считать время выполнения достаточно сложных программ, а не отдельных команд), либо гонять схожие программы на разных машинах и замерять время.
Как Вам уже указали, это не так. В, скажем, IBM PC у обоих штатных видеоадаптеров -- CGA и MDA -- была своя собственная видеопамять, которая на основной шине компьютера не висела (подключалась лишь при обращении со стороны процессора), поэтому собственно вывод видео никак на работе остальной машины не сказывался. Но во многих бытовых, и, в частности, в БК всё было на одной и той же шине, поэтому обращения видео отнимали шину у процессора. Кстати говоря, то же самое было в IBM PCjr -- сделали для удешевления не полностью отдельную видеопамять, а общую с системной.
"при чём" в таком контексте пишется слитно, но это придирки. А вот термин "многозадачность" (multitasking) появился очень давно, и подразумевал он именно что выполнение программ, переключаемых планировщиком (диспетчером) системы -- то есть, по сути, применялся именно к потокам и/или к "процессопотокам", когда в некоторой ОС не было отдельных концепций, аналогичных процессу и потоку винды.
Скажем, в большинстве вариантов OS/360 (а это вторая половина 1960-х), кроме самых примитивных, были и процессы, и потоки, только то, что в винде включается в термин "процесс", размазывалось между разделом памяти и задачей пункта задания, а "потоками" были эта самая задача пункта задания (головной поток) и порождаемые ей подзадачи.
В RSX-11M -- "бабке" Винды (середина 1970-х) -- были лишь "процессопотоки", называемые, внезапно, задачами, и даже выполняемые файлы ("экзешники") имели расширение .TSK. И да, они выполнялись параллельно в режиме вытесняющей многозадачности.
В общем, простите, задачи -- исторически это и есть параллельная работа.
С этим тоже есть проблемы, причём, по меньшей мере, две:
есть ядра Cortex-M0 (архитектура ARMv6-M), у которых этих команд нет вообще;
есть двухъядерные микроконтроллеры STM32H745 и иже с ним, где у обоих ядер (Cortex-M7 и Cortex-M4) эти команды есть, но вот глобальный монитор монопольного доступа разработчик МК почему-то не реализовал, из-за чего эта парочка команд может использоваться весьма ограниченно -- только если она должна обеспечить атомарность при доступе строго для одного ядра; если к чему-то нужно атомарно обращаться кодом, выполняющимся на разных ядрах, -- всё, приходится делать что-то другое, например, использовать аппаратные семафоры (блок HSEM), неализованные на этом семействе МК.
Не будет оно проигнорировано -- оно будет сохранено в ожидании обработки, и его обработчик будет вызван, как только станет возможным. Точно то же самое имеет место и на ARMах с NVICом: если низкоприоритетное прерывание запрашивается в момент, когда выполняется обработчик высокоприоритетного прерывания, низкоприоритетное запоминается и ждёт.
Вот насчёт Вирта не соглашусь, но холивар устраивать точно не буду :)
Бейсиков было 100500 диалектов, плохо совместимых между собой, ну а полная переносимость могла быть достигнута, разве что, для программы уровня хелловорлда.
Дейкстра это утверждал. Как по мне, он -- один из наиболее переоцененных персонажей в компьютерной истории (вероятно, потому, что очень много и довольно остроумно болтал).
На самом деле, первым таким языком был разработанный Цузе для его компьютера. Но первым, пошедшим в массы, был действительно Фортран.
Кстати говоря, на фотке -- не код на Фортране, а какой-то отчёт транслятора или компоновщика, причём без строк исходного кода.
Прогресс одобряю :)
Вообще, если уж покрывать тестами, в первую очередь нужно тестировать все граничные случаи (первое и последнее значения, когда некий флаг устанавливается, а затем первое и последнее, когда он сбрасывается, и т. д.). Применительно к переносу надо ещё постоянно держать в голове, что у разных архитектур при вычитании он ведёт себя по-разному: на одних устанавливается при возникновении заёма, а на других, наоборот, сбрасывается в такой ситуации; соответственно, нельзя "механически" перенести тест с одной архитектуры на другую, предварительно не убедившись, что логика изменения флагов у них совпадает.
Были 8-разрядные, были -- и К155ИР13, и КР580ИР82/83. Вероятно, их не было именно у этой конкретной конторы, а СССР -- это СССР, и поэтому нельзя было просто взять и купить даже при наличии бюджетов -- либо официально заказывай через всю бюрократическую машину и жди, пока все эти госпланы разродятся (нередко за несколько лет), либо "доставай" -- т.е., попросту говоря, воруй или покупай краденое.
Учитывая, что Брестский завод участвовал в выпуске ЕС ЭВМ (хотя головным для него в этом деле был Минский завод), а почти все они, кроме ранних моделей малой и средней производительности, делались на многослойках, это неудивительно: к концу 1980-х технология была уже хорошо отработана, необходимые связи имелись...
А дочитать фразу до конца не пробовали?
Вот и меня примерно по таким же причинам ни одна из советских бытовых ЭВМ, как и Спектрум, не интересовали вообще: у меня был доступ и к СМ-1420, и к ЕС-1035, и на их фоне эти машинки... Да они банально скучны внутри, единственное достоинство -- недокартинку нарисовать на экране могут, и то не все (а недокартинок мне хватило на школьном Агате).
Нет у 6502 комнад, выполняемых за один такт.
Предвыборка команды в том или ином виде, включая выборку новой команды одновременно с завершением предыдущей, много у кого есть, но это далеко не конвейеризация.
У 6502 тактирование однофазное, у 8080 -- да, двухфазное, но обе фазы имеют место на протяжении одного такта. AlexSpirit имеет в виду, что 6502 работает прям как нынешняя DDR-память -- выполняет операции и по фронту, и по спаду синхросигнала. (Хотя я в этом не уверен, это надо разбираться со схемой процессора, чтоб понять точно, как оно сделано).
Как считали эти 125 тысяч, мне неведомо. Но насчёт 6502 -- полная ерунда, у него теоретический предел на 1 МГц -- это 500 тыс оп/с, причём это будут либо межрегистровые пересылки, либо арифметико-логические с константой.
Ну и замечу, что терминами оперируют очень вольно. Быстродействие и производительность -- разные вещи. Скажем, для ЕС-1035 указывают производительность в 130-160 тыс. опс/с -- но это по какому-то из "Гибсонов", т.е. среднее число выполняемых команд на смеси, включающей самые разные команды, в том числе немалое количество операций с плавающей запятой. Ну а с какой производительностью плавающую запятую будет считать 6502 или 8080?
Ну, я это говорю больше ради точности: часто смешивают многотактовые процессоры со схемным управлением (типа того же К1801ВМ1) с реально микропрограммными, где управляющие сигналы формируются из информации, считываемой из памяти (а соответственно, можно поменять, скажем, систему команд, заменив содержимое памяти, но без внесения изменений в собственно схемотехнику).
Но, справедливости ради, микропрограммное управление само по себе тормозом не является -- всё зависит от конкретной реализации и общих аппаратных затрат. Скажем, процессор ЭВМ ЕС-1130 -- конвейерный (4 ступени, насколько помню), но с микропрограммным управлением. Выборка и декодирование команды, вычисление адресов операндов в памяти и даже выборка операндов из памяти реализованы схемно, а управление собственно выполнением команды -- микропрограммное. Как следствие, все простые команды типа сложения "регистр-регистр" и "регистр-память" (!) выполняются при заполненном конвейере за одну микрокоманду, т. е. за один такт (но для "регистр-память", естественно, требуется, чтобы содержимое нужной ячейки памяти уже лежало в кэше процессора, иначе потребуется обращение к физическому ОЗУ -- а это и несколько тактов, и возможная конкуренция с каналами ввода-вывода). Сложные команды, понятно, требовали многих микрокоманд, а поэтому выполнялись медленнее.
Строго говоря, "одинаково тормозила" -- неверное утверждение. Например, у 8080 доступы к шине предсказуемы, и после очередного обращения процессора можно сразу выполнять очередную регенерацию -- в это время процессор занят своими делами и точно к шине не полезет (вроде б, так сделано на Специалисте, причём регенерация совмещается с выборкой очередного байта для вывода на экран). У 6502 с его временем такта в 1000 нс в один такт можно впихнуть и обслуживание запроса процессора, и регенерацию. Но всё это требует, естественно, достаточно грамотного подхода при проектировании (и лишних деталей по сравнению с совсем примитивной реализацией "в лоб"); кроме того, работает лишь на простых системах, где, кроме процессора, активных устройств нет.
Ранние БК шли с Фокалом, Бейсик появился позже.
8080 на 2,5 МГц выдавал 625 тыс оп/с, 6502 на 1 МГц -- до 500 тыс, я выше кусок таблички с тактами выложил.
У самом проца по справочникам максимальная частота -- 5 МГц. В БК изрядным тормозом было видео, поскольку отдельной видеопамяти как таковой не было, и любое обращение для вывода на экран тормозило процессор. Плюс, частота процессора сильно ниже максимально возможной.
Не было там "микрокода", если уж на то пошло, хотя все утверждают именно это. Там было чисто схемное управление -- управляющие сигналы на каждый такт вырабатывались схемой (матрицей), а не считывались из памяти микропрограмм, как при настоящем микропрограммном управлении..
А вот у настоящих PDPшек, как и у наших СМок -- как правило, ещё более сложных (ВМ1 -- это LSI-11, т. е. огрызок архитектуры) -- было настоящее микропрограммное управление с настоящим ПЗУ микрокоманд.
MicroVAX -- это уже про VAX, а не про PDP-11. И у ДЕКа микропроцессорные реализации ПДПшек тоже были -- сначала из нескольких специализированных микросхем, потом и до одной дошли. Ну а скорость нужна не всегда и не везде; тот же К1801ВМ1 вполне сопоставим, если не быстрей, чем СМ-1300 -- но одна микросхема, а не целая плата.
500 тысяч (два такта) на пересылках регистр-регистр и на арифметико-логических с константой, 333 тысячи (три такта) на арифметико-логических при размещении второго операнда на нулевой странице, 250 тысяч (четыре такта) при размещении в произвольном месте памяти и прямой (абсолютной) адресации:
В то же время не забываем, что у PDP-11/LSI-11 для любых видов косвенной адресации используются регистры, а ещё есть автоинкремент/автодекремент, поэтому при последовательной обработке массивов у них будет одна команда там, где у 6502 может потребоваться десяток.
Шина 16-разрядная, поэтому "вдвое больше байтов" проблемы не создают сами по себе. Это у IBM PC 16-разрядные операции с памятью медленнее 8-разрядных их-за того, что сам процессор -- 16-разрядный, но шина у него -- 8-разрядная.
Это под вопросом, так сказать. Надо либо проводить тщательный теоретический анализ (считать время выполнения достаточно сложных программ, а не отдельных команд), либо гонять схожие программы на разных машинах и замерять время.
Как Вам уже указали, это не так. В, скажем, IBM PC у обоих штатных видеоадаптеров -- CGA и MDA -- была своя собственная видеопамять, которая на основной шине компьютера не висела (подключалась лишь при обращении со стороны процессора), поэтому собственно вывод видео никак на работе остальной машины не сказывался. Но во многих бытовых, и, в частности, в БК всё было на одной и той же шине, поэтому обращения видео отнимали шину у процессора. Кстати говоря, то же самое было в IBM PCjr -- сделали для удешевления не полностью отдельную видеопамять, а общую с системной.
Хто такое РУДОС, не знаю, а вот РАФОС и ФОДОС, если склероз не изменяет, -- одно и тоже, а именно DECовская RT-11.