vpv.vpv (26.02.2025 11:50, просмотров: 263) ответил vpv.vpv на Скажите, есть ли где описание ассемблера для CH32V003 / CH32X035
(QingKeV2/V4)? Гуглится что-то типа
"QingKeV4_Processor_Manual.PDF", но на сайте WCH даёт или китайские
иероглифы, или 404.-
- А ещё RISC-V это когда под каждый чип (в лучшем случае под каждого
вендора) свой компилятор. Тут только GCC, никогда IAR не будет
поддерживать весь этот зоопарк. - VladislavS.(26.02.2025 14:42)
- mainline GCC тоже не будет поддерживать зоопарк когда у разных
чипов свое уникальное расширение системы команд. Будет (то есть
уже) фрагментирование на 100500 кривых-косых неподдерживаемых
форков. Это RISC-V и похоронит. - 3m(27.02.2025 16:06)
- Посмотрел я, какие особенности у CH32V003 с точки зрения
компилятора. Я так понял, китайский GCC добавляет расширение xw
(несколько компактных инструкций), масштаб эффекта от которого
неясный и, скорее всего, скромный. Ну и
__attribute((interrupt("WCH-Interrupt-fast"))) тоже со скромным
эффектом, и там есть варианты обхода. Официальный GCC должен
нормально подойти. Короче, горевать рано. - SciFi(10.03.2025 09:05)
- Про масштаб эффекта расширения XW на примере моего проекта на
CH59x: il-2(691 знак., 11.03.2025 06:48)
- Цифры - страшная сила, особенно в умелых руках. Если не 150к таблиц
в коде, то разница впечатляет мизерностью. - Andreas(11.03.2025 09:31)
- Вообще-то да. Сейчас глянул навскидку map-файл. Из всего этого кода
около 10Кб - это мои исходники. Все остальное - библиотека BLE. Так
что правильнее наверное смотреть контраст на фоне 10кБ. 200 байт на
фоне 10Кб - это уже 2% :-) Не много, но и не так уж мало. - il-2(11.03.2025 09:50)
- Сейчас часто критично не объем памяти, а быстродействие. Возможно
там быстродействие выросло больше, не смотря на скромное уменьшение
объема - AlexBi(11.03.2025 11:23)
- Быстродействие - это расшивание узкого места. Там можно и асм, если
оч. надо. А если у вас какое-то другое быстродействие, то оно
неправильное. - SciFi(11.03.2025 11:25)
- Быстродействие именно это, только оно может появляться без
привлечения АСМа. У вас не было такого что без включенной
оптимизации в компиляторе оно не работает, т.е. не успевает? АСМ -
крайняя мера, лучше обходиться без него. - AlexBi(11.03.2025 12:59)
- Было разок за годы, причем при изменении в другом месте переставало работать. Да еще и при переходе на другую версию компилера может перестать работать.Или начнет. Напрягся, переписал кусочек команд на 50 на асм и забыл про весь этот неустойчивый гимор. - Andreas(11.03.2025 13:06)
- Когда-то давно было, нужно было обработчик прерывания допилить. Ну,
допилил. Уж там точно вот эти XW инструкции никак не помогли бы. - SciFi(11.03.2025 13:05)
- Разве плохо, когда кто-то за тебя все сделал и добавил в компилер
поддержку? И прога даром и бесплатно стала чуть короче. - Andreas(11.03.2025 13:10)
- Подъехали дополнительные сведения. На сайте Renesas можно скачать тулчейн LLVM+clang для RISC-V. Там LLVM 19.1.7, он умеет -march=rv32ec_xwchc. Проверил - действительно умеет. И никаких китайских форков. - SciFi(15.03.2025 22:26)
- Я только за. Но здесь "поддержка" в китайском форке GCC, и там есть ряд оговорок. А так да. С другой стороны, это я зажрался, наверное. Для того же стм8 если бы был хоть какой-то форк GCC с более-менее вменяемой генерацией кода, оторвали бы с руками :-) - SciFi(11.03.2025 13:13)
- Разве плохо, когда кто-то за тебя все сделал и добавил в компилер
поддержку? И прога даром и бесплатно стала чуть короче. - Andreas(11.03.2025 13:10)
- Быстродействие именно это, только оно может появляться без
привлечения АСМа. У вас не было такого что без включенной
оптимизации в компиляторе оно не работает, т.е. не успевает? АСМ -
крайняя мера, лучше обходиться без него. - AlexBi(11.03.2025 12:59)
- Быстродействие - это расшивание узкого места. Там можно и асм, если
оч. надо. А если у вас какое-то другое быстродействие, то оно
неправильное. - SciFi(11.03.2025 11:25)
- Это зависит от того, мы покупаем или продаём :-) - SciFi(11.03.2025 09:56)
- вот да , недавно переделывал под больший экран, прошивка чуть 50к
превысили и я начал нервничать и думать об оптимизации. А потом
вспомнил, что проц с 128к оказался дешевле и в итоге им закупились. - Andreas(11.03.2025 10:31)
- Продался за копейку! А мог бы покрасноглазить денёк-другой :-) - SciFi(11.03.2025 10:34)
- вот да , недавно переделывал под больший экран, прошивка чуть 50к
превысили и я начал нервничать и думать об оптимизации. А потом
вспомнил, что проц с 128к оказался дешевле и в итоге им закупились. - Andreas(11.03.2025 10:31)
- Сейчас часто критично не объем памяти, а быстродействие. Возможно
там быстродействие выросло больше, не смотря на скромное уменьшение
объема - AlexBi(11.03.2025 11:23)
- Вообще-то да. Сейчас глянул навскидку map-файл. Из всего этого кода
около 10Кб - это мои исходники. Все остальное - библиотека BLE. Так
что правильнее наверное смотреть контраст на фоне 10кБ. 200 байт на
фоне 10Кб - это уже 2% :-) Не много, но и не так уж мало. - il-2(11.03.2025 09:50)
- А разговоров-то было! - SciFi(11.03.2025 08:05)
- Цифры - страшная сила, особенно в умелых руках. Если не 150к таблиц
в коде, то разница впечатляет мизерностью. - Andreas(11.03.2025 09:31)
- xw - расширение - неоднозначно, с одной стороны чтение и запись
портов 8 или 16 бит упаковывается команда, с другой стороны -
использование типов uint16_t и uint8_t приводит к дополнительным
командам в коде по наложению маски! Zikon(339 знак., 10.03.2025 10:14)
- Насколько мне известно, стандартный GCC не ругается, когда ему в
параметрах архитектуры добавляешь xw. Вроде бы, это расширение уже
включили в ванильную ветку. - Nikolay_Po(10.03.2025 18:39)
- расширение xw - содержит 8 команд, 4 команды взяты у Huawei, а 4
команды, что со стеком добавили сами. Стандартное расширение Zcb
имеет 4 команды, что без стека, но OPкод совсем другой и более
обрезанные по части смещения. А gcc всё что можно, то и будет
поддерживать! - Zikon(10.03.2025 19:44)
- А где почитать что за инструкции? - Andreas(10.03.2025 19:53)
- В RM на ядро " XW: 16-bit compression instruction for
self-extending byte and half-word operations. Note: To further
improve code density, extend the XW subset by adding the following
compression directives c.lbu/c.lhu/c.sb/c.sh/c.lbusp/ c.lhusp/c.sbsp/c.shsp, use based on the MRS compiler or the toolchain it provides." - petrd(10.03.2025 20:04)
- Как связаны LLVM с GCC? Nikolay_Po(179 знак., 11.03.2025 16:10, ссылка)
- Это я видел, но что это за инструкции? - Andreas(10.03.2025 20:06)
- Товарищи китайцы такие затейники (инфа из LLVM): SciFi(2 знак., 10.03.2025 20:40, ссылка, картинка)
- Вот тут petrd(145 знак., 10.03.2025 20:11, ссылка)
- В RM на ядро " XW: 16-bit compression instruction for
self-extending byte and half-word operations. Note: To further
improve code density, extend the XW subset by adding the following
compression directives c.lbu/c.lhu/c.sb/c.sh/c.lbusp/ c.lhusp/c.sbsp/c.shsp, use based on the MRS compiler or the toolchain it provides." - petrd(10.03.2025 20:04)
- А где почитать что за инструкции? - Andreas(10.03.2025 19:53)
- расширение xw - содержит 8 команд, 4 команды взяты у Huawei, а 4
команды, что со стеком добавили сами. Стандартное расширение Zcb
имеет 4 команды, что без стека, но OPкод совсем другой и более
обрезанные по части смещения. А gcc всё что можно, то и будет
поддерживать! - Zikon(10.03.2025 19:44)
- Нет там аппаратного стека, там есть аппаратный механизм сохранения
10 регистров в пользовательский стек, по времени это так же как и
программное сохранение. - petrd(10.03.2025 11:35)
- Тогда непонятно ограничение 2 уровнями, если в общий стек пихают,
какая разница сколько уровней? - Andreas(10.03.2025 12:08)
- Ограничили вложенность прерываний! Только у ch32v30x (QK_V4F) аппаратный стек 3 уровня и вложенность до 8, после 3-х пишет в память - Zikon(10.03.2025 15:20)
- Это про вытеснение. - petrd(10.03.2025 12:11)
- А вот и не факт. Во 1-х в манулах на ядра QingKe явно описывается
HPE как аппаратный стек. Конечно, реализация может не
соответствовать описанию - китайцы большие затейники в этом плане.
Однако есть еще кое-какие интересные биты в регистрах CSR, которые
указывают на аппаратную реализацию HPE: il-2(613 знак., 10.03.2025 14:41)
- Факт. Речь шла про V003, а значит ядро V2. V3 и V4 не трогаю,
говорю только про V2. petrd(703 знак., 10.03.2025 15:27)
- Ну вот, кое что проясняется. il-2(471 знак., 10.03.2025 15:55)
- СH32V003. Все прерывания в моем коде имеют атрибут
__attribute__((interrupt("WCH-Interrupt-fast"))). petrd(163 знак., 10.03.2025 16:32, картинка)
- А вот сработало первое прерывание и MPOP = 1. petrd(1 знак., 10.03.2025 16:43, картинка)
- СH32V003. Все прерывания в моем коде имеют атрибут
__attribute__((interrupt("WCH-Interrupt-fast"))). petrd(163 знак., 10.03.2025 16:32, картинка)
- Ну вот, кое что проясняется. il-2(471 знак., 10.03.2025 15:55)
- Аппаратный стек - это такой, который сохраняет все регистры за 1
такт. Если для сохранения нужно по 1 такту на регистр, то толку с
того "аппаратного стека"? - =AlexD=(10.03.2025 14:55)
- Вот из мануала на QK_V4 ( здесь 3 уровня - это для V4F , для
остальных V4 - будет 2) ( V3 - тоже аппаратный стек есть 2 -
уровня) ( V2 - нет аппаратного стека ) Zikon(1 знак., 10.03.2025 15:13, картинка)
- Картинка не отвечает на вопрос о латентности. - =AlexD=(10.03.2025 15:26)
- Вот из мануала на QK_V4 ( здесь 3 уровня - это для V4F , для
остальных V4 - будет 2) ( V3 - тоже аппаратный стек есть 2 -
уровня) ( V2 - нет аппаратного стека ) Zikon(1 знак., 10.03.2025 15:13, картинка)
- Факт. Речь шла про V003, а значит ядро V2. V3 и V4 не трогаю,
говорю только про V2. petrd(703 знак., 10.03.2025 15:27)
- А вот и не факт. Во 1-х в манулах на ядра QingKe явно описывается
HPE как аппаратный стек. Конечно, реализация может не
соответствовать описанию - китайцы большие затейники в этом плане.
Однако есть еще кое-какие интересные биты в регистрах CSR, которые
указывают на аппаратную реализацию HPE: il-2(613 знак., 10.03.2025 14:41)
- Hardware Prologue/Epilogue (HPE) - я неправильно Hardware - понял? - Zikon(10.03.2025 11:51)
- ну и как он за 1 такт сохранит 10 регистров в памяти ? Да и разница
по времени всё-таки есть! - Zikon(10.03.2025 11:46)
- Немного ошибся в v003 - нет теневых регистров, в старших qkV4 - есть теневой аппаратный стек до 3-х уровней с сохранением 16-ти регистров, а в v003 действительно идет сохранение в стек и происходит быстро, потому что не надо декодировать комманды. Надо на x033 или v203 - проверить. - Zikon(10.03.2025 12:20)
- Никак он за 1 такт не сохранит. 2 такта на сохранение регистра * 10 +... Klen раньше уже исследовал petrd(1 знак., 10.03.2025 12:12, ссылка)
- У вас на клаве восклицательный знак залип :-) Вот кто-то не поленился и измерил при помощи осциллографа >>> SciFi(1 знак., 10.03.2025 11:50, ссылка)
- Тогда непонятно ограничение 2 уровнями, если в общий стек пихают,
какая разница сколько уровней? - Andreas(10.03.2025 12:08)
- Насколько мне известно, стандартный GCC не ругается, когда ему в
параметрах архитектуры добавляешь xw. Вроде бы, это расширение уже
включили в ванильную ветку. - Nikolay_Po(10.03.2025 18:39)
- Про масштаб эффекта расширения XW на примере моего проекта на
CH59x: il-2(691 знак., 11.03.2025 06:48)
- GCC пилят все кому не лень под свои чипы. Я и писал, что под каждый чип свой компилятор. А iar всех никогда не покроет. - VladislavS.(27.02.2025 20:01)
- Посмотрел я, какие особенности у CH32V003 с точки зрения
компилятора. Я так понял, китайский GCC добавляет расширение xw
(несколько компактных инструкций), масштаб эффекта от которого
неясный и, скорее всего, скромный. Ну и
__attribute((interrupt("WCH-Interrupt-fast"))) тоже со скромным
эффектом, и там есть варианты обхода. Официальный GCC должен
нормально подойти. Короче, горевать рано. - SciFi(10.03.2025 09:05)
- Для AVR же поддержали )) В одном флаконе "IAR C/C++ Compiler for
AVR" и "IAR C/C++ Compiler for AVR_TINY" - позволяет писАть
программки даже для AT90S1200 (!), у которой ни ОЗУ ни стека нет. - vpv.vpv(27.02.2025 08:39)
- "IAR C/C++ Compiler for AVR_TINY" - это когда такое в природе было? AlexG(58 знак., 27.02.2025 15:09)
- С какой версии началось - не помню, но встречается уже давно. Одно
семейство AVR - два IAR компилятора. vpv.vpv(1 знак., 03.03.2025 09:06, картинка)
- Не похоже чтобы iccavr_tiny мог что-то скомпилировать для тех Tiny,
которые без ОЗУ. Пару попробовал - говорит "this CPU model is not
supported by the compiler." - AlexG(03.03.2025 09:30)
- Да, наверное, для Си какое-то ОЗУ для стека всё-таки нужно,
попробовал АТ90S1200 - финт не проходит. Тут я наврал. :)) А вот
АТ90S2313 уже компилит. - vpv.vpv(04.03.2025 11:05)
- ЕМНИП, какой-то старый AVR GCC умел и под них. Но это очень
условный Цэ - LightElf(04.03.2025 15:06)
- C GCC это можно было делать так: AlexG(297 знак., 04.03.2025 16:42, ссылка, ссылка)
- Я для ATTINY13A писал какую-то шнягу на GCC, 64 байта хватит всем!
;-) - LightElf(04.03.2025 17:07)
- Для Тини13/15 на Си писали в аврстудио5 с тем компилятором, что шёл в комплекте. Вроде бы на основе той же GCC сделано - symbions(05.03.2025 20:38)
- Я тоже писал для tiny13, в IAR, оно даже работало, но мне не
понравилось как. - AlexG(05.03.2025 12:38)
- Звучит как возврат воздушных шаров по гарантии - "Они меня не
радуют" ;-)) - vpv.vpv(06.03.2025 11:21)
- Не стабильно оно работало, а ни памяти, ни периферии чтобы сделать
что-то более адекватное в tiny13 не было. Хотя знаю, есть
разработчики, которые в таких условиях справляются. - AlexG(06.03.2025 14:41)
- "Нестабильная работа" зависит не от контроллера же :)). У нас они в серийных изделиях годами работают, в жару и холод. Нареканий никаких. - vpv.vpv(10.03.2025 07:11)
- Странно, делали для улицы на тини13, небольшая программа на иар
авр, работает и даже ни одного возврата нет по проблемам на
вторичной стороне после сетевого трансформатора.. - Andreas(06.03.2025 14:46)
- Именно так. Тини13А - малюсенькая рабочая лошадка. )) - vpv.vpv(10.03.2025 07:13)
- микроконтроллер нормальный, просто маленький очень и тесный - AlexG(06.03.2025 16:23)
- И очень недорогой! - vpv.vpv(10.03.2025 07:08)
- PY32F002AL15S6TU - (sop8) - platan.ru - 18руб (от 1шт) Zikon(369 знак., 10.03.2025 09:42)
- был. в ближайшем магазине: ATTINY13A-SSU - 155р., APM32F030C8T6 - 107р. - AlexG(10.03.2025 08:55)
- И очень недорогой! - vpv.vpv(10.03.2025 07:08)
- Не стабильно оно работало, а ни памяти, ни периферии чтобы сделать
что-то более адекватное в tiny13 не было. Хотя знаю, есть
разработчики, которые в таких условиях справляются. - AlexG(06.03.2025 14:41)
- Звучит как возврат воздушных шаров по гарантии - "Они меня не
радуют" ;-)) - vpv.vpv(06.03.2025 11:21)
- IAR AVR прекрасно для ATTiny13A компилит. Особенно с оптимизацией по размеру кода. У нас несколько серийных устройств выпускается на Тини13. - vpv.vpv(05.03.2025 11:40)
- А еще тинька13 присутствует в некрочиповском XC8 2.0 и в CodeVision. Глянул - именно второй пользовал в парочке своих приблудок на Attiny13. - Гyдвин(04.03.2025 17:38)
- Я для ATTINY13A писал какую-то шнягу на GCC, 64 байта хватит всем!
;-) - LightElf(04.03.2025 17:07)
- C GCC это можно было делать так: AlexG(297 знак., 04.03.2025 16:42, ссылка, ссылка)
- ЕМНИП, какой-то старый AVR GCC умел и под них. Но это очень
условный Цэ - LightElf(04.03.2025 15:06)
- Да, наверное, для Си какое-то ОЗУ для стека всё-таки нужно,
попробовал АТ90S1200 - финт не проходит. Тут я наврал. :)) А вот
АТ90S2313 уже компилит. - vpv.vpv(04.03.2025 11:05)
- Не похоже чтобы iccavr_tiny мог что-то скомпилировать для тех Tiny,
которые без ОЗУ. Пару попробовал - говорит "this CPU model is not
supported by the compiler." - AlexG(03.03.2025 09:30)
- С какой версии началось - не помню, но встречается уже давно. Одно
семейство AVR - два IAR компилятора. vpv.vpv(1 знак., 03.03.2025 09:06, картинка)
- Сравнили тоже мне. Зоопарк RISC-V несравнимо больше и ситуация
будет только усугубляться. - VladislavS.(27.02.2025 10:26)
- До зоопарка 8051 им исчо далеко, а с 51-ми как-то справились. - LightElf(27.02.2025 12:28)
- Не скажите. У 51-х периферия разная. А у RISC-V и расширения набора
команд, и обработка прерываний совершенно разная. - VladislavS.(27.02.2025 13:42)
- У 51-х тоже много всякого разного, иногда - неожиданного ;-) Одно количество DPTR чего стоит. - LightElf(27.02.2025 15:23)
- Не скажите. У 51-х периферия разная. А у RISC-V и расширения набора
команд, и обработка прерываний совершенно разная. - VladislavS.(27.02.2025 13:42)
- До зоопарка 8051 им исчо далеко, а с 51-ми как-то справились. - LightElf(27.02.2025 12:28)
- "IAR C/C++ Compiler for AVR_TINY" - это когда такое в природе было? AlexG(58 знак., 27.02.2025 15:09)
- mainline GCC тоже не будет поддерживать зоопарк когда у разных
чипов свое уникальное расширение системы команд. Будет (то есть
уже) фрагментирование на 100500 кривых-косых неподдерживаемых
форков. Это RISC-V и похоронит. - 3m(27.02.2025 16:06)
- Лекарства на него нет. - VladislavS.(26.02.2025 14:39)
- Вот те раз... Вроде были какие-то универсальные? Но пока это всё равно, как оказалось, не актуально. - vpv.vpv(27.02.2025 08:41)
- ПМСМ, IAR разжижает мозги и зашоривает взгляд, для непосвящённых. А
ещё заставляет использовать синтаксис, несовместимый с ANSI C /
GCC, что приводит к большим сложностям при отладке кода на ПК
(имеется в виду модульное тестирование). VVB(434 знак., 26.02.2025 13:51)
- А когда это attribute в двойных скобках из GCC стали стандартом?
Авторы стандартов С/С++ так и не сподобились стандартизовать
расширения необходимые для embedded программирования. В результате
что GCC, что IAR решают одинаковые проблемы каждый своим способом,
и все эти способы одинаково не стандартные. Лично для меня
преимущества IAR это наличие вменяемой документации и DLIB -
аккуратно обезжиренная плюсовая библиотека. - ЫЫyкпy(26.02.2025 19:31)
- За такую оптимизацию кода, какую может дать IAR, я думаю, ему можно
простить всё. ))) - vpv.vpv(27.02.2025 08:52)
- "Легендарная" оптимизация IAR она или из мира AVR или из 2010-х когда GCC под арм был в зачаточном состоянии. В 2025-м GCC не уступает или превосходит IAR как показано в недавней теме на электрониксе. Другое дело что линкер IAR умеет работать с дырами в адресном пространстве а LD - нет но это уже терминальный случай. - 3m(27.02.2025 16:16)
- Это распространённое заблуждение. В нём подразумевается нулевая
ценность труда программиста. Это фу. - SciFi(27.02.2025 08:54)
- Не согласен. Если компилятор сможет впихнуть код в камень меньшего
объёма, который на 40 рублей дешевле, то каждая тысяча изделий тут
же даст 40.000 рублей экономии. А программа и программист будут те
же самые. - vpv.vpv(27.02.2025 09:01)
- В ИАРе тащил одновременно похожие проекты под стм8, авр и 8051 - среда одна, оптимизатор хороший, но редактор убог, а компилер проприетарен. На стм32 я вообще разницы с GCC по выхлопу не заметил, по авр другие пишут о небольшой разнице, поэтому когда 8051 и авр окончательно сдохли(у меня) радостно переполз на связку VScode+GCC. Старенький ИАР вынужденно использую только для стм8 и доработок старого, когда под риск-5 пойдут проекты иар даже не рассматриваю и не сомневаюсь, Andreas(21 знак., 27.02.2025 09:16)
- Сферический код для сферического камня в вакууме. Фактически
неудобные тулзы замедляют работу множества программистов каждый
день. Это сдвиг сроков и убытки. - SciFi(27.02.2025 09:02)
- Это современные ембеддеры просто зажрались чуток, когда в одном
корпусе почти за одни деньги линейка от 16 до 512 памяти. Есть у
тебя 8751, AT90s2313 или STM8S003 и изволь туда запихнуть все
нужное, камней с большей памятью нет или в другом корпусе и сильно
дороже. - Andreas(27.02.2025 09:28)
- Ну и нормально. Не продолжать же топить самовар шишками, можно и
электрочайником воспользоваться. А самовар для отдыха :-) - SciFi(27.02.2025 09:33)
- А вдруг война, а
я усталнавык потерян, в свой асм 20летней давности с благоговейным ужасом заглядываю. Выживальщики в лесах живут в ожидании пиздеца, а ембеддеры на асме продолжают писать. ) - Andreas(27.02.2025 09:47)- Клевещут, паровозы списали, так и не дождались ядрёного
апокалипсиса... - SciFi(27.02.2025 09:52)
- Списали и правильно сделали! Паровоз - это пипец капризный агрегат и если чо не так либо топка тухнет либо оно тупо взрывается. Автоматики и защит - никакой, вся автоматика белковая. Обученного персонала на паровозы даже если их хранить нет и не будет! - 3m(27.02.2025 17:23)
- Т-62 расконсервировали же и снаряды нашли. Даже Т-34 якобы где-то в
бой шли в 14м. Может и паровозы не все еще в печках.... - Andreas(27.02.2025 09:59)
- Паровозы не получится расконсервировать даже если рептилоиды
привезут их с планеты Нибиру в неограниченном количестве: на ЖД
полностью ликвидирована инфраструктура водопитания. Для справки:
паровозу не только уголь или дрова для топки нужны, ему еще надо
дохрена воды на каждой станции потому что цикл открытый причем вода
не из ближайшей лужи а хотя бы малость подготовленная. Все это
ликвидировано, так что никто никуда на паровозиках не поедет. - 3m(27.02.2025 16:22)
- Там еще и паровозные круги ликвидированы повсеместно, а паровозы не
умеют в задний ход - LightElf(27.02.2025 17:07)
- Ну, положим, не повсеместно ликвидированы. - Kpoк(27.02.2025 18:34)
- Экскурсионные маршруты есть на паровозах, в ютубе ролики есть,
значит немного есть рабочих и бегают как-то обратно возвращаются. - Andreas(27.02.2025 17:09)
- Про эти круги мне дед железнодорожник из забайкалья еще в 2003
говорил. Я в Благовещенск ехал, а он на Байкале сел до Улан-Удэ.
Про воду тоже говорил и по его мнению паровозами воспользоваться
уже не получилось бы. Ругался что инфраструктуру уничтожили. - Codavr(10.03.2025 12:01)
- На станции Орехо-Зуево - где-то до середины-конца 90-х простояла
водяная колонка между главными путями. - Toчкa oпopы(10.03.2025 12:03)
- Я на России ехал в 80м, они еще все на местах были. Codavr(345 знак., 10.03.2025 14:00)
- На станции Орехо-Зуево - где-то до середины-конца 90-х простояла
водяная колонка между главными путями. - Toчкa oпopы(10.03.2025 12:03)
- Про эти круги мне дед железнодорожник из забайкалья еще в 2003
говорил. Я в Благовещенск ехал, а он на Байкале сел до Улан-Удэ.
Про воду тоже говорил и по его мнению паровозами воспользоваться
уже не получилось бы. Ругался что инфраструктуру уничтожили. - Codavr(10.03.2025 12:01)
- Там еще и паровозные круги ликвидированы повсеместно, а паровозы не
умеют в задний ход - LightElf(27.02.2025 17:07)
- Потому и расконсервировали, что снаряды нашли. - LightElf(27.02.2025 12:29)
- На Донбассе много памятников где на постаменте стоят Т-34. Один из них: enc(1 знак., 27.02.2025 12:09, ссылка)
- Паровозы не получится расконсервировать даже если рептилоиды
привезут их с планеты Нибиру в неограниченном количестве: на ЖД
полностью ликвидирована инфраструктура водопитания. Для справки:
паровозу не только уголь или дрова для топки нужны, ему еще надо
дохрена воды на каждой станции потому что цикл открытый причем вода
не из ближайшей лужи а хотя бы малость подготовленная. Все это
ликвидировано, так что никто никуда на паровозиках не поедет. - 3m(27.02.2025 16:22)
- Печке похер какой кристалл выпекать (на той же технологии), это
песок под ногами (силициум). - VVB(27.02.2025 09:52)
- В гараже посреди выжженной пустыни технологии другие уже будут. - Andreas(27.02.2025 09:56)
- Клевещут, паровозы списали, так и не дождались ядрёного
апокалипсиса... - SciFi(27.02.2025 09:52)
- А вдруг война, а
- Ну и нормально. Не продолжать же топить самовар шишками, можно и
электрочайником воспользоваться. А самовар для отдыха :-) - SciFi(27.02.2025 09:33)
- Это современные ембеддеры просто зажрались чуток, когда в одном
корпусе почти за одни деньги линейка от 16 до 512 памяти. Есть у
тебя 8751, AT90s2313 или STM8S003 и изволь туда запихнуть все
нужное, камней с большей памятью нет или в другом корпусе и сильно
дороже. - Andreas(27.02.2025 09:28)
- Не согласен. Если компилятор сможет впихнуть код в камень меньшего
объёма, который на 40 рублей дешевле, то каждая тысяча изделий тут
же даст 40.000 рублей экономии. А программа и программист будут те
же самые. - vpv.vpv(27.02.2025 09:01)
- Наиболее распространённые (armcc, clang) поддерживают расширения gcc для упаковки структур, атрибутов и прочего. iarcc выпендривается в силу тяжёлого наследия прошлого; armcc тоже выпендривался (и даже имел свой несовместимый ABI), но всё-таки решился перейти на синтаксис gcc. VVB(724 знак., 27.02.2025 07:57, ссылка)
- За такую оптимизацию кода, какую может дать IAR, я думаю, ему можно
простить всё. ))) - vpv.vpv(27.02.2025 08:52)
- В общем, примерно понятно... )) Спасибо! Просто я очень привык к
IAR AVR, особенно vpv.vpv(355 знак., 26.02.2025 14:26)
- AVR особый зверь, там вроде бы IAR действительно попотел, чтобы
получался хороший код по сравнению с другими. RISC-V хорошо
поддерживается GCC и прочими, я бы не ожидал там увидеть какое-то
значительное преимущество у IAR. В качестве ещё одного примера могу
привести IAR для STM8, там код получается такой же хреновый, как и
у всех остальных :-) - SciFi(26.02.2025 14:30)
- По слухам, сама архитектура и ассемблер AVR изначально
разрабатывались "под Си", в тесной кооперации с
копмиляторостроителями. Отсюда такой результирующий эффект. - vpv.vpv(27.02.2025 08:57)
- Это пеар и маркетинг, с этим у них всё в порядке. По факту "под Си"
не очень :-) - SciFi(27.02.2025 08:58)
- Хз что там под С, но на асме после 8051 и пиков писать было просто божественно удобно - много регистров, удобное ограниченное(но не наркомански минимальное) число команд, адресная арифметика.... - Andreas(27.02.2025 09:23)
- Голословно. )) - vpv.vpv(27.02.2025 09:02)
- у меня есть доказательства: SciFi(1 знак., 27.02.2025 09:06, ссылка)
- (цитата) "Архитектура и система команд AVR (до 133 различных
инструкций) разрабатывались совместно с фирмой IAR Systems —
производителем компиляторов языков программирования С/С++" (с) КиТ
№2 2004г. - vpv.vpv(27.02.2025 09:05)
- Годный пеар. - SciFi(27.02.2025 09:08)
- Это пеар и маркетинг, с этим у них всё в порядке. По факту "под Си"
не очень :-) - SciFi(27.02.2025 08:58)
- У иара значительно лучше, чем у других код для СТМ8, особенно если
с sdcc сравнивать, там жесть. - Andreas(26.02.2025 14:32)
- Яр впихнул туда "виртуальные регистры" и сделал вид, что STM8 - это что-то вроде арма. Получилось так себе. Я сравниваю с COSMIC. Там весьма прилично. А если причёсывать исходник, зная его повадки, будет вообще близкое соответствие между Си и дизассемблером, как завещали отцы-основатели. - SciFi(26.02.2025 14:35)
- По слухам, сама архитектура и ассемблер AVR изначально
разрабатывались "под Си", в тесной кооперации с
копмиляторостроителями. Отсюда такой результирующий эффект. - vpv.vpv(27.02.2025 08:57)
- AVR особый зверь, там вроде бы IAR действительно попотел, чтобы
получался хороший код по сравнению с другими. RISC-V хорошо
поддерживается GCC и прочими, я бы не ожидал там увидеть какое-то
значительное преимущество у IAR. В качестве ещё одного примера могу
привести IAR для STM8, там код получается такой же хреновый, как и
у всех остальных :-) - SciFi(26.02.2025 14:30)
- А когда это attribute в двойных скобках из GCC стали стандартом?
Авторы стандартов С/С++ так и не сподобились стандартизовать
расширения необходимые для embedded программирования. В результате
что GCC, что IAR решают одинаковые проблемы каждый своим способом,
и все эти способы одинаково не стандартные. Лично для меня
преимущества IAR это наличие вменяемой документации и DLIB -
аккуратно обезжиренная плюсовая библиотека. - ЫЫyкпy(26.02.2025 19:31)
- А ещё RISC-V это когда под каждый чип (в лучшем случае под каждого
вендора) свой компилятор. Тут только GCC, никогда IAR не будет
поддерживать весь этот зоопарк. - VladislavS.(26.02.2025 14:42)
