Comments 105
Оптимизация памяти не умерла, как бы много памяти не было бы выкуплено, если криво ей пользоваться, то ее никогда не хватит. Алгоритмы изменились, это да.
конечно не умерла но сильно видоизменилась
раньше за проценты боролись
сегодня в разу подавай иначе время вложенное в оптимизацию не выгодно :-)
Борьба за проценты все еще выгодна, только уже в другой области – где используют слабые однокристаллки (SoC). Там "влез" по памяти и быстродействию в более дешевый чип – сэкономил, например, $2 на каждом устройстве. А серия в 10 тыс. штук. Как правило профит в $20k окупает содержание программистов, умеющих в оптимизацию.
сэкономил, например, $2 на каждом устройстве
Заменил stm32 чем то типа attiny? ;)
Почти :)
Например, ужался и в STM32F7xx серии влез в младшую модель на $1.4 дешевле (там цены в районе $10). А тот чип еще и в корпусе LQFP-144 вместо LQFP-208 (допустим линий I/O нам хватает там и там). Это 64 точки пайки, примерно по $0.01 каждая. Чуть меньше надо места на плате, чуть проще трассировка, чуть выше ремонтопригодность...
Мелочи. И все-таки на крупных сериях из них набегает заметная дельта по стоимости производства и обслуживания.
STM32F7xx
Монструозная палочка-выручалочка олдскулов, которые патологически не желают учиться линуксу, в котором из коробочки можно получить и сетевой стек, и драйвера камер, аудиокодеков, дисплеев, вместо того, чтобы полгода все это поднимать ручками. На ФОТ сливается многократно больше сэкономленного на стоимости камня.
Инструмент выбирается под задачу. Где-то линукс в самый раз, где-то RTOS, и там тоже есть драйвера периферии и различные стеки "из коробки". А иногда приходится отказываться не только от ОС, но и от HAL библиотек, и делать закат солнца вручную. Глазами отсматривать, какой ассемблерный код сгенерил компилятор и бороться, без преувеличения, за несколько тактов на самых горячих участках. Задачи разные бывают, как и железо.
Что выгоднее: влить деньги в "железо подороже + Linux" или "железо подешевле + bare metal + ФОТ", тоже зависит от вводных. Это если по уму. А если жить по принципу "пофиг на себестоимость, за все платит пользователь", то мы с этого и начали ветку )
влить деньги в "железо подороже + Linux" или "железо подешевле + bare metal + ФОТ"
Процессоры под линукс зачастую дешевле громоздких stm32f7xx. Даже с учётом внешней DDR3.
Процессоры под линукс зачастую дешевле
Не соглашусь с формулировкой. Иногда дешевле, но не зачастую.
Если не трудно, приведите конкретный пример недорого SoC и задачи, которую мы решаем, работая под Linux. Чтобы понимать, какие в этом случае есть альтернативы.
приведите конкретный пример недорого SoC
Для более предметного разговора можно было бы уточнить конкретный парт намбер вашего камня и что за устройство вы разработали (применяемые интерфейсы, периферия).
Предположим, вы используете STM32F767ZGT6. Стоит $7.88 за партию 120 штук.
Для сравнения процессоры:
MCIMX6Y2CVM08AB - $5.84 за партию 150 штук. Наша рабочая лошадка. У нас целая линейка серийно выпускаемых устройств на нем основана: базовая станция LoRaWAN, станция высокоточной навигации GNSS RTK, блок управления ГРК АГНКС/ПАГЗ, ПЛК контроллер, устройство SIP телефонии. Плюс несколько изделий на этапе разработки.
T113-S3 - $4.25 за партию 90 штук. Встроенная память DDR.
T113-i - $3.92 за партию 120 штук.
RV1106G2 - $4.12 за партию 152 штуки. Встроенная память DDR.
RK3308B - $3.82 за партию 120 штук.
STM32MP151CAB3 от того же STMicroelectronics - $3.92 за партию 200 штук.
STM32MP157AAC3 - $6.97 за партию 100 штук.
Думаю, этот список дешевых микропроцессоров легко можно дополнить еще десятками парт намберов.
RP2040 в разы дешевле, а Linux на нём умудрились запустить.
Спасибо за список. Allwinner и Rockchip довольно нишевые, кмк, я раньше в эту сторону не смотрел. Теперь буду иметь в виду.
Всем чипам из списка нужна внешняя NAND, большинству – DDR. Было бы честно плюсовать их к стоимости процессоров. В целом решение получается намного круче "голого" STM32F7xx, это очевидно.
Но иногда такие объемы памяти просто не нужны. А нужен deep sleep с потреблением в несколько мкА и сохранением состояния системы.
Что было в моем случае: если упрощенно - приемник и ретранслятор. Слушал несколько каналов (цифровой поток порядка 1 Mbps); демодуляция, декодирование и разбор протокола – в софте. Снаружи там чисто аналоговая часть, выход компаратора с детектора огибающей смотрел прямо в чип.
Сохранял услышанное на SD карту. Что-то должен был передать дальше. Собственно, большую часть SRAM съели буферы, сам код и логика были достаточно простые. Батарейное питание. Конфигурация – через файл на той же SD карте.
Точную модель контроллера уже не вспомню, простите. Что-то из F7хх серии в корпусе LQFP-144.
А если вы работаете от батарейки? Есть подозрение, что уводить в сон/будить такой процессор с запущенным Linux энергетически дороже, чем stm с rtos/проприетарным кодом.
Так тут опять ответ зависит от кучи вводных. С одной стороны смартфоны и прочие гаджеты на Linux/Android давно работают от батареек. С другой стороны, на копеечные Padauk не то что Linux, даже RTOS не влезет.
Так же и с RAM. Если она статическая, то может потреблять буквально микроамперы. А если динамическая - то потребление подскакивает на порядки и от CR2032 её не прокормить.
Ну и наконец, насколько вообще в данной задаче нужен Linux? Например, реализовать аналог OpenWRT на HAL можно, но стоимость такой разработки будет астрономическая. И наоборот, для беспроводного датчика температуры и влажности с LCD индикатором восьмибитного МК хватит. И будет он больше года от CR2032 работать.
Можно было б списать на олдскулов, если б они стоили пять копеек за пучок. Бизнес рулит, наймёт и ньюскулов и рептилоидов, если это актуально.
Вот навскидку несколько позиций, которые актуальны, кроме цены:
потребление,
габариты, вес,
устойчивость к воздействию внешней среды: температура, вибрация, электромагнитные воздействия и т.п.,
требование национального производителя, внутреннее производство, санкции и т.п.,
сертификация для определённого применения.
Иными словами, вопрос несколько более комплексный, хотя, могу согласиться, что где-то может сыграть фактор инерционности знаний и мышления
несколько позиций, которые актуальны, кроме цены
ФОТ забыли. В текущих реалиях ФОТ является определяющим фактором. Железо в наше время стоит дешево как грязь. Экономить доллар-два в себике изделия при зарплатах $2000+ бессмысленно. Собственно поэтому экономически мало оправдано что-либо разрабатывать в России. При таких скромных объемах рынка затраты на разработку рискуют не окупить никогда. Ситуация усугубляется тем, что из-за
инерционности знаний и мышления
олдскулов, которые так и норовят удариться в полугодовую реализацию с нуля того, что уже давным давно было разработано и подключается в сборку линукса одной строчкой: сетевой стек, аудиокодеки, видеокамеры, юсб устройства и т. д. Еще на этапе разработки обнуляют перспективы коммерциализации продукта, зато потом ходят надувают щеки: вот, сэкономил доллар... А то, что ФОТ раздулся на $20000 выше запланированного мало кого интересует.
ФОТ я б всё же выделил в отдельный топик. Тут надо осторожно как с изобретателями велосипеда, так и с любителями попробовать новый фреймворк, про который прочитал или услышал, так и с всё переписать фром зе скретч.
Не то, чтоб они не были правы в конкретно взятом случае, но нужно считать, причём не только ФОТ на саму разработку, но и в последующую поддержку, риски. Будет ли кому тот код поддерживать. Тут сталкивался с двумя крайностями от кода в процедурном стиле с кучей копипастов и ассемблерных вставок от условного олдскула до любителей затянуть весь сахар нового стандарта и все недавно изученные паттерны. В обоих случаях возникает языковая избыточность и неудобство для поддержки, больше шанс получить баг при модификации.
Короче, соблюдать баланс, всё считать и учитывать мнение и возможности коллег
А то, что ФОТ раздулся на $20000 выше запланированного мало кого интересует.
Работать с известным устройством - это обычно уменьшает и ФОТ, и прочие затраты, чем строить проект на пусть более гибком, но неизвестном устройстве, по которому нет ни опыта применения, ни знания подводных камней. Так-то вышеперечисленное и для STM32 существует, и имеет софтовую поддержку.
Расскажите, как линукс позволит сократить ФОТ, если в требованиях к устройству чётко сказано "работать не менее 90 дней от двух аккумуляторов типоразмера 18650" . Довольно массовое устройство, я лично принимал участие в его разработке.
Похвально, что вам доводилось разрабатывать беспроводной датчик LoRaWAN. Покажите, где я утверждал, что для этой задачи нужен Линукс?
Вот тут:
https://habr.com/ru/articles/908196/comments/#comment_28284764
В моём случае - это было устройство, которое должно было просто лежать, и ждать события. А как только событие произойдёт - развить очень бурную деятельность. Линукс можно "утоптать" в 1 мА потребления?
Копипаста этого комментария:
Монструозная палочка-выручалочка (ПРИМ. STM32F7xx) олдскулов, которые патологически не желают учиться линуксу, в котором из коробочки можно получить и сетевой стек, и драйвера камер, аудиокодеков, дисплеев, вместо того, чтобы полгода все это поднимать ручками. На ФОТ сливается многократно больше сэкономленного на стоимости камня.
Где здесь утверждается, что линукс нужно применять в батарейных устройствах с нано-микро-амперным потреблением в спящем режиме?
полугодовую реализацию с нуля того, что уже давным давно было разработано и подключается в сборку линукса одной строчкой
Любители расставлять галочки в конфигураторе легко впадают в ступор на пол года, когда дело доходит до жесткого тайминга (это когда RTOS не вывозит). Банально подключить десяток i2c/1w уже надо уметь, чтобы данные не терялись. Не говоря уже про управление силовыми ключами.
У вас просто задачи такие. Блок тормозов в машине у вас тоже на линуксе? Или любой промышленный частотник? Или пульт от ворот? Миллион применений где линукс даром не впился.
Миллион применений где линукс даром не впился.
А где я утверждал обратное? Все что я сказал, - то, что применение STM32F7xx - это маркер того, что олдскул, не умеющий в линукс (и старательно это скрывающий), возможно пытается за бареметалить типично линуксовую задачу.
применение STM32F7xx - это маркер того, что олдскул, не умеющий в линукс
Откровения уровня "наличие у человека рук и жопы это маркер того, что он рукожоп".
Но то, что у вас в тексте появились слова "маркер" и "возможно" это уже хорошо.
Линукс можно "утоптать" в 1 мА потребления?
Кстати можно было бы попробовать. Задача интересная. Но потребление лучше конкретизировать в ваттах. А то 1 мА от сети 220(230)В можно наверное и винду утоптать. Как минимум надо найти совместимое железо которое умеет спать с сохранением памяти и регистров примерно в половину этого.
Любители расставлять галочки в конфигураторе
Вы это точно про Embedded Linux? Вы с ним работали?
На самом деле разработка под Embedded Linux на порядок сложнее bare metal. Большинство ногодрыгальщиков впадают в ступор от одного только факта, что вместо привычной графической среды разработки предлагается зияющая чернотой консоль.
Отсюда и растут уши рассказов о борьбе за каждый доллар - ничего кроме ногодрыганья на стм-ке не осилили, - ни линукс, ни плис, - вот и вынуждены все-все-все реализовывать на том, что осилили, вместо того, чтобы под каждую конкретную задачу выбирать наиболее оптимальный инструмент.
Кстати, реальная история про галочки в конфигураторе.
Взял в работу незатейливое устройство. Сводится к тому чтобы с датчика переслать данные в смартфон. Работы на пару вечеров. Железо выбрано заказчиком и прописано в тз. Даже не надо тратить время на выбор.
Ну я открываю фреймворк, нахожу нужные библиотеки, всё на месте. Но я же не дурак, библиотеки разные бывают, по этому открываю заголовочный файл, листаю функции, смотрю параметры, что вынесено в настройки и т.п. Ну вроде всё ок. В крайнем случае исходники есть, всегда можно поправить, наколстылить.
Делаю железку, заливаю прошивку. Тишина. Ни ошибок ни признаков жизни. Там проверил, сям проверил - всё нормально, открываю имплементацию, а там:
function_name (...){
// not implemented yet
}Вообще косых фреймворков сей час хватает. Всё просто и быстро пока работает и пока хватает функционала. Но словил редкий глюк или нужна более глубокая кастомизация, и вся экономия вылетает в трубу.
Самый интересный вопрос после такого рассказа:
Какой процент сэкономленных денег (т.е. сэкономленных на 1 экземпляре девайса * кол-во девайсов в партии) достаётся потом инженерам, которые всё это наэкономили?
Из личного опыта: не больше 10% в виде разных бонусов (премии, повышения, небольшой процент с продаж конкретно этих девайсов и пр). Но собственный опыт – слишком маленькая выборка )
Я-то этот пример приводил с другой целью. Показать ситуацию, когда дополнительные затраты на оптимизацию экономически выгодны для организации в целом.
Предвидя возражения, уточню: это не про затягивание разработки (сроки и TTM никто не отменял), а про окупаемость затрат на "мозги" и на "сделать хорошо".
Кому мало RAM будет - пусть новый компьютер покупают!
Рекламный девиз мелкомягких.
Рекламный девиз мелкомягких
А что этот девиз рекламирует? Какие именно компы? :)
Любые, лишь бы поддерживали Windows11.
Любые
Интересная рекламная стратегия ;) Никогда не видел, чтобы рекламировали любой стиральный порошок или любой автомобиль,( чтобы ездил). А с компами это работает
Есть альянсы производителей, венчурные фонды (под которыми ряд перспективных стартапов, которые почти гарантированно взлетят, если чуть заранее спровоцировать спрос), и реклама без бренда - это давно такая же обычная вещь, как и классическая реклама. Просто она тоньше и аккуратнее классики, так как ее цель не грубо впарить и забыть, а отрытие новых рынков либо создание потребности в том, что до этого было никому не нужно. Тут важно не спугнуть потенциального потребителя.
купил тут на днях себе Macbook Air 13 M4, внезапно сразу же после запуска с запущенным Safari занято 7 из 16 GB, ну спасибо майкрософт, и тут переиграл меня)
Видимо такие компы, на которых пойдет вин11. Если у тебя комп ее не тянет - продай, сдай в утиль и срочно беги за новым. Что значит "тянет"? Винда ругается- значит плохой, негодный комп. Им то по барабану, чей комп ты купишь, им главное свою систему втюхать и завязать на свое облако.
Вот поэтому микропроцессоры Motorola были лучше, чем интелловские - могли адресовать 16 мегабайт памяти без этих извращений.
Интерфейс компьютера Next был лучше, чем у Windows, однако всё в итоге решает цена...
Интерфейсы Next унаследовала MacOS, они не исчезли просто так. В том числе, Виндовс 11 позаимствовал различные моменты из MacOS.
Где оно в Макосе? И тем более в Виндовс...
ЗЫ: Про Полуось в статье на том сайте дальше, это не подпись, а заголовок )
Предполагаю, что имеет место излишнее обобщение. Next явно повлиял на MacOS X ранних версий, скриншоты можно посмотреть тут. Microsoft заимствовала дизайнерские решения Apple - мне это стало очевидно после того, как удалось потыкать старенький G4 после нескольких лет с Windows 7. С Win 11 уже не работал, так что и говорить про неё не буду
Три колонки внизу слева — Finder, слева сверху — меню, только оно теперь горизонтальное вверху, справа — Dock, теперь внизу горизонтально. Классы с префиксом NS — это из NextStep.
Ну так я именно об интерфейсе говорю, а не о классах: изменилось расположение, в сторону "горизонтальных баров".
Почему-то многим это удобнее (как в Виндовс?), хотя ИМХО как раз в оригинальном варианте было лучше:
- меню бывает нужно разве что в самом начале, потом всё на хоткеях - зачем же оно постоянно место отжирает зря?
- док полезен для апплетов-индикаторов, которые всё время на виду, и при этом сбоку для них можно выделить больше места, чем в горизонтальном трее. Особенно на широкоформатном экране - он и так широкий
Ну, в общем, вкусовщина )
микропроцессоры Motorola были лучше, чем интелловские
В плане адресации - да. В остальном - нет. Когда пришла возможность делать out-of-order исполнение, для десктопных процессоров это начало 1990-х, линия m68k умерла потому, что была over-CISC в массе деталей, как именно исполняется команда, какое количество и сложность режимов адресации, и введя эти детали в спецификации своего ISA. А у x86 такого ограничения не было. По тому, например, что в командах (кроме строковых и всяких служебных) не более одного операнда в памяти, она оказалась ближе к требуемому в новые времена (RISC) и потому выжила. Конечно, правительство этому помогло (см. историю про ASCI Red), но это лишь ускорило на несколько лет неизбежную смерть m68k. А у x86 к тому времени был отлаженный 32-разрядный режим.
(Кстати, почему только 16MB? Адрес 32-разрядный, значит, наступал период обновления. Немного раньше S/370 прошла этот путь, 370/XA расширило адрес с 24 до 31 бита. И там было много граблей в первую очередь с софтом, пришлось добавлять режим 24-битной адресации для старого пользовательского кода, а ядерный пришлось массово переписывать, где он зависел.)
Не только в плане адресации. Защита памяти 8086 — нет, 68000 — есть. Режим супервизора — 8086 — нет, 68000 — есть. А главное — 8086 — архаичная система команд со всякими аккумуляторами и специальными регистрами типа sx, dx, 68000 — ортогональная к регистрам, очень логичная система команд.
[1. С семейством m68k надо сравнивать 80386 и далее, а не 8086. Защита памяти появилась в 80286, но не страничная. В линии m68k она появилась не в 68000, а в 68010, а это уже 1982 - то есть он ровесник 80286; но у 68010 это требовало внешнего MMU, решение было не из дешёвых (тогда). 68020 аналогично требовал внешнего MMU. Только с 68030 они смогли впихнуть MMU внутрь, а это уже 1987, через два года после 80386.
2. Неортогональность по регистрам в 32-битном режиме x86 значительно снижена - именно там, где она била больше всего (режимы адресации). То, что она остаётся и сейчас в вариантах типа косое умножение с результатом в xDX:xAX, переменный сдвиг в CL - ни на что реально не влияет.
3. У m68k нет полной ортогональности по регистрам. Например, можно добавить содержимое D-регистра к памяти, но нельзя то же самое для A-регистра. К A-регистру нельзя добавить произвольную константу. ADDx (аналог ADC) не работает на A-регистрах. То же про битовые операции. Однобитовые операции типа BFCHG не разрешены почему-то для режимов типа (An)+. Когда вы говорите
ортогональная к регистрам, очень логичная система команд
вы почему-то игнорируете все эти тонкости и нелогичности.
4. Зато есть безумные двойные косвенные режимы типа ([bd,An],Xn,od). Именно они убили всю архитектуру: перевести их на out-of-order исполнение оказалось просто невозможно, причём не технически, а административно: кто-то постановил, как именно в каком порядке они проходятся, для возможности восстановления с любой промежуточной точки. X86 как более примитивный таки избежал этого.
Мне, конечно, нравятся некоторые аспекты m68k, но именно из-за описанного в конце не считаю её настолько лучшей. Мнение типа "m68k была заведомо лучше x86" - это чистый туман размытых воспоминаний, подкрепляемый фанатичными ненавистниками x86. Я пытаюсь быть объективным:)
С семейством 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к? А то вдруг
Я пытаюсь быть объективным
окажется не очень правдой.
А ещё и адресация осталась 16-битной. Это через 3 года после 68000.
где вы видели в х86 16-битную адресацию? Наверное имелось ввиду, что адресация не стала 32-битной? Ну так и не должна, процессор то 16-битный. Однако по сравнению с 8086 и 8088 количество адресных линий возросло с 20 до 24
Наверное имелось ввиду, что адресация не стала 32-битной? Ну так и не должна, процессор то 16-битный.
Здесь нет однозначной связи. System/360 Model 30 имела 8-битное АЛУ, шины вокруг него, исполняла всё однобайтными порциями. При этом у неё был полный набор 32-битных операций арифметики, и 24-битный адрес (когда младшие модели продавались с 4KB памяти и это уже стоило чудовищных денег, это было реально дофига). Позже, Z80 имел 4-битное АЛУ, но работал в основных командах с 8-битными данными, в части с 16-битными.
А вот то, что одним сегментом нельзя было адресовать больше 64KB, и вообще сегментация защищённого режима в 80286 - который был урезанной версией выбредка кого-то из отцов Intel, пытавшимся ещё что-то получить от мёртворожденного iAPX432 - это тут более существенно. В плюс Мотороле то, что они сразу попытались использовать плоский режим, без этих извращений - и тут не было потерь в скорости.
Однако по сравнению с 8086 и 8088 количество адресных линий возросло с 20 до 24
Только из-за ограничений стиля это было сильно неудобно. Полноценное использование началось уже с 386.
да, я оказывается запамятовал как защищенный режим в 286 был реализован, потому как никогда не использовал
Здесь нет однозначной связи
Да, вопрос терминологии. Но думаю, что x86 процессоры до 386 никто 8-ми битными еще не называл.
Наверное в общем случае наиболее правильно под битностью понимать размер машинного слова в командах к АЛУ, но и здесь наверняка куча исключений есть.
Ага, давайте сравнивать 68000 из 1979 с 80386 из 1985
Нет, ниже было в подробностях - сравнивать нужно диапазон 68010 - 68030.
Хотя вы можете сравнить и 8086 с 68000, конечно. 68000 на три года позже (реальные продажи - 1981), так что к IBM PC он катастрофически опоздал.
То есть выяснили, что страничное MMU в 68k появилось за 3 года до 386.
А в S/370 оно появилось на ≈10 лет раньше, и что?
А сколько стоило то MMU, вы таки посмотрели? Ещё удвоить цену процессора? Соответственно, сильное сокращение рынка. Аналогичный пример был с 8087, пока в 386-е не начали вкладывать FPU блок - его ставили только в специализированные машины.
А давайте ещё регистры посчитаем. 8 штук D и 7 штук (не считая стека) A. А в х86 ВСЕГО 7 регистров. Или это не считается?
С количеством регистров - я безусловно согласен, их в 2 раза больше (или 2.5, как считать). Вопрос в том, насколько это влияло на удобство работы кода - в те-то времена. Когда разрабатывалась PDP-11, например, в ней не захотели делать больше 8 регистров, потому что люди путались в таком количестве. Компиляторы стали заметно продвинутее только где-то с середины 1990х, потому что начала разрабатываться теория в современном виде, до этого они были совершенно топорными. Это требует серьёзного рассмотрения, была ли польза с тех 16 (15, неважно).
А вот то, что сейчас ностальгически вспоминается то, чего не было - якобы полная ортогональность - это факт бесспорный.
Тогда становится неясно зачем амд добавило r8..r15 регистры, наверное дураки были
Когда именно AMD их добавила? Это было на 10 лет позже. Для индустрии в те времена это чудовищный промежуток, поменялось практически всё. Про компиляторы я уже говорил, см. выше. Уже набрался опыт и с RISC-процессорами сразу нескольких архитектур, и SSA начали вводить. А вот на 1979 такое было критически мало где, я с ходу только S/370 вспомнил.
Насколько я помню, в 68060 команды не могли продолжаться, только заново переисполняться. Ну и в x86 можно найти ужасы, типа rep movsb. И ничего -- живут как-то, на "микрокоде" дешифруют и исполняют. Так что это плохой аргумент -- технические проблемы вполне решаемые для OoO.
То, что я говорю, это не техническая проблема, после того, как зафиксировали то, чего фиксировать не надо было.
68060 вышел в 1994, это уже был закат. Тут надо уточнить историю, возможно, они ввели несовместимое изменение, но уже опоздали. Факт то, что мозговой заклин на супер-CISC, когда его времена давно ушли, мог - и скорее всего он в первую очередь и погубил - не только m68k, но и другие архитектуры той разработки - в первую очередь VAX.
А вы сколько килобайт кода собственноручно написали для 68к?
Мало. Считайте, один. Но на объективность это не влияет. У меня нет никакой повышенной любви к архитектуре x86 - можете погуглить, какими словами я её ругаю. Но то, что из-за меньшего количества CISC-like наворотов она оказалась более подготовленной к повороту в сторону OoO и RISC - чисто объективный факт, не признавать его нельзя.
Аналогичный пример был с 8087, пока в 386-е не начали вкладывать FPU блок
FPU появился в 486DX все-таки, если я правильно понял суть вашего коментария. В 386 как и раньше это был отдельный чип
Хотя вы можете сравнить и 8086 с 68000
Ну а что не так? Примерно в одно и то же время задуманы, примерно одни и те же техпроцессы. Разница, опять же, налицо.
А сколько стоило то 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к вылезут.
Аргументация вывернута с ног на голову, именно из-за того, что 68k не стал ширпотребом, он и оставался дорогим, а не наоборот.
Вы переоцениваете вклад больших партий. Есть объективная цена производства - та самая, которая по расширенному закону Мура падала экспоненциально - и она не давала слишком быстрых результатов.
Интересно, сколько бы стоил 80286, если ибеме не выбрало бы себе 8088 чуть пораньше? Я думаю -- бесконечность, т.е. до него вообще не дошло бы.
Хороший вопрос. Возможно, Intel бы умер или ушёл чисто в производство памяти. Что именно IBM дала жизнь линии x86 - не вижу причин спорить с этим.
Но то, что я говорю - что x86 не был настолько плох на общем фоне, а m68k, например, соответственно не настолько лучше остальных, чтобы его проигрыш создал трагедию.
Как интересно получается: в том, что loop только с cx, сдвиги только с cl и умножения-деления только с dx/ax -- люди не путались, а в абсолютно равноправных 8+8 регистрах путались.
Да. Это не мой тезис. Я тоже немного удивлён. Но если такое приписывают создателю PDP-11, наверно, это соответствует общему пониманию в те времена.
Напоминаю, что вокруг - в среднем и нижнем ценовом сегменте - были чуть ли не тотально архитектуры на один аккумулятор, потому что иначе было дорого. S/360 с её почти равноправными регистрами, кроме старших моделей, стоивших миллионы, была сделана на микропрограммных автоматах, и равноправность регистров эмулировалась на микропрограммном уровне. На этом фоне уже 8 честных регистров PDP-11 (хоть, опять же, напрямую использованных в АЛУ только в старших моделях) было прогрессом.
За 10 лет после этого (считаем до 1979-1981) упаковка в формат микропроцессора только усилила давку по ресурсам. 8008, 8048, 8080, 6502 - один аккумулятор. 6800 - два почти равноправных аккумулятора - это нечто особенное, так больше никто не делал. Чуть более высокий сегмент, PDPшки все кроме 11-й - тоже один аккумулятор во главе. Граница до честных почти равноправных регистров как в PDP-11, S/360, S/370 - это было очень существенно.
Насколько этот стиль влиял на всех - не мне судить, я тогда только в детский сад ходил. Но если вокруг были почти везде одноадресный мир - это не могло не влиять.
Тут бы послушать более детально воспоминания тех, кто всё это проектировал.
И компиляторы наверное ВООБЩЕ не занимались распределением регистров, фигачили всё через один? (хотя для 8086 -- охотно поверю).
Занимались, но очень плохо по сравнению с нынешним уровнем. Сейчас только толковый спец в тонкостях архитектуры сможет систематически обгонять компилятор по качеству кода. Тогда - мог любой, кто знал ассемблер, и вопрос был только в объёме работы.
Но 8086 у нас офигенно ортогональный при этом. Выглядит как попытки манипуляции.
Ваши приписки про "офигенно ортогональный" и домыслы про манипуляцию прошу оставить при себе.
Конечно индиректные адресации в 68020+ чуть усложнили декодинг, но во1 в любом коде (уж я-то видел кучи кода под 68к) они используются редко
И что, от этого их свалили бы на микрокоманды, а остальное - на полноценный автомат? Я конечно не спец по OoO, но мне кажется, что это было бы сильно сложно. А поддерживать всю эту хрень таки надо было бы.
Итого -- проблема техническая, причём не требующая хай-перфоманс решения любой ценой.
А вот тут я сильно не уверен. Полноценный OoO на старте был чудовищно дорог в разработке. Intel вытянул его, по слухам, только с государственной помощью, получив заказ на 4e8$$ "за красивые глаза". И это при том, что меньше всяких индиректных, автодекрементных и прочих адресаций. С ними шансы вытянуть разработку, мне кажется, нулевые. Опять же, есть поле для раскопок.
Откуда кстати сразу можно сделать вывод, что уровень инженеров, выдумывавших ibm pc был настолько низок. что они ниасилили бы даже 8255 подключить к 68000.
Уровень у них был как раз очень хорошим. Задачу вложить в минимум аппаратных средств всё что нужно они отработали почти идеально. Лучше них только Возняк был с Apple II, там вообще шедевры инженерного строения.
Рассказы про "больше периферии под 8086" явно не соответствуют историческим фактам. А вот то, что 68000 в 1979 только анонсировался, в 1981 начали производить (а первые версии всегда проблемны), а вот для 8088 был к моменту опытных прототипов IBM PC уже второй источник от AMD - вот это то, что как раз повлияло.
Ну так напишите побольше. И чего-нибудь сложное, где регистров перестанет хватать. Или где массивчики за 64к вылезут.
Опять же, тут надо сравнивать с 386 - где нет проблем с переходом за 64KB. Хотя в huge режиме в 8086 их тоже не очень было:)
"Сложное, где регистров перестаёт хватать" - таких задач было достаточно мало. Опять же напоминаю про качество компиляторов.
Если бы случайно ибм не выбрало бы именно 8088
А в чем там случайность вы видите? Выбирали из 3х процессоров, из которых m68k еще не был готов несколько лет и ИБМ не вошла бы в рынок, а TMS9900 был вообще без регистров
из-за того, что 68k не стал ширпотребом, он и оставался дорогим
кмк не был он дорогим. 400 фунтов готовый комп, ну добавим 200 на MMU все равно в разы дешевле IBM пустого за 1600$
только нафиг там MMU не нужен был потому что цена за мегабайт к примеру была еще дороже IBM
Если бы случайно ибм не выбрало бы именно 8088. А как известно, оно руководствовалось отнюдь не системой команд и техническим совершенством, а какими-то локальными соображениями типа "под 8086 есть больше периферийных чипов".
Во-первых, не руководство IBM. IBM PC возник вопреки неповоротливому руководству.
Во-вторых, подразделение, разрабатывавшее IBM PC, делало это в сжатые сроки и использовало обвязку от i8080, а она от микросхем окружения i8086/8088 отличается. Те же интервальные таймеры программируются по-другому. Intel нарвалась уже на то, что i8086 оказался никому не нужен, то же самое произошло и с остальным окружением. Обвязка i8080 была хорошо знакома разработчикам, и обновлять её смысла не было никакого.
В-третьих, периферийные чипы должны быть в ассортименте с процессором, и как приколхозить чужие порты ввода-вывода - это не проблема разработчика аппаратуры. Будь у вас хоть трижды прогрессивный процессор, если подключение к нему периферии доставляет проблемы, потребитель выберет другой комплект. Ему ещё и программировать надо, а не только плату собрать, не забывайте об этом.
В четвёртых, IBM разработала компьютер на перспективу, в чём ни разу не ошиблась. На счёт 64 кБ сегментов и удобства программирования такой организации памяти, вы рассуждаете задним числом. Во время запуска IBM PC 5150 на рынке преобладали i8080/8085 и Z80 с 64 кБ памяти. Учитывая данный факт, IBM планировали перетащить годное программное обеспечение с 8-битной платформы на 16-битную. Даже операционную систему они хотели по типу CP/M. И только раздолбайство Гари Килдалла не дало этому произойти.
Аргументация вывернута с ног на голову, именно из-за того, что 68k не стал ширпотребом, он и оставался дорогим, а не наоборот.
68k отнюдь не был малораспространённым процессором. Наоборот, в 1980-х он применялся повсеместно - от профессиональных машин Apple до массовых домашних Atari/Amiga, и бесчисленных 16-битных игровых приставок, там только официальных Сега Мега Драйв было продано этак миллионов тридцать, не говоря уже про клоны.
Так многие опускают, что память напрямую связана и с быстродействием. Приложение хоть раз должно записать и хоть раз прочесть что-то из выделенной памяти. А скорее всего много, много раз. Если память много, то и время обработки большое. Если мало, то и программа быстрая. Конечно, все несколько сложнее, но суть такая.
BIOS начинался с 0xF0000, а вот видеобуфер как раз с 0xA0000. И именно он ограничивал память основного сегмента. Загружая драйвера и некоторые резидентные программы в свободные области памяти между видеобуфером и BIOS, можно было заметно сэкономить память в основном сегменте.
Самое смешное, что уже в i80286 DOS получал доступ к дополнительным ~64К памяти, благодаря тому, что смещение относительно сегментного регистра могло пересекать мегабайтный барьер.
Точно, там же еще видеопамять была )
Самое смешное, что уже в i80286 DOS получал доступ к дополнительным ~64К памяти, благодаря тому, что смещение относительно сегментного регистра могло пересекать мегабайтный барьер.
HMA, ага, поздние ДОСы умели использовать эту область и предоставляли API, чтобы выделять там память.
На самом деле ограничение 640К, это не из-за подпрограмм BIOS, да и вообще такого ограничения не было ни в IBM PC, ни в IBM PC XT. Это ограничение появилось только в компьютере IBM PC AT в 1984-м году, потому что после 640К там начиналась область видеопамяти для EGA-адаптера.
В PC XT же можно было поставить с помощью плат расширения до 704К, если там видеоадаптер MDA, или до 736, если там CGA
Да, про видеопамять напомнили.
А платы расширения - это такой редкий зверь, что о них вроде где-то писали, но у нас их тогда не было...
Платы расширения памяти а-ля RAMpage тогда стоили совсем уж неприличных денег. И это был единственный способ расширить не так чтобы и большую память тех компов. Привычных планок памяти тогда же ещё не было, память просто распаивалась на материнке, и её там было мало. Ранние IBM РС умели только в 64К памяти, потом в РС ХТ максимум стал до 256К, и АТ увеличила до 512К.
Не совсем так. Как я помню, первые IBM PC поддерживали до 256кб. PC XT уже поддерживали до 640кб. Я сам тогда пользовался Искрой 1030 с 512Кб памяти. AT уже были на 286 процессоре и могли, вроде, то ли в 4Мб то ли в 16Мб - тут точно не помню уже
Неа, первые IBM PC поддерживали или 16, или 64К памяти, это было обусловлено чисто технически, там ОЗУ было на том древнем n-MOS процессе,который требовал напряжение смещения подложки, соответственно, на материнке не было даже разведено соответствующих линий адреса, эти пины там использовались для подводки напряжения смещения. Но вот через пару лет, как раз к выходу ХТ, они перешли на новые чипы, работающие только от +5В, и добавили ещё две линии адреса, и тогда уже поздние IBM PC стали поддерживать столько же памяти, сколько и PC XT, 256К.
Я сам тогда пользовался Искрой 1030 с 512Кб памяти.
Я только про оригинальные IBMовские компьютеры начала 1980-х пишу. Все те бесчисленные клоны, аналоги или просто сделанные "по мотивам", которые выходили во второй половине 1980-х, и в СССР, и за границей, от них уже несколько отличались, хотя как раз тогда и более-менее сформировался канон "640К"
Ну а 286 имел ограничение памяти до 16 мб, хотя найти такую конфигурацию тогда было нереально. В основном 2-4 метра они имели.
Канон 640К образовался исходя из кол-ва адресных линий в 8086\8088.
Их всего 20, что позволяет в принципе адресовать 1МБ памяти. Но кроме набортной рамы, нужна еще пямять для отображения на девайсы, вот и выбрали для физической памяти верхнюю границу в 640К, сразу, на первом писюке (5150), а не когда-то потом.
Обратите внимание, что кроме 286-AT (5170) существует еще 286-XT (5162) и там, не смотря на то что у проца 24 адресных линии, адресовать можно все равно только мегабайт, причем физ памяти не более пресловутых 640К. EMS карточки на мегабайты не в счет, они через окно в первом мегабайте работают, переключая свои банки.
AT (5170) как раз решил эту проблему, добавив рабочие 4 линии, т.н "gate A20" и спецификации на Extended память (XMS, все что выше мега)
уточню, гейт а20 в 5162 таки есть (там же, в контроллере клавы), но работает не так как в AT, а только на чтение, переключаясь в зависимости от режима CPU (real, protected)
вот и выбрали для физической памяти верхнюю границу в 640К, сразу, на первом писюке (5150), а не когда-то потом.
Дык, не было такой границы у 5150. 736К там верхняя граница. Да, если вы откроете табличку в мануале с установкой свичей на материнке, там в табличке положения свичей максимум до 640К расписаны (и там расписаны не все допустимые и распознаваемые BIOS положения свичей), но при этом вы можете вставить карту памяти до 736К, и она там будет прекрасно работать, если у вас CGA-адаптер.
Conventional memory, от того что вы заюзаете диапазон монохромного буфера, никуда не переместится. И никакие несамописные проги ничего от этого действия не выиграют. Свичи в 5150 расписаны, что логично, до 256КБ
А, используя ваш довод, могу добавить, что трудно воткнуть карточку на 736К в 81 году и через год и даже через два. И трудно переместить что либо из ядра и резидентов DOS 1.0 и следующих версий в ассортименте за пределы конвенциональных 640K
Conventional memory, от того что вы заюзаете диапазон монохромного буфера, никуда не переместится.
На компьютере, у которого нет MDA-адаптера, нет никакого "диапазона монохромногот буфера", а есть один непрерывный диапазон сonventional memory размером 736Кб. А на компьютере, у которого есть MDA-адаптер, есть один непрерывный диапазон сonventional memory размером 704Кб.
А, используя ваш довод, могу добавить, что трудно воткнуть карточку на 736К в 81 году и через год и даже через два.
Естественно. Но речь шла о том, существовало ли какое-то ограничение в виде 640К на момент появления первых IBM PC и даже ХТ. Ответ - нет, не существовало.
Откройте IBM 5150 Technical reference и посмотрите раздел System Memory Map (2-26) и увидите там все эти диапазоны. В частности от 0 до 640K различные варианты оперативной памяти, 640K-656K reserved, 656K-768K видеобуфера
Надо объяснять для чего этот раздел предназначен и как пишется и работает ПО под DOS? В любом случае DOS загрузит прогу целиком в свободный непрерывный кусок памяти внутри диапазона до 640К и не байтом больше или выдаст ошибку вроде Program too big to fit in memory
В частности от 0 до 640K различные варианты оперативной памяти, 640K-656K reserved, 656K-768K видеобуфера
Да, согласен, там область выше 640К была указана как зарезервированная.
В любом случае DOS загрузит прогу целиком в свободный непрерывный кусок памяти внутри диапазона до 640К и не байтом больше или выдаст ошибку вроде Program too big to fit in memory
А вот в этом ну никак не могу вас поддержать, ибо был у меня тридцать лет назад "Поиск-1" с теми же 736К памяти и CGA, и прекрасно пользовался я всеми теми 736К памяти под MS DOS 5.0, потому как при компиляции софта в Турбо Паскалях почти сотня килобайт сверху была очень даже не лишней.
Это ограничение появилось только в компьютере IBM PC AT в 1984-м году, потому что после 640К там начиналась область видеопамяти для EGA-адаптера
А кто мешает в XT хоть EGA, хоть VGA воткнуть? Ограничения в 640К вот не было, а после втыкания тогда появится? (развернуто ответил выше)
Туда помещались текстовые редакторы, файловые менеджеры, базы данных, бухгалтерские программы, игры, софт для FIDO (типа "электронная почта по модему"), BBS ("сайты"), в общем всё что работало на MS DOS.
Прямо вот так все вместе и помещались? И прямо вот так параллельно работали?
По очереди, разумеется.
Речь о том, что тогда - помещалось, а сейчас если программа меньше 100 мегабайт - то это и не программа, а так, скрипт какой-то...
А сейчас эта вкладка браузера 200М отъедает. И что из того?
Плохо. Рукожопие процветает.
на сайтах, у которых странички по 50 килобайт никто не сидит.
А сколько должна вкладка в памяти отъедать с учетом кучи ява-скрипта и отображения кучи графики на мониторах от 1080 до 8К?
Ну вот смотрите, куча ява-скрипта и куча графики на Хабре появилась уже давным-давно. Более того, вы можете открыть эту же страницу не в актуальном браузере, а в браузере, допустим, десятилетней давности, и она там будет отображаться абсолютно корректно, т.к. тот браузер уже поддерживает всё, что здесь используется. Но весить там страничка будет значительно меньше, инфа соточка.
Часть софта и вместе помещалась тоже — попытки сделать какую-никакую многозадачность были в ДОСе, кроме того, очень распространены были TSR-программы, которые «висели» в памяти и активировались на события, тот же русификатор клавиатуры.
himem.sys форева!
Расскажите о таблицах данных того времени, этакий прародитель эксель или сложнее? Могу конечно по гуглить но я помню был эксель с дизайном 80x25 из аски символов как far/norton
SuperCalc - текстовый дедушка Excel'а.
Скрытый текст
FoxBase - предок FoxPro. Вполне приличная система управления файловыми БД. Шустро летала на тех 640 килобайтах, обсчитывала зарплату для тысяч сотрудников.
Скрытый текст
Ну и де-факто стандарт тех десятилетий, сам FoxPro. Вершина своей эволюционной ветки, умел в SQL на своих файловых базах с очень неплохой оптимизацией. Когда через годы Borland решила догнать его на этом фронте, и выкатила свое BDE (Borland Database Engine), то разница в быстродействии и надежности была столь разительна в пользу старого доброго FoxPro, что эта неудача сыграла важнейшую роль в закате Borland.
Скрытый текст
Вы, наверное, будете смеяться, но на тех компьютерах работал не только некий прародитель Excel, но и сам Excel. И ещё и под виндой:
Тут следует упомянуть, что самые первые IBM PC могли поставляться вообще с 16KB памяти, и на 1981-й это ещё стоило примерно 100
, на персональный компьютер - нереально). А на потом думали вообще сменить архитектуру. Проблема в том, что, условно, MS-DOS задержался на десять лет по сравнению с тем, что ожидали (в заметной мере, в своих наполеоновских планах) авторы железа, программ, журналисты и прочие, и, несмотря на то, что адресация далее 1MB была уже в 80286, массовое переписывание кода на новый стиль стало быть позволено уже только в середине 1990-х. Вот об этом бы почитать подробнее, каким образом и почему индустрия впала в такой заклин.
Там было "примерно 100 долларов. Так что 640kB было какой-то несбыточной цифрой на те времена (4100 долларов..."
Кажется, форматтер символы доллара понял как ограничители формулы.
Под MS DOS понаписали много софта, и переписывать его под новый процессор без крайней необходимости - кому это было надо?
Это же не OpenSource, где можно взять исходники и новый компилятор, и попробовать собрать.
Смысл что-то менять появился тогда, когда вышла Windows, с "встроенной графикой", причем достаточно распространилась, чтобы пользователи начали задумываться: оставить привычную надежную DOS-программу XXXXX (работающую в окне Windows, в режиме виртуального x86), или купить новую версию чисто под Windows?
DOS-extenders, если вы под адресацией имеете ввиду именно защищенный режим появились вместе с 286 в 80х, где было удобно или нужно, там и использовали, откуда середина 90х и какой-то заклин, мне, например, непонятно.
Так-то память выше мегабайта можно было и в реальном режиме использовать, за xms память не помню, а ems точно работала через окно в первом мегабайте, так что кому память не нужна была вся разом, этим и удовлетворялись.
Ещё напомню, что 286 компы были не только в виде AT, но и XT
Вот об этом бы почитать подробнее, каким образом и почему индустрия впала в такой заклин.
А это не был "заклин". DOS долгое время имела преимущество в массе сфер. Для бизнесовой - под ней было написано куча кастомного бухгалтерского и учётного софта. Для промышленной - в ней был реалтайм, которого не было в винде. Для игровой - в ней был прямой доступ к видеоустройствам, с максимальной производительностью, недоступной в винде до появления DirectX. А ограничений памяти в DOS, в общем-то, не было, ибо появились всякого рода DPMI-extenders.
Ну понятно что фраза про 640 была просто маркетинговым ходом. Конечно автор, кем бы он не был - понимал что прогресс стоять на месте не будет.
Ещё про оптимизацию скажу. Сейчас её НЕТ. По-крайней мере в играх. Какую ни возьми - весят по 50 гигов каждая. .kkrieger тихо плачет в сторонке...
«640 кбайт хватит для всего»