Эндрю Хуан (Andrew Huang) и Шон Кросс (Sean Cross), в своё время спроектировавшие открытый ноутбук Novena и платформу для создания смартфонов Precursor, представили на конференции 39C3 (Chaos Communication Congress) открытый SoC Baochip-1x, предназначенный для создания защищённых устройств интернета вещей (IoT). Чип спроектирован для использования вместе с микроядерной операционной системой Xous, развиваемым Эндрю и Шоном последние пять лет. Схемы, описания аппаратных блоков на языке Verilog, симулятор и сопутствующая проектная документация доступны под открытой лицензией CERN OHL 2.0. Код операционной системы Xous написан на языке Rust и распространяется под лицензией Apache 2.0...Подробнее: https://www.opennet.me/opennews/art.shtml?num=64521
Все супер, за одним но - в уже почти 2026 году, и нет хотя бы 32 битного флоат?
Это сразу огромное ограничение. Скажете дизайн открыт - ну и что, нарисовать всё что угодно можно, а что бы произвести чип нужны огромные деньги, простым интересующимся такое не под силу.
> и нет хотя бы 32 битного флоат?И зачем он в IOT?
> Это сразу огромное ограничение
Для каких конкретно задач?
> И зачем он в IOT?В твоем понимании IOT - это подергать лампочкой. Но это далеко не все.
> Для каких конкретно задач?
Например для LVGL. Понимаю что твое дергание лампочкой в туалете вывода в красивом выводе на дисплей не нуждается - но это не у всех так.
Например для банального дискретного счетчика, где тебе каждые 15 мс прилетает значение с АЦП которое тебе нужно возвести в квадрат, сложить № раз, а потом по истечению 1 секунды снять с этого квадратный корень и разделить на №. Не знаешь как ватты считаются, что ли?
А что, определение человека или кота на камере видеонаблюдения перестало быть IOT'ом? Ну давай выведи соответствие по маске хотя бы 320х240@15.
Уже не говоря за то что любая вещь может иметь собственный веб-интерфейс для конфигурирования, и такие штуки нужны чтобы он не был дубовым как в Ардуйнях.
Задач полно.
А float при чём тут во всех случаях?> по истечению 1 секунды снять с этого квадратный корень
Сколько сотен мегагерц не хватает для этого железке из новости?
> А float при чём тут во всех случаях?Ты вообще понимаешь что такое float?
> Сколько сотен мегагерц не хватает для этого железке из новости?
Не сотен мегагерц, а тактов.
Если у процессора нет FPU, или его не поддерживает ядро - блоку ALU приходится раскладывать относительно простую арифметическую операцию на составляющие операции которые он выполняет последовательно, приблизительно тому как ты делишь в столбик (если вас в школе этому еще учат).
14.5/2 в случае деления FPU'хой займет примерно два такта командой FDIV. В случае ALU это будет около восьмидесяти тактов.
Именно поэтому четырехядерный Xeon по 2.5 ГГц при проигрывании 4К-видоса греется и пропускает кадры, а какой-нибудь двухядерный ARMик щелкает на 800 МГц и не напрягается.
А float нужен не только для непосредственно вычислений IOT, он нужен практически в любой современной и не очень системе - ФС, выводе картинки на экран, обработке сетевых подключений, сообщений ядра.
Я тебе советую скачать исходник какой-нибудь часто используемой небольшой программы и сделать в его каталоге grep -r 'float' *
Удивишься.
Ага, ясно, с наступающим. А ведь потом протрезвеешь и вспомнишь, что в видеодекодерах нет плавающей запятой. Там даже целые числа консервативно используют, чтоб не жрало процессор и память. Хуже того - там функции заранее вычисляют и в lookup-таблицы кладут...
> нет плавающей запятой. Там даже целые числа консервативно используют, чтоб не жрало процессор и памятьМощно придумал! Вроде завтра не первое апреля...
Эт не я. Где-то со времён H.264 заметили, что если к 8-битной картинке добавить справа два нуля, то эффективность кодирования вырастает.> The bit-depth increase provides greater accuracy for the miscellaneous prediction processes involved in the AVC/H.264 compression scheme, including motion compensation, intra prediction and in-loop filtering
> US9521434: a video coder may use IBDI to increase the bit depth of a sample being coded to reduce rounding errors in internal calculationsЕсли бы целые числа использовали неконсервативно, то и 8-битное видео, и 16-битное видео шли бы одному пути кодирования-декодирования и разницы бы не было.
> 14.5/2 в случае деления FPU'хой займет примерно два такта командой FDIV. В случае ALU это будет около восьмидесяти тактов.14.5/2 через фиксированную точку будет делиться даже быстрее чем через плавающую, ещё раз, зачем тебе float?
> 14.5/2 через фиксированную точку будет делиться даже быстрее чем через плавающую, ещё
> раз, зачем тебе float?Мне? Мне - не нужно. Но есть масса операций, в которых нужно, и графоний - только одна из них.
>> А float при чём тут во всех случаях?
> Ты вообще понимаешь что такое float?А ты, в свою очередь - вообще понимаешь что такое IoT?!?! :)
А то давай потребуем ему PCI Express 16-lanes впердолить! Ну удобно жи - можно печку Nvidia 4090 подключить и 4К VR генерить на лету! В IoT без этого - точно никуда :))))
> А ты, в свою очередь - вообще понимаешь что такое IoT?!?! :)
> А то давай потребуем ему PCI Express 16-lanes впердолить! Ну удобно жи
> - можно печку Nvidia 4090 подключить и 4К VR генерить на
> лету! В IoT без этого - точно никуда :))))Можно. Например если хочешь поставить у себя дома локальный ассистент наподобие какого-нибудь Джарвиса из фантастических фильмов. Безусловно он будет являться частью IOT в целом и умного дома в частности.
И будет говорить с другими системами _без_ вот-этого-всего, так?! :)
А это значит!(С)
Но железо чтобы рисовать красивый 4К Ынтермордий у тебя и так уже есть. А вот малышей после не-чокаясь! ардунки ... практически нет. Вот они и хотят в туда. Ну элементарно же Ватсон!(С) :)
> Если у процессора нет FPU, или его не поддерживает ядро - блоку ALU приходится раскладывать относительно простую арифметическую операцию на составляющие операции которые он выполняет последовательно, приблизительно тому как ты делишь в столбик (если вас в школе этому еще учат).Шо за глупости? Если ты софтфлоат реализуешь, то зачем делить в столбик? Логарифмируй, вычитай, возводи 2 в степень. Или не возводи, продолжай работать с логарифмами. Или дидов в школе не учили логарифмам?
А методам вычислений тоже не учили? Есть масса способов решить уравнение a*x=b, обходясь без деления на неизвестное на этапе компиляции число. Более того, если бы тебе приходилось работать с флоатами, то ты бы научился этим трюкам и трюкам изменения всего алгоритма, чтоб вообще избавиться от необходимости деления, просто потому, что деление флоатов очень гнусная операция, которая может привести к потере точности и запоганить тебе весь результат. Есть например целый жанр публикаций геометрических алгоритмов: "то же самое, но теперь без деления".
> каждые 15 мс прилетает значение с АЦП которое тебе нужно возвести в квадрат, сложить № раз, а потом по истечению 1 секунды снять с этого квадратный корень и разделить на №.
Ну вот тут, например, ты делишь на целое число. Тебе не нужно fp деление. Возьми вместо секунды 960мс, 960/15 будет 64, таким образом вместо деления ты сможешь обойтись побитовый сдвигом.
> Я тебе советую скачать исходник какой-нибудь часто используемой небольшой программы и сделать в его каталоге grep -r 'float' *
Естественно они его используют, это просто и думать не надо.
Согласно слухам, деление флоатов побыстрее целочисленного. Не бенчмаркил ещё, надо попробовать.
Быстрее. На первых пнях это началось. Насколько это распространяется на армы я не знаю, но полагаю, что распространяется. Не думаю, что алгоритм SRT деления патентован.
Почему тогда компиляторы до сих пор генерируют целочисленное?
Не знаю.i32 -- это 31 бит "мантиссы", из него f64 надо сделать, чтобы поделить с той же точностью. А потом результат деления обратно в i32 округлить. Я думаю, это даст результат совпадающий бит-в-бит, но честно говоря не проверял. Целочисленное деление заодно считает и остаток от деления, но компилятор знает ведь, нужен ли остаток программе или просто игнорируется, и если он игнорируется, то почему бы и не?
Но может там накладных расходов на сохранение/восстановление состояния FPU? Или может возня не стоит того? То есть, если у программиста производительность программы упирается в то, как много процессор может выполнять делений в секунду, то может программисту стоит использовать флоаты, а не выносить мозги тем, кто компиляторы пишет? А если не упирается, то зачем тогда связываться?
>Я думаю, это даст результат совпадающий бит-в-бит, но честно говоря не проверялЛемир и многие другие тоже считают, что совпадёт, это известный трюк. И Лемир тоже задаётся вопросом, почему компиляторы это не делают by default.
>Но может там накладных расходов на сохранение/восстановление состояния FPU? Или может возня не стоит того
В компиляторе есть модель процессора по загрузке слотов, поэтому компилятор будет знать лучше в конкретном месте программы при конкретных подстановках и развертываниях.
>А если не упирается, то зачем тогда связываться?
По такой логике можно вообще все оптимизирующие компиляторы ффтопку отправить.
> По такой логике можно вообще все оптимизирующие компиляторы ффтопку отправить.Не факт. Динамическое выделение регистров под значения (вместо того, чтобы явным образом работать с переменными явно лежащими на стеке) даёт прирост производительности для любого кода. То есть, какой бы там цыкл не тормозил в моей программе, он выиграет от такой оптимизации. А вот найти цыкл, который можно ускорить на 5+% заменой целочисленного деления на FPU деления -- это ещё поискать надо. А если при этом добавить ещё условие, что есть действительно смысл в том, чтобы использовать там int'ы, вместо float'ов (в смысле хранить данные как i32, но обрабатывать как f64), что это не какая-то странная прихоть программиста, то я не уверен, что найдётся найти хотя бы один такой.
Если мы допустим, что нет кода, который может выиграть от такой оптимизации, то тогда в чём смысл добавления такой оптимизации в компилятор? Чтобы компилятор сделать помедленнее, потолще и более сложным в сопровождении?
На самом деле, я вдруг сообразил, моя "теория" даёт проверяемое предсказание. Эту оптимизацию легко проделать без помощи компилятора. Надо заменить a/b на round((double)a)/((double)b)). Таким образом, если кто-то когда-то думал что его программе такая оптимизация поможет, он вероятно её проделал. А это значит, что если в дикой природе таких оптимизаций не встречается, значит она бесполезна.
Лемир проделал. И до него ещё дофига сколько.
> Согласно слухам, деление флоатов побыстрее целочисленного. Не бенчмаркил ещё, надо попробовать.Только если тебе надо много делений и других FP операций делать
В изоляции при сравнении целочисленного и fp у тебя всегда будет побеждать целочисленное
> Шо за глупости? Если ты софтфлоат реализуешь, то зачем делить в столбик? Логарифмируй, вычитай, возводи 2 в степень. Или не возводи, продолжай работать с логарифмами. Или дидов в школе не учили логарифмам?Чувак, але, софтфлоат - это не деление в столбик.
> А методам вычислений тоже не учили? Есть масса способов решить уравнение a*x=b, обходясь без деления на неизвестное на этапе компиляции число.
Масса. И все это гоняют ALU.
> Возьми вместо секунды 960мс, 960/15 будет 64, таким образом вместо деления ты сможешь обойтись побитовый сдвигом.
На Интеле что ли сидишь? Это у них обычно 10+10 = 19.99.
> Чувак, але, софтфлоат - это не деление в столбик.Да ладно?? А вот это ты к чему тогда писал про деление в столбик?
> Если у процессора нет FPU, или его не поддерживает ядро - блоку ALU приходится раскладывать относительно простую арифметическую операцию на составляющие операции которые он выполняет последовательно, приблизительно тому как ты делишь в столбик (если вас в школе этому еще учат).
> Масса. И все это гоняют ALU.Да ладно??
> На Интеле что ли сидишь? Это у них обычно 10+10 = 19.99.
Это ты к чему сейчас сказал? Ты хочешь чтобы я всю глубину твоей мысли угадал? Накося, выкуси, я даже не буду пытаться.
> Да ладно?? А вот это ты к чему тогда писал про деление
> в столбик?Я там русским по белому написал, к чему. Что тебе не понятно из слов "выполняет последовательно, приблизительно тому как ты делишь в столбик" ?
> Это ты к чему сейчас сказал? Ты хочешь чтобы я всю глубину
> твоей мысли угадал? Накося, выкуси, я даже не буду пытаться.Герц - это сколько колебаний за 960 мс? :))
> Я там русским по белому написал, к чему. Что тебе не понятно из слов "выполняет последовательно, приблизительно тому как ты делишь в столбик" ?Я выкинул "приблизительно" и что? Это была отсылка к твоим же словам, которые ты видимо забыл сразу, как нажал кнопку "отправить", и теперь докапываешься ко мне, будто это я виноват, что у тебя память девичья.
> Герц - это сколько колебаний за 960 мс? :))
Я не собираюсь отвечать на вопрос, который не имеет отношения к делу.
> Я выкинул "приблизительно" и что?И то, что и ребенку понятно, что слово "приблизительно" не то же самое, что слово "равно". В контексте это звучало вообще как аналогия, а не алгоритм. Странно что вам нужно разжевывать такие элементарные вещи, возможно вы и вправду программист.
> Я не собираюсь отвечать на вопрос, который не имеет отношения к делу.
Почему не имеет? Вы же сами предложили делить не 1000 мс, из которых состоит секунда, а на 960 мс, вот мне и интересно, как это у вас в жизни работает. У нас например в сети частота переменного тока - 50 колебаний в секунду. А сколько колебаний за 960 мс у вас в розетке ?)
> И то, что и ребенку понятноНе надо аппелировать к детям, я не ребёнок.
> В контексте это звучало вообще как аналогия, а не алгоритм.
Мнепох. Отсылка от этого не прекратила быть отсылкой.
> Почему не имеет?
Потому что я не вижу связи.
> Например для банального дискретного счетчика, где тебе каждые 15 мс прилетает значение с АЦП которое тебе нужно возвести в квадрат, сложить № раз, а потом по истечению 1 секунды снять с этого квадратный корень и разделить на №. Не знаешь как ватты считаются, что ли?Ну типа, для этого много где просто swfloat используют, оно не настолько медленное чтобы от его отсутствия страдать в подобных задачах. Да и фиксированную точку зачастую можно использовать, зачем тебе в подобных вычислениях плавающая
Для графики в embedded зачем плавающая точка вообще непонятно, целочисленных величин хватает, там обычно не такого размера экраны чтобы нужно было полноценную растеризацию делать
> в embeddedТут вам не embedded, тут ещё хуже! Тут вам IoT, это хрень такая в запаяных коробоках ...
А UI у неЯ черзЪ уеб-Ынторфейс :)
И сотри его со своего моЩЩЩногА смартыона\планшета и всю красоту рендери на __нЁмммм__ :)
> оно не настолько медленное чтобы от его отсутствия страдать в подобных задачахНа livejournal была (и наверное только была) статья, которая смотрела на мнение "плавучка на 8-битном МК - гроб-гроб-кладбище, без своей библиотеки фиксированной запятой не обойтись" и приходила к выводу, что программная реализация float из gcc конкурентоспособна (только минус одна библиотека и плюс переносимость и плюс повышенная точность).
Ты бы ещё geocities вспомнил бггг
> и приходила к выводу, что программная реализация float из
> gcc конкурентоспособна (только минус одна библиотека и плюс переносимость и плюс
> повышенная точность).Я и не говорил что надо для swfloat что-то отдельное ставить, я про в целом способ реализации
Почти везде реализация из libm взята, в т.ч в Rust: https://github.com/rust-lang/compiler-builtins/blob/main/lib...
> Ну типа, для этого много где просто swfloat используют, оно не настолько
> медленное чтобы от его отсутствия страдать в подобных задачах. Да и
> фиксированную точку зачастую можно использовать, зачем тебе в подобных вычислениях плавающаяОно не просто медленное, оно мегамедленное
> Для графики в embedded зачем плавающая точка вообще непонятно, целочисленных величин хватает,
> там обычно не такого размера экраны чтобы нужно было полноценную растеризацию
> делатьТы в курсе как рисуется примитивный КРУГ?
> Ты в курсе как рисуется примитивный КРУГ?Я то - да :)
А ты вот явно не в курсе, что его рисовать можно вообще без FP! :-D
Ну чего людей смешишь то?! В школе жи рисовал, ну вспомни сразу 8 точек за итерацию ...
ФамилиЁ Брезенхейм ничего не говорит?! :-\А кстати - и сколько тысяч окружностей в секунду тебе для IoT нужно? Если тебе вдрук упёрся именно GUI на той IoT'ке ...
> Ты в курсе как рисуется примитивный КРУГ?Дополню другого комментатора - для растеризации круга примерно всегда используют алгоритм Брезенхэма. Как тебе в подобной задачи должен помочь FPU? Ты собираешься на каждый пиксель круга дёргать sin/cos/sqrt? Это жесть как дорого даже с FPU, так это не делает никто
https://en.wikipedia.org/wiki/Midpoint_circle_algorithm
Приведи пример того, как по твоему должен рисоваться примитивный круг)
> https://en.wikipedia.org/wiki/Midpoint_circle_algorithm
> Приведи пример того, как по твоему должен рисоваться примитивный круг)Ты зело дофига хочешь от человека с ником windows10, прозрачно намекающим на всю мощь мощей.
Сиди дальше на ардуино с float. Остальные понимают, что в большинстве случаев вместо float НАДО использовать fixed point
> Сиди дальше на ардуино с float. Остальные понимают, что в большинстве случаев
> вместо float НАДО использовать fixed pointБольшинства случаев не существует. Есть внешние данные, которые нужно обработать.
Ну тады у тебя два путя(С) :)1) Возьми железку с FP, то что в $Subj - не для тебя...
2) Если ты советский инженер(С) ... короче - считай женился :))))
> Большинства случаев не существует. Есть внешние данные, которые нужно обработать.Можно пример таких данных что ты собираешься обрабатывать на iot железке? Опять же - большинство процессоров справляются с графикой без FPU, много stm32, много armv7, много esp32 S2 сущестует в подобной технике, и не имеют FPU, и всё хорошо
> что бы произвести чип нужны огромные деньги, простым интересующимся такое не под силу.Что такое "простые интересующиеся"?
Если взять mosis, то там стоимость входи от 50к баксов.
Т.е даже для небольшой фирмы это вполне посильные деньги.Энтузиасты могут скинуться.
Или каким-то уважаемым людям или на любой краудфандинговой компании.
Т.к речь про IOT, то чипов нужно будет пучок каждому желающему.
"произвести" и "заказать" это разные слова
Полно вариантов программной реализации арифметики с плавающей точкой без FPU в процессоре, чего ныть-то? Для IoT с головой хватит.
> Полно вариантов программной реализации арифметики с плавающей точкой без FPU в процессоре,
> чего ныть-то? Для IoT с головой хватит.Бггг. Сам-то пробовал? :))
Вот и выросло поколение... Плавающую арифметику более-менее сносно считал еще Spectrum, на несчастных 3.5 МГц тактовой и даже без целочисленного умножения/деления в системе команд процессора. И кстати, Z80 снят с производства меньше двух лет назад. Но нет, мы ж без FPU никак...
Не только Spectrum, штатно 8086, 80286, 80386 и i486SX обходились без FPU (его надо было докупать отдельно). В компиляторах была поддержка программной эмуляции и даже не особо напрягаясь люди как-то считали во float-ах. А если надо было прямо очень быстро, то да, пытались уйти на целочисленные вычисления/фиксированную запятую/прочие трюки.
> Вот и выросло поколение... Плавающую арифметику более-менее сносно считал еще Spectrum,
> на несчастных 3.5 МГц тактовой и даже без целочисленного умножения/деления в
> системе команд процессора. И кстати, Z80 снят с производства меньше двух
> лет назад. Но нет, мы ж без FPU никак...Верно. Мы без FPU никак. Просто потому что для забивания гвоздей существуют молотки, а микроскопы они децл для другого.
> Верно. Мы без FPU никак. Просто потому что для забивания гвоздей существуют
> молотки, а микроскопы они децл для другого.Да, вот ща мы каждому датчику протечки гумна поставим по сопроцессору плавучки. Чтоб утопая в гумне он успевал перерабатывать его, видимо :)
Хотя если вы конечно за 20 центов запилите, как wch, но еще и с плавучкой - почему бы и нет. Ежели опциональное. А ежели не опциональное - так для МКшных задач у плавучки контекст огроменный. И его сохранение и восстановление здорово нагибает латенси, времена прерываний и проч. Небольшие такие нюансы.
Сабж в этом смысле ни два ни полтора. Для МК слишком здоровый, сложный и малопредсказуемый уже. Для апликушника слишком малохольный. А, ну да, поставьте нашу неведому супер-ртос... и делайте с ней ... неведомо что. Будет столько же продаж сколько и у чудо-ноутов этого гражданина, вероятно.
> Да, вот ща мы каждому датчику протечки гумна поставим по сопроцессору плавучки. Чтоб утопая в гумне он успевал перерабатывать его, видимо :)Датчикам это может и не нужно. Вот только встраиваемые системы - это не только датчики.
Вот на данный момент я например 3д-печатаю. Стандартную прошивку (Marlin) и родную плату МК выбросил, поставил RPI и клиппер. Казалось бы - четыре шаговика, что сложного в их управлении?
А нет, клиппер намного быстрее и качественнее печатает. Почему так? Потому что железо, поддерживающее FPU позволяет более точно вычислять микрошаги и траекторию движения, составляет более подробную карту поверхности (это когда у вас площадь неровная). И да, разница между 0.2 мм, 0.24 мм и 0.04 - весьма велика. Если вы будете печатать кубик высотой 5 см с погрешностью 0.04 мм -к половине кубика у вас начнется лапша, потому что сопло станет печатать не на предыдущем слое, а в воздухе.
- - -
Вы наверное не понимаете разницу между "без FPU нельзя" и "без FPU хуже". Вчитайтесь внимательнее.
> А нет, клиппер намного быстрее и качественнее печатаетОру, ты взял лучший пример для этого)))
У klipper та прошивка что в MCU загружается как раз таки оперирует исключительно fixed point :D
Вся floating математика там на хостеОно может использовать FP для ускорения каких-то операций, однако его поддержка сугубо опциональная
> И да, разница между 0.2 мм, 0.24 мм и 0.04 - весьма великаС fixed point ты сам задаёшь сколько бит точности тебе надо
Если ты говоришь что тебе обязательно нужен float - то уж скажи зачем тебе нужна не просто точность, а плавающая точность (Для значений от 1.4e-45 т.е)?
В большинстве случаев такое очень даже нежелательно, потому что с float у тебя погрешность накапливаетсяНу и btw, marlin это наверное единственная прошивка которой fpu надо, gbrl/teacup/klipper/прочие прошивки для принтеров и CNC - все оперируют fixed point
> Вы наверное не понимаете разницу между "без FPU нельзя" и "без FPU хуже". Вчитайтесь внимательнее.Есть ещё рариант про "с FPU хуже" - только ты упорно его видеть\слышать\пониать не желаешь :( Про датчики субстанций выше точно же прочитал, но понять не захотел :(
А почему в тех датчиках FP - это плохо? А потому что бесплатно бывает только в мышеловке!
А в жизни за это придётся заплатить:
- деньгами ( и не пи-пи моск - за так никто тебе его не всунет!)
- потреблением, и если твой дивайс на батарейке - это кончен бал, погасли свечи(С)
Про нагрев не буду но тоже может за-ролять.
А по-большому - каждый смотрит в свой IoT и думает что так - везде :)
А случаи ... онЕ разные бывают!(С) Один хитрый старичок :)Придумали продаваны термин про всё сразу и ни-о-чём конкретно, а мы ругаемси на Новый Год то! :)))
С Наступающим! И немедленно выпил! (С)
> Датчикам это может и не нужно. Вот только встраиваемые системы - это
> не только датчики.А концентратор и прочие UI я пардон муа на линухе сделаю. Минимальный одноплатник способный бутануть линух стоит менее 10 баксов и может отрисовать либо морду на кутях, либо вебморду дешево и сердито. Нормальную. Полноценную. Без особых скидок на убогость чипа и отсутствие нормальных ФС, куцую сеть и проч.
Почему так? Потому что сие я могу отладить прямо на моем десктопе с тем же линухом, что радикально все упрощает. А потом просто загнать это и на таргет. Дешево и сердито!
А вот как девлоп под эзотеричного уродца с левой ртос выглядит, и почему это лучше того - вот вы например и покажете. Если я и прочие вас случайно законкурируют к фигам, извините, ничего личного, это бизнес.
> Вот на данный момент я например 3д-печатаю. Стандартную прошивку (Marlin) и родную
> плату МК выбросил, поставил RPI и клиппер. Казалось бы - четыре
> шаговика, что сложного в их управлении?Вообще, это 3+1 измерения с не совсем тривиальной логикой (e.g. правила костылирования особенностей технологии).
> железо, поддерживающее FPU позволяет более точно вычислять микрошаги
Микрошаги сами по себе обычно ограничены - возможностями железа. FPU там ессно никак не фигурирует: при физической реализации микрошагов фигурируют только целые числа. Не оперируют железки типа PWM, GPIO и прочие таймеры плавучкой. By design. Это раздуло бы железку в разы. Так что вы не в теме.
> И да, разница между 0.2 мм, 0.24 мм и 0.04 - весьма велика.
И к плавучке это все относится - как?
> погрешностью 0.04 мм -к половине кубика у вас начнется лапша, потому
> что сопло станет печатать не на предыдущем слое, а в воздухе.Что-то вы сказки тут рассказываете. Какой толщины у вас filament? 0.04 мм это 40 микрон, вы даже отпозиционировать привод с такой точностью не сможете воспроизводимо. А если сможете может вам уже пора - микросхемы печатать? :)
> Вы наверное не понимаете разницу между "без FPU нельзя" и "без FPU
> хуже". Вчитайтесь внимательнее.Вон там господа Fixed point дофига юзают - и им норм. Хотя жирные МК с FPU - так то сто лет есть. Вот только взамен на FPU там размер контекста ломовой, его времена сохранения во, джиттер во, и оно - меньше микроконтроллера и больше недо-апликушника. В результате самые массовые ессно совсем не эти чудеса а куда более мелкие, верткие и пердсказуемые штуки. А как сэр собирается отбить сетап 22 нм процесса не будучи линчеваным инвесторами с вон тем - это мы будем посмотреть. С безопасной дистанции.
FP на Z80? У меня аж волосы на заднице зашевелились при упоминании.
Там это стоило таких костылей, что оно годилось разве что в калькулятор.
Все более-менее сносные вещи делали в очень хитрых fixed point, причём очень часто - табличной предконверсией, причём с извратами, те же синусы например часто упаковывали на условные 256 градусов :D вместо привычных 360. Потому что там даже 16-битные операции - это уже нетривиальная долбанина.
Зачем людям мозг выносишь - возьми старый пень или целерон и паяльник, распаяй ему питание прямо на плате. Поставь туда QNX RTP 6.0 , который с Photon. И будешь счастлив !
> Зачем людям мозг выносишь - возьми старый пень или целеронЖрёт. Греется. Забивается пылью. Гудит.
Да ну нах такое счастье. А если брать Ындустриальный фанлесс... цена - уже не торт :(> Поставь туда QNX RTP 6.0 , который с Photon.
Зойчем?!?!? Ея как RIM/Blackberry схавал - оно не торт.
Да и ЗОЙЧЕММ тебе Hard-RT??? Там базового линя - обмотаться!
> Зачем людям мозг выносишь - возьми старый пень или целерон и паяльник,
> распаяй ему питание прямо на плате. Поставь туда QNX RTP 6.0
> , который с Photon. И будешь счастлив !Чтобы это нечто смогло - столько же сколко одноплатник с полкреды питаемый от "зарядки для мобли". А потом у него опухнут кондеры и вентиляторы пылью забьются, от чего никакой QNX не поможет, ессно.
И батарейки в рюкзаке.
> Xous is a microkernel operating system written in pure Rust...с unsafe в 101 файле*
* если верить github поиску
> ...с unsafe в 101 файле*Не 101, а 2433 (включая комменты) на всего лишь 585523 строк растового кода.
если учесть что большая часть это однострочные вызовы, типа
let mut i2c = unsafe {
bao1x_hal::udma::I2cDriver::new_with_ifram(
i2c_channel,
400_000,
100_000_000,
i2c_ifram,
&udma_global,
)
};То колличество safe кода можешь прикинуть сама.
В любом случае это больше чем в дыpяшke где весь код будет unsafe.
>> ...с unsafe в 101 файле*
> если учесть что большая часть это однострочные вызовы, типаУязвимостям все равно. А вот гарантии раста ломаются на весь остальной код.
> две крайности - полнофункциональные чипы с блоком управления памятью (MMU)
> разумного компромисса
> легковесность, свойственную микроконтроллерам ARM без MMU
> Наличие MMU в Baochip-1x позволяет
> *и 5 ядер почти по гигагерцу*Чево?
>> две крайности - полнофункциональные чипы с блоком управления памятью (MMU)
>> разумного компромисса
>> легковесность, свойственную микроконтроллерам ARM без MMU
>> Наличие MMU в Baochip-1x позволяет
>> *и 5 ядер почти по гигагерцу*
> Чево?Да там какой-то сплошной заказ с алиэкспресса в новости. На картинке - одно. В тексте - другое. Не хватает еще надписи типа "зеленый доска мягкий разработчик".
Зачем нужен Xous, если есть Muen и Ironclad на Аda/SPARK? Ну и L4 ещё, конечно же.
Вот например Arduino подходит под проект, делает нужную работу, показывает дисплей нужного X*Y точек и размера, а в нём часов нет совсем. Поэтому на основе календаря ничего сделать нельзя. Пример - автономная метеостанция с использованием Астрономических данных из таблицы.
> Вот например Arduinoпро ардуино с октября 2025 года можно забыть навсегда
https://sinardcom.ru/blogs/blogs/novye-usloviya-arduino-vyzv...
Что изменилось ?
Qualcomm практически незаметно опубликовала обновленные документы, в которых появились новые требования к пользователям. Среди них — несколько пунктов, которые вызвали наибольшее недовольство:
Бессрочная и безотзывная лицензия на любой загруженный пользователями контент.
Это означает, что любые проекты, схемы, код или изображения могут использоваться корпорацией без ограничений.
Расширенный сбор данных и мониторинг, в том числе для функций, связанных с искусственным интеллектом.
Передача данных в единую глобальную инфраструктуру Qualcomm, включая информацию о несовершеннолетних пользователях.
Запрет на обратное проектирование (reverse engineering) Arduino без официального разрешения. Этот пункт особенно болезнен для хардверного сообщества, где анализ и модификация устройств всегда считались нормой.
Долгосрочное хранение данных о пользователях, даже если аккаунт был удалён.Для обычных людей, всё как было, так и осталось. Компания хочет заурядную статистику и делает то же, что GPL/GNU. Те же принципы, только изложенные буквально на русском языке. Так в чём проблема ?
У "обычного людя" может возникнуть потребность сунуть нос под капот, если только это не совсем конченная креветка с мозгами "нажми на кнопку - получишь результат".
> У "обычного людя" может возникнуть потребность сунуть нос под капот, если только
> это не совсем конченная креветка с мозгами "нажми на кнопку -
> получишь результат".Да реально ничего не изменится. Я там ниже чуть обизложил, реально вот ардуина - это для кулибинов и экспериментов, как применялась, так и будет. Реального прода на ней по сути не было (ну разве что в совсем уж кошмарных извратах). Поэтому как игрались - так и будут играться, а реал юз всё равно да, пойдёт в сторону STM32 и более специализированных MC, как и раньше. И в не малой мере - после ардуины.
> про ардуино с октября 2025 года можно забыть навсегдаС чего бы это?
Arduino - это не просто конкретная архитектура микроконтроллера, это скорее архитектура системы, внесшая порядок, примерно как IBM-PC в этих ваших х86. Благодаря этому, МК получили понятный уровень абстракции, понятное наименование и нумерацию портов, вменяемый IDE с С++ подобным синтаксисом, и огромное комьюнити.
Для STM32 на гите 82 тысячи проектов. Для Arduino - 373 тысячи. Это не хорошо, и не плохо, это просто увеличивает порог входа и дает +1 шанс к тому, что твою проблему уже кто-то решил.
И Qualcomm от этой традиции никуда не уходит.
Плюс ко всему, как было написано выше, Arduino - это культура, а не просто торговая марка, так что тебе никто не запрещает брать китайский LGBTQ и шлепать на него скетчи как на Ардуину. Или взять голый чип 328PU, прошить его как Ардуину и шлепать на него скетчи. В DIP корпусе оно даже внешний кварц не требует, лол.
> на основе календаря ничего сделать нельзя. Пример - автономная метеостанция с
> использованием Астрономических данных из таблицы.Кому очень надо - цепляют DS2312 к нему по i2c, тоже мне рокетсайнс. Хотя лучше прокачать скилл и STM32 чтоли взять какой. Намного более осмысленная инженерия. Ну или хотя-бы клон с него от луноликих, но с клонами можно и горя хлебнуть.
> Кому очень надо - цепляют DS2312 к нему по i2c, тоже мне
> рокетсайнс.И лечат пнос затыканием жпы.
> Хотя лучше прокачать скилл и STM32 чтоли взять какой.
Какую проблему решает использование STM32?
> Намного более осмысленная инженерия. Ну или хотя-бы клон с него от луноликих,
> но с клонами можно и горя хлебнуть.В чем осмысленность, и зачем осмысленность?
Ну вот к примеру мне нужно считать показания с датчика A и вывести на экран B. Для чего мне дрчиться в какую-то осмысленную инженерию, если в конечном итоге это приведет к тому же самому результату?
> И лечат пнос затыканием жпы.С другой стороны - задача то решена. Да, уж как умели. Но это лучше чем "никак" или камлания на богов которые за вас все сделают, типичного для вас. Потому что у них 100500 strings attached. А абдурин с ds2312 или что там - ну, работает. И подстав никаких особо.
А то что кривовато - отлично тем кто STM32 и проч освоил меньше конкуренции.
>> Хотя лучше прокачать скилл и STM32 чтоли взять какой.
> Какую проблему решает использование STM32?У него RTC есть. Получается 1-чиповое решение. И в целом намного более крутые по периферии чипы намного дешевле. Абдурино по сравнению с - обдираловка в плане соотношения фичи-стоимость. Это стало золотым стандартом отрасли, типа x51 2.0 этакого. Правда больше по периферии чем по cpu core. Ибо китайцы наделали клонов с compat (условно) периферией, но cpu core порой заменен на RISCV вместо ARM Cortex M. Просто заменили блок на блок, вывесив из RISCV ядра те же интерфейсы шин. Дешево и сердито. И роялтя платить не надо! Так что вот вам 32 бит нечто с DMA за 15-20 центов. И тут PIC10...12 всякие начали что-то напрягаться. За те же центы - намного круче чипы.
> В чем осмысленность, и зачем осмысленность?
В правильной, крутой и продвинутой периферии. МК ради нее берут на самом деле. И по этому аспекту даже самый первый STM32F1xx даст жесточайший мастеркласс абдурине.
Просто для понимания 1MSPS @ 12 bit ADC (а порой их 2-3 в чипе). В самом древнем из семейства. В поновее и до 4.5 MSPS и более. В мелочи с тетрадную клеточку. Теперь разоприте на ЭТО абдурину кроме как внешним чипаком... встроенный ADC... как бы сказать то! :). Ну и DMA чтобы такие потоки еще и реально ворочать. Ибо что с вами будет от нескольких миллионов IRQ/sec - угадайте сами! Абдурин на только ворочании такого потока сольется. Плюс хардварные автоматы. Можно пустить ADC+DMA по кольцу и оно вообще само живет, асинхронно от остального чипа. Можно "live buffer" сделать где индексы == состояние сигнала на лапках, околореалтаймно. Можно и точки синхронизации пулять когда всю серию отпедалило. Абдурин в принципе не способен на такую логику с такими скоростями и оффлоадом.
> Ну вот к примеру мне нужно считать показания с датчика A и
> вывести на экран B.Это ничего не говорит о характере сигнала, как часто это надо, объеме данных и проч. Захоти более-менее точно и быстро мерять какой-то процесс, скажем тот же 1MSPS - и удачи абдурин на ЭТО распереть вообще. Это сразу становится - куском проблем. Винтажный 8 бит дизайн с тормозным ядром не заточен на такие потоки, а если хоть какую-то обработку сигнала делать.. ых, ых, ых, 8-битный уродец даже на своем дубовом 10-бит ADC замечает что оказывается 10 битов в 8 совсем никак не - и это попадос на математику этажеркой. В и без того тормозном ядре. Упппс!
> Для чего мне дрчиться в какую-то осмысленную инженерию, если в конечном
> итоге это приведет к тому же самому результату?Вот только я без особого напряга отсэмплирую пин чуть не миллион раз в секунду если мне оно надо. Мало ли какой процесс я мониторил. А на абдурине ... ых, ых, ых.
Т.е. лопата и небольшой экскаватор в принципе оба позволяют копнуть куб грунта. Но есть нюансы. Поэтому ваше умение использовать лопату не делает вас серьезным конкурентом водителю экскаватора. Даже если это ведет к тому же результату.
Тут момент.В том, что STM32 продуман под реал юз и удобнее ардуины для реальных применений - это вот просто настолько очевидный факт, что тут даже спорить бессмысленно. Если мне нужен вот такой вот да умный MC - я возьму STM32 без колебаний.
Но ардуина - это не просто MC. Это да, целая экосистема, ценность которой несколько выше ценности собственного самого MC. Но тут второе но: это экосистема больше для индивидуэл юз и лабных экспериментаторов. Поэтому даже при откровенно х** реализации собственно железа, у неё больше востребованность именно в секторе кулибиных, в т.ч. тех, которым чистый STM32 освоить сложно, и от этого никуда не деться. Потом часть этих кулибинов, которые выросли из ютубинга своих поделок, и которым уже реал юз нужен - придут и к STM32 и к прочим :)
Короче тёплое с мягким сравнивать "в лоб" бессмысленно.
ладно заловендорлочить ядро на llvm (нет, не ладно), но завендорлочить целый ЦПУ на llvm - это что-то с чем-то
Есть ресурсы на поддержку 1001 компилятора?
ты, видимо, пытался спросить "есть ресурсы на лоббирование на уровне правительства и рекламу из каждого утюга?", подразумевая, что ресурсов у майкрософт достаточно? так вот, у тебя плохо получилось
>Есть ресурсы на поддержку 1001 компилятора?Десяток хоть назовешь?
Для начала назову один, если обеспечишь его поддержку - буду по одному называть следующие. Готов?
> Для начала назову один, если обеспечишь его поддержку - буду по одному
> называть следующие. Готов?Gccrs. Но он пока несколько недопиленный. Что как бы повод с сабжем дела не иметь. Зависеть от узкой клики майкрософта, гугл и эпла при том что им на вон то в целом пофигу - сами понимаете.
Они уже в последних версиях LLVM и clang своими индусами какую-то дичь сотворили, Торвальдс недавно в рассылке ругался как раз. Но не только он - это стало лезть довольно много где. Код жирный, тормозной а если не повезло то е ще и глючит.
Докажите вендорлок на llvm.
очень просто доказать математическипринимаем llvm за 2 в десятичной системе счисления
принимаем вендорлок за 3 в десятичной системе счисленияпринимаем 5 в десятичной системе счисления за доказательство
итого 2+3=5, следовательно llvm имеет вендорлок
обратно тоже доказывается: 5-2=3; 5-3=2.
надеюсь это помогло вам убедиться в наличии вендорлока
> 5-3=2Доказательство - вендорлок = ллвм
Вот тебе и доказательство что в ллвм нет вендорлока
кто тебе сказал, что в доказательстве только один вендорлок?
Да ладно, пусть играются. Для их собственных применений этого скорее всего вполне достаточно, что собственно и решает. Снаружи всё равно не взлетит, как и вся рисква. Архитектура по балансу сложности-производительности от ARM отстаёт на световые годы, а фрагментация IP уже на уровне.
> не взлетит, как и вся рискваА инженеры WD и не в курсе, что "рисква" не взлетела...
Инженеры, я думаю, копротивлялись, но там роялти такие, что решили попробовать сопельки в шоколаде. Возможно ещё выстрелит, в очередной раз, лично я после серий разнотипных факапов с HDD и SSD к WD уже лет 10 не прикасаюсь.
Хотя будем честными - SWerV'у уже пять лет, а SSD всё ещё на физоне, хорошо если не на сандиске. Такой вот успех - а планировалось-то именно под SSD в начале. От 2023-2025 вообще новостей про внедрёж около 0, разве что кому-то IP впарили из партнёров.
> Хотя будем честными - SWerV'у уже пять лет, а SSD всё ещё
> на физоне, хорошо если не на сандиске.Будем честными - RISCV уже несколько миллиардов выпущено. Вот прям ща мне более 100 юнитов где-то едет. Он уже никуда не денется.
> Такой вот успех - а планировалось-то именно под SSD в начале.
> От 2023-2025 вообще новостей про внедрёж около 0,
> разве что кому-то IP впарили из партнёров.Не згаю у кого там внедрежа около ноля а вон те 32 бит МКшки за 20 центов произвели в отрасли небольшой фурор и теперь 8-bit фигне типа AVR совсем душняк будет. И конечно их миллионами будут делать.
Не нравятся штуки с тетрадную клеточку и пылинку? Есть и жирные серверные чипы с кучей ядер. А нвидия и амд заменили часть сервисных aux ядер в своих видяхах - на RISCV. Даже ESP32 арджуинский - и тот эт самое. RISCV ядер уже на планете - миллиарды.
Зачем тебе 100 юнитов? Надеешься из них один core2duo собрать?
> ладно заловендорлочить ядро на llvm (нет, не ладно), но завендорлочить целый ЦПУ
> на llvm - это что-то с чем-тоНе, ну это ж разовая акция. Послезавтра эта однодневка уйдёт с рынка и всё, будет какое-то ещё поделие вместо неё. Там плакать-то будет же не тот, кто завендорлочил, а тот, кто это рискнул использовать или на это завязаться.
>>Серверы ожидают поступления сообщений и запускают связанный c полученным сообщением код на языке Rust.что тут за бред написан ?
Попытались описать механизм Send/Receive/Reply из QNX.Там суть в том, что сервер в основном цикле вызывает Receive() и блокируется микроядром на ожидании запроса. В определённый момент клиент выполняет Send() с указанием сервера и блокируется микроядром на ожидании ответа, а сервер разблокируется и ему передаются данные, которые клиент указал в Send(). На основании этих данных сервер выполняет какие-то действия и при помощи Reply() разблокирует клиента, который получает данные, которые сервер передал в Reply(). Функции Send(), Receive() и Reply() являются примитивами (системными вызовами) микроядра, и позволяют унифицировано передавать данные как между двумя независимыми процессами, так и между процессом и микроядром.
"Every Xous Server contains a central loop that receives a Message, matches the Message Opcode, and runs the corresponding rust code"
https://betrusted.io/xous-book/#architecture
и тут бред написан
А ну-ка, поделись, что было бы не-бредом, в твоём понимании?
Поясните, почему аппаратная многозадачность в x86 оказалась тормознее программной, из-за чего её избегали использовать, из-за чего в конце-концов выпилили. И что мешает сделать чип с аппаратной поддержкой I/O, где ядру ОС выделено специальное физическое ядро, желательно оптимизированное под исполнение ядра ОС, но можно и любое из доступных, где вместо прерываний - io_uring, а ядро слушает это io_uring, но ... аппаратно реализованное, и все прерывания чтобы доставлялись именно в сконфигурированные через регистры очереди. Другие процессы могут как очередь отмаппить (очередь для процесса маппит и конфигурирует ядро, очередь - это область памяти плюс несколько архитектурных регистров, для юзерспейсной программы они на запись недоступны, но программа может их инкрементировать, при инкременте процессор сам доставляет сообщение в ядерное ядро, и должна быть доступна инструкция "ждать результата"), так и syscall дёрнуть (сисколлы реализуются также через сообщения, только в память юзерспейсного процесса явно не мапятся, а прямо в кеше процессора).
Потому что это переусложняет и так недешёвое железо + надо совместимость поддерживать между ревизиями, а ревизий при такой сложности будет очень много. Вполне себе реализованы подпорки для софта, которые позволяют всё вышеперечисленное делать с минимальными накладными расходами. Хоть ядро отделяй, хоть десять - всё на совести условного гипервизора.
Гляньте в Xen хотя бы - оно не далеко от вашей идеи, за исключением отсутствия чётко выделенных ядер - хотя это вполне себе делается просто на уровне конфигурации.
> Поясните, почему аппаратная многозадачность в x86 оказалась тормознее программной, из-за
> чего её избегали использовать, из-за чего в конце-концов выпилили.Не совсем так, и там - и там вполне себе аппаратная многозадачность, а вот переключение контекстов процессов в первом случае аппаратное (call TSS), а во втором - программное (push/push/push; mov esp,xxx; pop/pop/pop). Во втором случае можно было сохранять сильно не всё (можно было не сохранять FPU, если его не использовала текущая задача), и вообще было более удобно для программиста, где он сам мог выстраивать удобные ему структуры, а не мучаться с TSS.
> мешает сделать чип с аппаратной поддержкой I/O, где ядру ОС выделено
> специальное физическое ядро, желательно оптимизированное под исполнение ядра ОСесли правильно понимаю - примерно так в iMX.6 сделали реализацию DMA на SOC (спец. RISC-процессор, но не архитектуры ARM, со спец.прошивкой, который и реализует контроллер DMA). Честно говоря, получилось не очень. Такое замечательное DMA пришлось для некоторых контроллеров (SPI), отключать, т.к. оно нормально не работало. Хотя, конечно, идея была красивая.
Вообще как-то так выходит, что сложные процессорные инструкции оказываются тормознее, чем последовательность простых. Когда-то в x86 были инструкции enter/leave для организации стековых фреймов, и где они теперь? У меня есть предположение, что последовательность простых инструкций проще раскидать про конвеерам, чем одну сложную инструкцию выполняющую то же самое. Но это лишь предположение.
> У меня есть предположение, что
> последовательность простых инструкций проще раскидать про конвеерам, чем одну сложную
> инструкцию выполняющую то же самое. Но это лишь предположение.Не то что бы в условном arm инструкции были сильно простые, там уже давно добавили много более сложных.
Однако в x86 проблема несколько другая - там сложных инструкций оочень много, и при этом сомнительной полезности в современном мире, оптимизировать их дорого и не нужно.Если бы сейчас кто-то решил изобрести новый cisc, то он смог бы вместить туда намного более полезные инструкции
enter/leave имели смысл для ручного написания asm кода, сейчас же только leave можно встретить в выхлопе компилятора, enter делает слишком много вещей которые условному gcc не нужны, потому что он при компиляции сам способен всё посчитать, не перекладывая это на рантайм
https://www.felixcloutier.com/x86/enter
> Не то что бы в условном arm инструкции были сильно простые, там уже давно добавили много более сложных.Например? SIMD инструкции перекладывающие числа оттуда/сюда или выполняющие четыре сложения параллельно? Их можно разложить на более простые инструкции, которые в сумме будут делать то же самое, но их сложнее параллелить. Что ещё? Что-нибудь связанное с примитивами синхронизации, для которых важна атомарность выполнения нескольких операций? Но это ситуация, где атомарность важнее скорости.
Но я не знаю армовскую ISA, может там есть что-то ещё? Поэтому спрашиваю примера.
> Если бы сейчас кто-то решил изобрести новый cisc, то он смог бы вместить туда намного более полезные инструкции
Например?
> enter/leave имели смысл для ручного написания asm кода, сейчас же только leave можно встретить в выхлопе компилятора, enter делает слишком много вещей которые условному gcc не нужны, потому что он при компиляции сам способен всё посчитать, не перекладывая это на рантайм
Ну да, вообще отказываются от стекового фрейма в том понимании, которое в него вкладывалось в 80-е. Храним промежуточные результаты вычислений в регистрах, динамически выделяя под них регистры, да так, что глядя в машинный код найти там переменную, которую я вижу в сорцах, будет крайне сложно.
Но мне всегда казалось, что enter и leave были придуманы чтобы экономить байты машинного кода. Если бы речь шла про удобство ручного написания кода, их можно было бы заменить макросами. Но экономя байты, они жрали лишние такты процессора.
> Например? SIMD инструкции перекладывающие числа оттуда/сюда или выполняющиеНапример всякие CISC команды бывшие в x86 без всяких SIMD еще. Там есть реально сложные типа копирования или поиска в цикле - разваливаемые на целую последовательность силами uCode. В ARM просто нет uCode. Все достаточно просто для прямого выполнения.
> параллельно? Их можно разложить на более простые инструкции, которые в сумме
> будут делать то же самое, но их сложнее параллелить. Что ещё?У x86 внутри реально совсем другие блоки выполнения а x86 ISA лишь фронтэнд.
> Но я не знаю армовскую ISA, может там есть что-то ещё? Поэтому
> спрашиваю примера.В ARMовской или RISCV системе команд инструкции более простые. Если вы знаете x86 ISA то должны знать что там есть довольно сложные команды с по сути вложенными циклами и проч.
В ARM такого ессно нет. И в RISCV тоже. Так что на минималках их exec core намного проще. А отожрать можно любой бэкэнд. Вот только ARM и RISCV в итоге есть в 20-центовых МК. Попробуйте так с x86. А тулчейн может быть тот же :)
> Ну да, вообще отказываются от стекового фрейма в том понимании, которое в
> него вкладывалось в 80-е. Храним промежуточные результаты вычислений в регистрах,У x86-32 для этого хтонически не хватало регистров. И там довольно гнусные хаки на эту тему. По поводу чего программа состоит из push и pop чуть менее чем полностью.
> найти там переменную, которую я вижу в сорцах, будет крайне сложно.
Для этого есть debug info.
> кода, их можно было бы заменить макросами. Но экономя байты, они
> жрали лишние такты процессора.Это x86 в целом не сильно помогло. А кто хочет всякую плавучку может поинтересоваться размером контекста и сколько тактов проца его сохранение может сожрать.
Чо, с перепою вообще котелок не варит, даже прочитать не получается то, на что отвечаешь?> Например всякие CISC команды бывшие в x86 без всяких SIMD еще. Там есть реально сложные типа копирования или поиска в цикле - разваливаемые на целую последовательность силами uCode. В ARM просто нет uCode. Все достаточно просто для прямого выполнения.
Вопрос стоял, какие сложные инструкции есть в ARM, ты зачем-то мне про x86 втираешь.
> У x86 внутри реально совсем другие блоки выполнения а x86 ISA лишь фронтэнд.\
Напомню, речь идёт про arm.
> В ARM такого ессно нет.
Выше было заявлено, что есть.
> Для этого есть debug info.
Да неужели? Существование debug info просто переворачивает сказанное мною, и говорит о том, что динамического выделения регистров нет. Так? Или что ты хотел сказать?
Чувак, я тебе скажу вот что. Если ты встреваешь в разговор взрослых дядей, чтобы бляснуть своими познаниями, ты хотя б выспись сначала как следует после празднования НГ. То есть до третьего числа молчи зубами к стенке.
К слову, я отмечу, что микрокод есть во всех современных процессорах. В том числе и в arm'ах. Микрокод сильно упрощает процессор, вне зависимости от того, risc это или cisc, потому что любая операция процессора будет сложной в железе, и её прям-таки напрашивается разбить на микрооперации. Более того, конвеерное выполнение инструкций требует микроопераций.
> Однако в x86 проблема несколько другая - там сложных инструкций оочень много,
> и при этом сомнительной полезности в современном мире, оптимизировать их дорого
> и не нужно.Реальные проблемы x86:
1) это не масштабируется вертикально.
2) переусложненные системы, которые крайне сложны в bringup и не могут ни шагу без блобов
3) два с половиной поставщика вместо экосистемы
4) переклин не винтеле которому в сабжеобразном ловить нечего
> Реальные проблемы x86:
> 1) это не масштабируется вертикально.x86 масштабируется и вертикально и горизонтально. Более того, до определённого момента на горизонтальное масштабирование (сиречь число CPU, далее ведер) просто забивали кроме серверных применений. Просто вертикальное уже почти достигло имеющихся физических пределов технологии - все остальные к таковым тоже близко, но в силу меньшей востребованности - чуть дальше.
> 2) переусложненные системы, которые крайне сложны в bringup и не могут ни шагу без блобов
С армами всё ещё хуже. Во-первых, жутчайшая фрагментация. Во-вторых, фрагментация + вендорлок чуть более, чем везде. Без блоба во внутренние "акселераторы" редкий реальный арм (я не о чистых дебажных, я о реально эксплуатируемых) вообще как-либо стартует, ну либо стартует, но в виде огрызка с чистой жевалкой команд и околонулём периферии.
> 3) два с половиной поставщика вместо экосистемы
Если честно - это лучше чем полторы сотни поставщиков, из которых каждый выхлоп со своими блобами и квирками и без нормальной совместимости с остальными вообще (разве что опять брать чистый огрызок командодробилки, но тогда оно ни в производительность, ни в потребление).
> Если бы сейчас кто-то решил изобрести новый cisc, то он смог бы вместить туда намного более полезные инструкцииА через 10 лет - ещё раз переизобрести, с новыми. И каждые 10 лет - переиначивать все ОС и компиляторы. x86 потому в недостижимых высотах и летает, что реальная ISA, с нее... сроками поддержки и совместимости. И не только собственно в системе команды CPU, но и в инфраструктуре.
А как микроядро( скорее наноядро) может иметь размер 4 кБ, ведь Раст имеет рантайм( даже без std он один больше этих 4 кБ наверное будет) ?
Вот это нормальный вариант использования rust. Никакой условной компиляции не надо. Чип один - код один. С жестко зашитой архитектурой.
Вплоть до каждого регистра.Из-за этого код остается читаем и без дублирования.
Это единственно верный вариант использования rust.
Получилось отличное электрическое ТС из печёной массы.
> Создатели чипа Baochip-1x попытались совместить легковесность,
> свойственную микроконтроллерам ARM без MMU, с возможностями изоляции памяти, доступными в полноценных CPU.И получилась какая-то неведомая е... х... из разряда ни два ни полтора.
> Чип спроектирован для использования вместе с микроядерной операционной системой Xous,
Да еще - с неведомым системным софтом ни два ни полтора.
Итого? Удачи в продажах этому чипмейкеру :). А пока заказики лотов уехали allwinner и wch, тоже с RISCV но без всякой эзотерики.
Совместимости ни с чем нету, так что вещь сама в себе, такое производят каждый месяц кто-нибудь не по разу.
> Совместимости ни с чем нету, так что вещь сама в себе, такое
> производят каждый месяц кто-нибудь не по разу.Ну как бы можете посмотреть на продажи Novena или что там у этого автора. Вот только с такой же фигней но по 22 нм техпроцессу его инвесторы линчуют, пожалуй, если он не придумает куда пару миллионов этого спихнуть. А с таким дизайном чипа это будет нелегко.
Да он уже спихнул. Производство чипа оплатила компания, делающей криптокошельки. С хуангом по-видимому договор - он им чип сдизайнит бесплатно, а они оплатят производство, и у этой же компании энтузиасты эти физические чипы и купят как дополнительный бизнес. Мемристорная память на чипе - это тоже прикол от этой компании, их разработка, поэтому все кто хотят форкать - хоть обфоркуются, чип завязан на патенты и ноу-хау этой компании.
Я даже не уверен, что чип сам хуанг дизайнил, а не компания, а хуанга как франшизу на раскрутку.