https://www.opennet.ru/openforum/vsluhforumID3/135144.html Опубликован выпуск проекта Tinygo 0.34, развивающего компилятор языка Go для маломощных систем, таких как микроконтроллеры и встраиваемые устройства, которым необходима генерация очень компактных исполняемых файлов и низкое потребление ресурсов. Компиляция для поддерживаемых целевых платформ реализована в tinygo при помощи LLVM, а библиотеки функций заимствованы из основного инструментария проекта Go. Код распространяется под лицензией BSD...<br><br>Подробнее: https://www.opennet.ru/opennews/art.shtml?num=62115<br> https://www.opennet.ru/openforum/vsluhforumID3/135144.html#120 Tue, 10 Dec 2024 15:50:06 GMT Tinygo + ASM. Идеально и не нужно большен ничо.<br> https://www.opennet.ru/openforum/vsluhforumID3/135144.html#119 Wed, 30 Oct 2024 08:57:56 GMT Я к тому, что если бы мне потребовалось автоматическое управление памятью плюс уплотнение кучи, то пришлось бы смотреть в сторону языков уровнем выше Go. Тем более, что 10-е правило Гринспена никто не отменял. Но пока не потребовалось, да и нашёл Рефал - там фрагментация кучи не может привести к ошибке "недостаточно памяти", только к просадке производительности на процессорах, где есть кеш. Сам язык специфичен и не факт, что сгодится для МК. Но подход - все объекты одного размера - вполне сгодится. Если нужны размеры разные, как раз две-три кучи и получится. :)<br> https://www.opennet.ru/openforum/vsluhforumID3/135144.html#118 Tue, 29 Oct 2024 18:07:20 GMT &gt; Эппл уже зажал сорцы. У них свой, особый, уличный clang для xcode. <br><br>А сделать свой gcc для внутреннего использования и никому не отдавать, что помешает?<br><br>GCC это попытка монополизировать рынок компилаторов и продвинуть GPL.<br>Как бы гнутые не пыжились со своим ЕЕЕ, ее прокатило.<br>Пришлось добавлять GCC RUNTIME LIBRARY EXCEPTION, чтобы успокоить народ.<br>Не каждому понравится перспектива "скомилил код, тот заразился коммуняцким gpl-раком".<br> <br>&gt; Не могу придумать с наскока архитектуру проца которую бы умел clang но не умел хоть какой-то выводок gcc. А наоборот - вполне. И меня волнует - в основном вот это.<br><br>Если не сложно, назови пару штук.<br>Подозреваю, что там будет что-то нераспространненное, да еще древнее.<br><br>&gt; А почему у Эппла свой, уличный clang? Проприетарный. А мне быть вторым сортом как-то не в тему.<br><br>Лол, посмотри кто был в комитете GCC.<br>IBM, Red Hat, nethype GmbH, Google и тд<br>Думаешь сейчас это не так?<br>Что они завтра решат, то ты и скушаешь. Зато дааа не второй сорт))<br><br>И разве GPL запреща https://www.opennet.ru/openforum/vsluhforumID3/135144.html#116 Tue, 29 Oct 2024 17:48:38 GMT &gt; Вот тут кто б его знает. Но называя вещи своими именами - ну и чем вы такой софт заменять будете? <br><br>Я слава богу не буду)<br><br>&gt; Я могу позаковыристей софта накидать. У вас есть FEM симуляторы? Microwave cad? Или... вы будете платы под 5G соты на кульмане? :) <br><br>У китайцев все купят.<br><br>&gt; Да что там, попробуйте хотя-бы ADC/DAC под это произвести? А, это умеет 1 фирма на всю планету, "Analog Devices"? Ух ты, сюрприз!<br><br>Да, тут хотя бы гвозди...<br><br>&gt;&gt; Это я понимаю, все таки Embrace, Extend, and Extinguish это классика для <br>&gt; Невозможно написать ядро, boot loader или фирмварь используя только стандартный си. Там <br>&gt; просто не регламентированы некоторые критичные вещи, НЕОБХОДИМЫЕ для таких вещей. <br><br>Но привязывать это к единственному гнутому компилятору, который еще и получивщейся код превращал <br>в г&#822;о&#822;в&#822;н&#822;о&#822; GPL (и по этой причине пришлось делать GCC Runtime Library Exception)<br>Т.е ЕЕЕ в прямом его смысле.<br><br>&gt; Как можно принять стандарт freestanding, но не регламентировать скажем pl https://www.opennet.ru/openforum/vsluhforumID3/135144.html#115 Tue, 29 Oct 2024 17:38:32 GMT &gt;&gt; в угоду автодеску загасили руторент и все раздачи с ним.<br>&gt; Ну такое.<br>&gt; Думаю даже сейчас пользовать автокад это плохая идея, тк хз сколько там закладок.<br><br>Вот тут кто б его знает. Но называя вещи своими именами - ну и чем вы такой софт заменять будете? Я могу позаковыристей софта накидать. У вас есть FEM симуляторы? Microwave cad? Или... вы будете платы под 5G соты на кульмане? :) Да что там, попробуйте хотя-бы ADC/DAC под это произвести? А, это умеет 1 фирма на всю планету, "Analog Devices"? Ух ты, сюрприз!<br><br>&gt;&gt; совсем трупов как видите - подтянули.<br>&gt; Не прошло и 20 лет))<br><br>Как говорится, лучше поздно чем никогда.<br><br>&gt; Это я понимаю, все таки Embrace, Extend, and Extinguish это классика для <br>&gt; всяких 321в, опенсорсных или нет.<br><br>Невозможно написать ядро, boot loader или фирмварь используя только стандартный си. Там просто не регламентированы некоторые критичные вещи, НЕОБХОДИМЫЕ для таких вещей. Как можно принять стандарт freestanding, но не регламентировать скажем placement в конкретную секцию энног https://www.opennet.ru/openforum/vsluhforumID3/135144.html#114 Tue, 29 Oct 2024 17:17:00 GMT &gt;&gt;у gcc лицензия не позволяла зажимон сорцов и это имело некий эффект.<br>&gt; Не, просто gcc был на десятку лет раньше clangа. <br><br>Эппл уже зажал сорцы. У них свой, особый, уличный clang для xcode.<br><br>&gt; Как clang допилили до рабочего состояния - так всё новое делают под clang/llvm.<br><br>Не могу придумать с наскока архитектуру проца которую бы умел clang но не умел хоть какой-то выводок gcc. А наоборот - вполне. И меня волнует - в основном вот это.<br><br>&gt; И "зажимать сорцы" особо смысла нет. Фирмы, продающие чипы - они с <br>&gt; чипов зарабатывают.<br><br>А почему у Эппла свой, уличный clang? Проприетарный. А мне быть вторым сортом как-то не в тему.<br><br>&gt; радостью это свалят на сообщество.<br><br>Там рулят гугл и эпл на двоих в основном. На мой вкус обе корпорахи - "не очень".<br><br>&gt; Разумеется. Поэтому оптимизировать надо через LLVM, а потом уже этот LLVM конвертировать <br>&gt; в машинный код.<br><br>Вам надо - вы и занимайтесь. Мне 8051 вообще не надо в общем случае. А вот какие-нибудь извраты типа Xtensa/LatticeMico и т.п.... - возможны вариа https://www.opennet.ru/openforum/vsluhforumID3/135144.html#113 Tue, 29 Oct 2024 16:36:39 GMT &gt; Не думаю <br><br>Это заметно, да :)<br><br>&gt; что увольнение "16% of Fuchsia employees" сильно повлияет на разработку.<br><br>Это на секундочку - каждый 6-ой в команде. По опыту (которого у тебя тупо нет) - это влияет :(<br> https://www.opennet.ru/openforum/vsluhforumID3/135144.html#112 Tue, 29 Oct 2024 14:37:13 GMT Так и не надо все что ни есть в одно корытце пихать. Универсальное одинаково хуже чего угодно, по сравнению со специализированным.<br>Кстати, на ESP8266, ESP32, STM32 я использую две кучи, а иногда и три кучи с разной реализацией. <br> https://www.opennet.ru/openforum/vsluhforumID3/135144.html#111 Tue, 29 Oct 2024 12:19:26 GMT Дефрагментация в общем случае требует перемещение объекта в памяти, для чего добавляется лишняя косвенность, либо корректируются все ссылки. Не уверен, что в Go такое возможно малой кровью. Когда немного копал вопрос, Compacting GC встречались в языках уровня LISP.<br>