В дополнение 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++ типичные софты, как в линуксах.
предельная хардварная закопиращенность (можно посмотреть на все загородки в свежих хboх'ах, например, или в тех же айфонах)
Максимальный онлайн, который в совокупности с п.1 делает пиратство физически невозможным
Вы хотите, чтоб и книги были такими же? Ну так уже -- амазон киндл тот же. Вот только к этой поделке приближаться и на километр не хочется. А выше вполне рабочую модель предложили, с донатами/оплатой за продолжения.
И ваше утверждение, что мол "вы воюете с авторами" -- в общем случае неверно. Если я иду в магазин и покупаю бумажную книгу, то какая доля моих заплаченных денег за эту книгу уйдёт автору? 0.1%? Ну значит, на 0.1% с авторами воюем, и на 99.9% -- с копирастами.
Нужно давно было уходить от модели монолитного ядра как это сделали в Apple и Microsoft.
И как там, уже ушли? Теперь там замечательные драйвера ко всему в драйверной модели, но только те, которые дозволены вендором, когда он соизволил подписать драйвер? Шоб вам так жить.
Как выглядит процесс отладки написанного на зубиле (==chisel)? Ну вот сунули мы сгенерённый верилог-дизайн в симулятор вместе с тестбенчем, который ловит баг, а дальше? Какие сигналы в вейвы добавлять, что на них смотреть?
Как например делать правки в гейтах, если уж речь об АСИКах? С верилогом vs нетлистом (на верилоге же) примерно понятно как, а с зубилом?
upd: какая-то ерунда в каменте выше по иерархии. Продавать начали емакс, переписанный на си Гослингом, да и то с его согласия и не сразу. До этого момента емакс Гослинга тоже был свободно распространяемым, хотя и без формальной лицензии. Столлман его взял и стал развивать, по мере развития весь код Гослинга был удалён. В чём "возмущение" Столлмана в данном случае было -- неясно.
Во-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++ типичные софты, как в линуксах.
Пиратства там нет по 2 причинам:
предельная хардварная закопиращенность (можно посмотреть на все загородки в свежих хboх'ах, например, или в тех же айфонах)
Максимальный онлайн, который в совокупности с п.1 делает пиратство физически невозможным
Вы хотите, чтоб и книги были такими же? Ну так уже -- амазон киндл тот же. Вот только к этой поделке приближаться и на километр не хочется. А выше вполне рабочую модель предложили, с донатами/оплатой за продолжения.
И ваше утверждение, что мол "вы воюете с авторами" -- в общем случае неверно. Если я иду в магазин и покупаю бумажную книгу, то какая доля моих заплаченных денег за эту книгу уйдёт автору? 0.1%? Ну значит, на 0.1% с авторами воюем, и на 99.9% -- с копирастами.
Впечателение, что половина абзацев текста и половина фоток из прошлых статей. Пошла гонка за количеством?
ROTFL, это даже круче чем "статическая теория газов" от одного автора и проектировщика систем отопления тут!
Где-где подвесить?
И как там, уже ушли? Теперь там замечательные драйвера ко всему в драйверной модели, но только те, которые дозволены вендором, когда он соизволил подписать драйвер? Шоб вам так жить.
Из последнего: https://www.opennet.ru/opennews/art.shtml?num=62942 Теперь уже и светодиодиком вообще не помигать. Лучше пусть у меня будет возможность помигать, пусть и с сегфолтом.
Как выглядит процесс отладки написанного на зубиле (==chisel)? Ну вот сунули мы сгенерённый верилог-дизайн в симулятор вместе с тестбенчем, который ловит баг, а дальше? Какие сигналы в вейвы добавлять, что на них смотреть?
Как например делать правки в гейтах, если уж речь об АСИКах? С верилогом vs нетлистом (на верилоге же) примерно понятно как, а с зубилом?
А вы не путаете? Голый ксоршифт, без пост-обработки, дайхард как раз фейлит на ура. А пост-обработка включает в себя в т.ч. и умножения.
Ну нихрена себе. Автор переврал название (правильное -- NedoOS) и ещё какую-то "похожую судьбу" приписал. Репозиторий NedoOS вполне жив: http://nedoos.ru/svn/listing.php?repname=NedoOS
Ну и как водится, креатив грандиозен, автор молодец. Раз так.
upd: какая-то ерунда в каменте выше по иерархии. Продавать начали емакс, переписанный на си Гослингом, да и то с его согласия и не сразу. До этого момента емакс Гослинга тоже был свободно распространяемым, хотя и без формальной лицензии. Столлман его взял и стал развивать, по мере развития весь код Гослинга был удалён. В чём "возмущение" Столлмана в данном случае было -- неясно.
При этом лицензия GPL никак не запрещает брать деньги за софт...