"Профессионально разработанные" cortex-m аппаратно пушат кучу (но не все) регистров и точно так же тратят на это время, но только уже безусловно и всегда. А потом ещё и компитятор ручками сохраняет оставшиеся, если функция обработчика сложная с кучей расчётов, не лезущих в сохранённые аппаратно. Ну и наконец, никто и ничто не мешает впилить в конкретную эмбедскую risc-v корку расширение, подменяющее caller-saved регистры при входе в обработчик.
Вот странно. У вас "ой спорно", а у толпы олдов-фанатов пдп-11 не спорно...
Хотя со многим я согласен, достаточно было бы 1.5-адресных команд, как в 68k сделали и огромный косяк с ADC/SBC, который аж не поправили, а повторили в ваксе.
Установка флагов командами MOV, CLR, COM - диверсия, которую практически все позднейшие архитектуры, имеющие флаги условий, устранили. X86, ARM, SPARC, M68k, POWER - нигде такого нет.
Не знаю почему это "диверсия", и откуда вы взяли что в 68к этого нет (как раз очень есть). И присмотритесь к арму или power, может и там оно окажется (опциональным для каждого опкода).
"68k" это "x86", а первый процессор семейства 68k это 68000. И как конкурент 286 он очень даже -- появился раньше, адресовал память сразу нормально, а не убого как 286, кусками по 64к.
про прерывания так что то я и не понял. внешний девайс может в себя включать кучу всякого железа для манипуляций прерываниями
Ну очевидно же. Внешний девайс выставляет свое прерывание на /INT, если в этот же момент ула решит поддёрнуть своё, то оно потеряется.
может даже сделать di:halt
Программе может потребоваться запретить прерывания на какое-то (короткое) время. Если в этот момент ула поддёрнет своё прерывание, то оно тоже потеряется, т.к. не висит до момента очистки процессором, а само по себе кончается. В этом и есть проблема
в 128 два экранных буфера 0x4000, другой с 0xС000 переключаться битиком.
Нет конечно же, там 2 экранных буфера, каждый в своей собственной страничке 16к. Вот правда одна из них всегда воткнута с адреса 0x4000 и её можно воткнуть в 0xc000, а другая -- только в 0xc000 и втыкается. Как результат, если нужно работать с 2 экранными буферами, то извольте их втыкать в 0xc000,после чего в процессе рисования расширенная память оказывается недоступна. Или делайте промежуточный внеэкранный буфер а потом копируйте.
в 48 столько памяти на экран - никтобы не понял.
Фактически, там и так 16 килобайт видеопамяти было, но ула могла вынимать из них только те самые 6912. А если сделать 2 экранных буфера, это не значит что теперь нельзя использовать только один, всё остальное могло бы оставаться точно таким же (в т.ч. начало васика c 0x5c00 и т.д.).
"байт атрибута на байт пикселей" многие хотели, но опять же не в 48К же.
Почему это "не в 48к же"? Какая логика стоит за таким выводом? В том же таймексе с теми же 48к памяти вполне себе сделали.
А вот про прерывание не понял/не помню, в чем была проблема в имеющейся реализации?
Представьте, что внешний девайс тоже захочет давать прерывания. Или что программа захочет по какой-то надобности запретить прерывания на скажем 10 мкс. Результатом будет неиллюзорная возможность терять кадровые.
А вот нифига. Разлиновка экрана была следствием того, что "чипсет" спектрума читал память в "page mode": один раз выдавал RAS-адрес и потом 2 раза читал с разных CAS-адресов. Благодаря этому в моменты чтения пикселей и атрибутов Z80 хоть и с тормозами, но мог продолжать работать с видеопамятью.
Я имел в виду например следующее:
можно было бы сделать 2 экранных буфера, например один с адреса 0x4000, другой с 0x6000.
можно было бы дополнительно сделать цветовой режим "байт атрибута на байт пикселей"
можно было бы прерывание сделать нормальным (для чего достаточно было всего лишь битик статуса впендюрить в УЛу, и снимать прерывание не тупо через короткое время, а только по факту очистки того бита статуса)
Одна часть "ракеты-носителя" была прикручена к шатлу в виде большого оранжевого бака, а другая часть после выработки всего топлива из того бака -- маршевые двигатели -- являлась собственно частью конструкции шатла и становилась мёртвым грузом на всё остальное время полета.
Далее, что шатл, что буран с момента отключения маршевых двигателей находились на незамкнутой орбите, и далее довыведение осуществляли собственными двигателями орбитального маневрирования. Так что формально "самостоятельный подъём на орбиту" осуществлял и буран тоже.
Это круто и рисково. В общем - творческое решение.
Как уже в коментах упомянули, это было стандартно. По дешёвке покупались отбракованные производителем микросхем половинки. Точно так же по дешёвке синклер покупал и основные 16кбит чипы, которые имели 3 (!) напряжения питания и уже к тому моменту были устаревшими. Обычное скупердяйство, а не "творческое решение". Ну и вообще, творчески решал там инженер, которого синклер нанял (Альтвассер). Наконец, тем же "творческим решениям" мы обязаны многочисленными просчётами в архитектуре спектрума.
В дополнение clang управляется не корпорацией, а обычным человеком.
Во-1 надо, чтоб было чем управлять. Программисты. Для проектов уровня шланга ли, файрфокса ли -- их надо много. Во-2, чтоб все эти программисты делали чонадо а не чохотят, им надо бабло платить. А бабло надо где-то брать. А вот лично вы давно ли донатили на развитие шланга? Правильно. Донатят корпорации, даже не донатят а платят за то, чтобы делали что им нужно. И тут уже "всегда можно форкнуть" перестаёт работать, т.к. такие громадные проекты форкнуть конечно можно, но вот мейнтейнить (апдейтить под новые стандарты с\c++, фиксить баги, добавлять платформы и языки) уже в 1 лицо не получится. Через несколько лет форк превратится в тыкву.
Всякие там го и расты -- как раз примеры вендорлоков, которые развиваются непойми кем и существуют в виде единственной имплементации (про го пишут что там несколько имплементаций, так что тут не точно). ГНУшники вроде пытаются свой растокомпилятор выкатить, но при отсутствии официального стандарта на язык им можно подкладывать свинью за свиньёй и их реализация никогда не сравнится с "настоящей", например.
Всё это означает, что сохранять и поддерживать гцц при наличии шланга -- крайне важно.
У кого-нибудь есть пример, как интегрировать в gnu make сборку precompiled header для gcc? Ну то есть нужно, чтоб во-1 зависимости инклуда, который предкомпилируется, прогенерились (по аналогии с тем, как можно автоматически генерить зависимости .c файлов от .h), а во-2 чтоб при изменении любого инклуда, от которого зависит precompiled header или при изменении его самого всё пересобиралось, в т.ч. зависимости.
И что ему запрещает работать как компаратор? До шин питания он конечно не дотянет, не rail-to-rail всё-таки, но как компаратор вполне работает, если какое-то особое быстродействие не нужно. И диодов встречно-параллельных у него между входами нет.
Ну а что не так? Примерно в одно и то же время задуманы, примерно одни и те же техпроцессы. Разница, опять же, налицо.
А сколько стоило то MMU, вы таки посмотрели? Ещё удвоить цену процессора? Соответственно, сильное сокращение рынка.
Интересно, сколько бы стоил 80286, если ибеме не выбрало бы себе 8088 чуть пораньше? Я думаю -- бесконечность, т.е. до него вообще не дошло бы. Аргументация вывернута с ног на голову, именно из-за того, что 68k не стал ширпотребом, он и оставался дорогим, а не наоборот.
потому что люди путались в таком количестве
Как интересно получается: в том, что loop только с cx, сдвиги только с cl и умножения-деления только с dx/ax -- люди не путались, а в абсолютно равноправных 8+8 регистрах путались. И компиляторы наверное ВООБЩЕ не занимались распределением регистров, фигачили всё через один? (хотя для 8086 -- охотно поверю). Но 8086 у нас офигенно ортогональный при этом. Выглядит как попытки манипуляции.
То, что я говорю, это не техническая проблема
Конечно индиректные адресации в 68020+ чуть усложнили декодинг, но во1 в любом коде (уж я-то видел кучи кода под 68к) они используются редко, во2 ввиду п.1 можно оптимизировать процессор под исполнение неиндиректных адресаций, а таковые прожёвывать медленно через микрокод (точно так же сейчас исполняют всякие rep movsb и scatter-gather в avx или где там). А без индиректных адресаций ВНЕЗАПНО декодирование опкодов в 68к становится сильно проще чем в х86. 1 или 2 слова опкод, из него сразу ясно, сколько каких аргументов/адресов и их размеры. В3, индиректные адресации не подразумевают записи в память при вычислении EA, а значит отменить всю цепочку операций можно без проблем на любом шаге. Итого -- проблема техническая, причём не требующая хай-перфоманс решения любой ценой.
погубил - не только m68k, но и другие архитектуры той разработки - в первую очередь VAX.
Он бы и x86 погубил, причем сильно раньше. Если бы случайно ибм не выбрало бы именно 8088. А как известно, оно руководствовалось отнюдь не системой команд и техническим совершенством, а какими-то локальными соображениями типа "под 8086 есть больше периферийных чипов". Откуда кстати сразу можно сделать вывод, что уровень инженеров, выдумывавших ibm pc был настолько низок. что они ниасилили бы даже 8255 подключить к 68000.
VAX кстати вполне себе упихивался силами DEC в чипы, причём именно с теми же оптимизациями -- особо микрокодные инструкции выносили чуть ли не на уровень программной эмуляции, сосредотачиваясь на простых. Ну и потом VAX был директивно погублен самой DEC после провозглашения ещё одной вундервафли alpha. Что было бы, если (предположительно) каким-то способом vax занял место 8088 в ibmpc -- никто не узнает. Но можно предполагать, что примерно то же самое.
Мало. Считайте, один. Но на объективность это не влияет.
Ну так напишите побольше. И чего-нибудь сложное, где регистров перестанет хватать. Или где массивчики за 64к вылезут.
С семейством m68k надо сравнивать 80386 и далее, а не 8086
Ага, давайте сравнивать 68000 из 1979 с 80386 из 1985
Защита памяти появилась в 80286, но не страничная
И оказалась даром никому не нужна. А ещё и адресация осталась 16-битной. Это через 3 года после 68000.
через два года после 80386.
То есть выяснили, что страничное MMU в 68k появилось за 3 года до 386.
Например, можно добавить содержимое D-регистра к памяти, но нельзя то же самое для A-регистра.
А давайте ещё регистры посчитаем. 8 штук D и 7 штук (не считая стека) A. А в х86 ВСЕГО 7 регистров. Или это не считается? Тогда становится неясно зачем амд добавило r8..r15 регистры, наверное дураки были, ведь и так было всё офигенно замечательно с "равноправными" регистрами, их 7 штук хватало всем.
кто-то постановил, как именно в каком порядке они проходятся,
Насколько я помню, в 68060 команды не могли продолжаться, только заново переисполняться. Ну и в x86 можно найти ужасы, типа rep movsb. И ничего -- живут как-то, на "микрокоде" дешифруют и исполняют. Так что это плохой аргумент -- технические проблемы вполне решаемые для OoO.
это чистый туман размытых воспоминаний
А вы сколько килобайт кода собственноручно написали для 68к? А то вдруг
Какой процент сэкономленных денег (т.е. сэкономленных на 1 экземпляре девайса * кол-во девайсов в партии) достаётся потом инженерам, которые всё это наэкономили?
Если замена хдд, который давал условно 100иопсов и 100 мегабайт в секунду на ссд, где тыщи иопсов и гигабайт в секунду даёт выигрыш хорошо если в 10%, то дальнейнее ускорение рамдиском, где иопсы и бендвиз ограничены скоростью чтения и копирования у процессора, вряд ли магически ускорит хотя бы в 2 раза что-то. C рамдисками я тоже экспериментировал, и ускорение там относительно ssd получалось для компиляции ещё меньше, чем от hdd->ssd.
Мой посыл был о том, что в задачи типичного компилирования c/c++ диск -- самое последнее место, в которое машина упрётся по ограничению скорости компиляции.
1) создаем виртуальный диск в оперативной памяти tmpfs и компилим на нём.
Много чего компилировал и компилирую, в т.ч. и в генте, но не помню случая, чтобы когда-то компиляция рогом упиралась бы в диск. Ну, конечно, замена хдд на ссд даст наверное 5-10% выигрыша по времени, но не более того (компиляция во все 32 потока на ryzen'е). Потому мне всегда странны рассказы о том, что "заменил диск -- стало в 2 раза быстрее компилироваться". Это наверное не про c/c++ типичные софты, как в линуксах.
Очевидно же, они перешли к O(N^2 * 2^(-N))! Новое слово в computer science! :)
"Профессионально разработанные" cortex-m аппаратно пушат кучу (но не все) регистров и точно так же тратят на это время, но только уже безусловно и всегда. А потом ещё и компитятор ручками сохраняет оставшиеся, если функция обработчика сложная с кучей расчётов, не лезущих в сохранённые аппаратно. Ну и наконец, никто и ничто не мешает впилить в конкретную эмбедскую risc-v корку расширение, подменяющее caller-saved регистры при входе в обработчик.
Вот странно. У вас "ой спорно", а у толпы олдов-фанатов пдп-11 не спорно...
Хотя со многим я согласен, достаточно было бы 1.5-адресных команд, как в 68k сделали и огромный косяк с ADC/SBC, который аж не поправили, а повторили в ваксе.
Не знаю почему это "диверсия", и откуда вы взяли что в 68к этого нет (как раз очень есть). И присмотритесь к арму или power, может и там оно окажется (опциональным для каждого опкода).
"68k" это "x86", а первый процессор семейства 68k это 68000. И как конкурент 286 он очень даже -- появился раньше, адресовал память сразу нормально, а не убого как 286, кусками по 64к.
х87 даже синусы считает неточно, попробуйте посчитать sin(M_PI) при помощи SSE(2) и при помощи х87.
А если вам не хватает 53 бит мантиссы, попробуйте для начала https://en.wikipedia.org/wiki/Double-double_(arithmetic)#Double-double_arithmetic
Ну очевидно же. Внешний девайс выставляет свое прерывание на /INT, если в этот же момент ула решит поддёрнуть своё, то оно потеряется.
Программе может потребоваться запретить прерывания на какое-то (короткое) время. Если в этот момент ула поддёрнет своё прерывание, то оно тоже потеряется, т.к. не висит до момента очистки процессором, а само по себе кончается. В этом и есть проблема
Нет конечно же, там 2 экранных буфера, каждый в своей собственной страничке 16к. Вот правда одна из них всегда воткнута с адреса 0x4000 и её можно воткнуть в 0xc000, а другая -- только в 0xc000 и втыкается. Как результат, если нужно работать с 2 экранными буферами, то извольте их втыкать в 0xc000,после чего в процессе рисования расширенная память оказывается недоступна. Или делайте промежуточный внеэкранный буфер а потом копируйте.
Фактически, там и так 16 килобайт видеопамяти было, но ула могла вынимать из них только те самые 6912. А если сделать 2 экранных буфера, это не значит что теперь нельзя использовать только один, всё остальное могло бы оставаться точно таким же (в т.ч. начало васика c 0x5c00 и т.д.).
Почему это "не в 48к же"? Какая логика стоит за таким выводом? В том же таймексе с теми же 48к памяти вполне себе сделали.
Представьте, что внешний девайс тоже захочет давать прерывания. Или что программа захочет по какой-то надобности запретить прерывания на скажем 10 мкс. Результатом будет неиллюзорная возможность терять кадровые.
А вот нифига. Разлиновка экрана была следствием того, что "чипсет" спектрума читал память в "page mode": один раз выдавал RAS-адрес и потом 2 раза читал с разных CAS-адресов. Благодаря этому в моменты чтения пикселей и атрибутов Z80 хоть и с тормозами, но мог продолжать работать с видеопамятью.
Я имел в виду например следующее:
можно было бы сделать 2 экранных буфера, например один с адреса 0x4000, другой с 0x6000.
можно было бы дополнительно сделать цветовой режим "байт атрибута на байт пикселей"
можно было бы прерывание сделать нормальным (для чего достаточно было всего лишь битик статуса впендюрить в УЛу, и снимать прерывание не тупо через короткое время, а только по факту очистки того бита статуса)
Одна часть "ракеты-носителя" была прикручена к шатлу в виде большого оранжевого бака, а другая часть после выработки всего топлива из того бака -- маршевые двигатели -- являлась собственно частью конструкции шатла и становилась мёртвым грузом на всё остальное время полета.
Далее, что шатл, что буран с момента отключения маршевых двигателей находились на незамкнутой орбите, и далее довыведение осуществляли собственными двигателями орбитального маневрирования. Так что формально "самостоятельный подъём на орбиту" осуществлял и буран тоже.
Как уже в коментах упомянули, это было стандартно. По дешёвке покупались отбракованные производителем микросхем половинки. Точно так же по дешёвке синклер покупал и основные 16кбит чипы, которые имели 3 (!) напряжения питания и уже к тому моменту были устаревшими. Обычное скупердяйство, а не "творческое решение". Ну и вообще, творчески решал там инженер, которого синклер нанял (Альтвассер). Наконец, тем же "творческим решениям" мы обязаны многочисленными просчётами в архитектуре спектрума.
Во-1 надо, чтоб было чем управлять. Программисты. Для проектов уровня шланга ли, файрфокса ли -- их надо много. Во-2, чтоб все эти программисты делали чонадо а не чохотят, им надо бабло платить. А бабло надо где-то брать. А вот лично вы давно ли донатили на развитие шланга? Правильно. Донатят корпорации, даже не донатят а платят за то, чтобы делали что им нужно. И тут уже "всегда можно форкнуть" перестаёт работать, т.к. такие громадные проекты форкнуть конечно можно, но вот мейнтейнить (апдейтить под новые стандарты с\c++, фиксить баги, добавлять платформы и языки) уже в 1 лицо не получится. Через несколько лет форк превратится в тыкву.
Всякие там го и расты -- как раз примеры вендорлоков, которые развиваются непойми кем и существуют в виде единственной имплементации (про го пишут что там несколько имплементаций, так что тут не точно). ГНУшники вроде пытаются свой растокомпилятор выкатить, но при отсутствии официального стандарта на язык им можно подкладывать свинью за свиньёй и их реализация никогда не сравнится с "настоящей", например.
Всё это означает, что сохранять и поддерживать гцц при наличии шланга -- крайне важно.
Если забить на гцц, то через несколько лет можно оказаться в той же ситуации что и с firefox vs хромой -- т.е. в корпоративном вендорлоке
У кого-нибудь есть пример, как интегрировать в gnu make сборку precompiled header для gcc? Ну то есть нужно, чтоб во-1 зависимости инклуда, который предкомпилируется, прогенерились (по аналогии с тем, как можно автоматически генерить зависимости .c файлов от .h), а во-2 чтоб при изменении любого инклуда, от которого зависит precompiled header или при изменении его самого всё пересобиралось, в т.ч. зависимости.
И что ему запрещает работать как компаратор? До шин питания он конечно не дотянет, не rail-to-rail всё-таки, но как компаратор вполне работает, если какое-то особое быстродействие не нужно. И диодов встречно-параллельных у него между входами нет.
Ну а что не так? Примерно в одно и то же время задуманы, примерно одни и те же техпроцессы. Разница, опять же, налицо.
Интересно, сколько бы стоил 80286, если ибеме не выбрало бы себе 8088 чуть пораньше? Я думаю -- бесконечность, т.е. до него вообще не дошло бы. Аргументация вывернута с ног на голову, именно из-за того, что 68k не стал ширпотребом, он и оставался дорогим, а не наоборот.
Как интересно получается: в том, что loop только с cx, сдвиги только с cl и умножения-деления только с dx/ax -- люди не путались, а в абсолютно равноправных 8+8 регистрах путались. И компиляторы наверное ВООБЩЕ не занимались распределением регистров, фигачили всё через один? (хотя для 8086 -- охотно поверю). Но 8086 у нас офигенно ортогональный при этом. Выглядит как попытки манипуляции.
Конечно индиректные адресации в 68020+ чуть усложнили декодинг, но во1 в любом коде (уж я-то видел кучи кода под 68к) они используются редко, во2 ввиду п.1 можно оптимизировать процессор под исполнение неиндиректных адресаций, а таковые прожёвывать медленно через микрокод (точно так же сейчас исполняют всякие rep movsb и scatter-gather в avx или где там). А без индиректных адресаций ВНЕЗАПНО декодирование опкодов в 68к становится сильно проще чем в х86. 1 или 2 слова опкод, из него сразу ясно, сколько каких аргументов/адресов и их размеры. В3, индиректные адресации не подразумевают записи в память при вычислении EA, а значит отменить всю цепочку операций можно без проблем на любом шаге. Итого -- проблема техническая, причём не требующая хай-перфоманс решения любой ценой.
Он бы и x86 погубил, причем сильно раньше. Если бы случайно ибм не выбрало бы именно 8088. А как известно, оно руководствовалось отнюдь не системой команд и техническим совершенством, а какими-то локальными соображениями типа "под 8086 есть больше периферийных чипов". Откуда кстати сразу можно сделать вывод, что уровень инженеров, выдумывавших ibm pc был настолько низок. что они ниасилили бы даже 8255 подключить к 68000.
VAX кстати вполне себе упихивался силами DEC в чипы, причём именно с теми же оптимизациями -- особо микрокодные инструкции выносили чуть ли не на уровень программной эмуляции, сосредотачиваясь на простых. Ну и потом VAX был директивно погублен самой DEC после провозглашения ещё одной вундервафли alpha. Что было бы, если (предположительно) каким-то способом vax занял место 8088 в ibmpc -- никто не узнает. Но можно предполагать, что примерно то же самое.
Ну так напишите побольше. И чего-нибудь сложное, где регистров перестанет хватать. Или где массивчики за 64к вылезут.
Ага, давайте сравнивать 68000 из 1979 с 80386 из 1985
И оказалась даром никому не нужна. А ещё и адресация осталась 16-битной. Это через 3 года после 68000.
То есть выяснили, что страничное MMU в 68k появилось за 3 года до 386.
А давайте ещё регистры посчитаем. 8 штук D и 7 штук (не считая стека) A. А в х86 ВСЕГО 7 регистров. Или это не считается? Тогда становится неясно зачем амд добавило r8..r15 регистры, наверное дураки были, ведь и так было всё офигенно замечательно с "равноправными" регистрами, их 7 штук хватало всем.
Насколько я помню, в 68060 команды не могли продолжаться, только заново переисполняться. Ну и в x86 можно найти ужасы, типа rep movsb. И ничего -- живут как-то, на "микрокоде" дешифруют и исполняют. Так что это плохой аргумент -- технические проблемы вполне решаемые для OoO.
А вы сколько килобайт кода собственноручно написали для 68к? А то вдруг
окажется не очень правдой.
Самый интересный вопрос после такого рассказа:
Какой процент сэкономленных денег (т.е. сэкономленных на 1 экземпляре девайса * кол-во девайсов в партии) достаётся потом инженерам, которые всё это наэкономили?
Лично я ничего не понял. Это там переменные резисторы что ли? С 3 выводами?
И ещё я не понял, в чём проблема изменить фазу сигнала на 180 градусов. Это же просто инверсия, не?
Если замена хдд, который давал условно 100иопсов и 100 мегабайт в секунду на ссд, где тыщи иопсов и гигабайт в секунду даёт выигрыш хорошо если в 10%, то дальнейнее ускорение рамдиском, где иопсы и бендвиз ограничены скоростью чтения и копирования у процессора, вряд ли магически ускорит хотя бы в 2 раза что-то. C рамдисками я тоже экспериментировал, и ускорение там относительно ssd получалось для компиляции ещё меньше, чем от hdd->ssd.
Мой посыл был о том, что в задачи типичного компилирования c/c++ диск -- самое последнее место, в которое машина упрётся по ограничению скорости компиляции.
Много чего компилировал и компилирую, в т.ч. и в генте, но не помню случая, чтобы когда-то компиляция рогом упиралась бы в диск. Ну, конечно, замена хдд на ссд даст наверное 5-10% выигрыша по времени, но не более того (компиляция во все 32 потока на ryzen'е). Потому мне всегда странны рассказы о том, что "заменил диск -- стало в 2 раза быстрее компилироваться". Это наверное не про c/c++ типичные софты, как в линуксах.