Самый низкоуровневый язык, ага - Компьютерные священные войны

Здравствуйте, Евгений Музыченко, Вы писали:

vsb>>не хватает аналога async/await в С. Чтобы я мог записать алгоритм в простом виде, а компилятор из этого сварганил машину состояний и оно бы работало параллельно с другими такими же машинами состояний.

ЕМ>Такое может неплохо работать на мощных процессорах, когда запас по быстродействию большой. На МК это рискует тормозить, причем непредсказуемо.

Автоматы нормально работают и на МК, и никаких особенных требований по быстродействию не требуют. Не вижу, почему бы автомат, сгенерированный компилятором, был бы сильно хуже

ЕМ>А есть реализации Rust под требуемые МК?

Хз, у меня коллега по эмбеду дрочил на раст, но вроде ничего не приносил. Если бы нашел, то уверен, что попробовал бы это нам продать. Но это было несколько лет назад

Здравствуйте, vsb, Вы писали:

vsb>это блокирующий алгоритм. Если хочется его делать не в блокирующем режиме, то этот алгоритм переводится в машину состояний вроде

vsb>

vsb>void process_events() {
vsb>  switch (state) {
vsb>    case WAIT_FOR_TBE:
vsb>      if (TBE != 0) state = TRANSMIT_BYTE;
vsb>      break;
vsb>    case TRANSMIT_BYTE:
vsb>      TRANSMIT_DATA := transmit_data[i];
vsb>      state = WAIT_FOR_RBNE;
vsb>      break;
vsb>    case WAIT_FOR_RBNE:
vsb>      if (RBNE != 0) state = RECEIVE_BYTE;
vsb>      break;
vsb>    case RECEIVE_BYTE:
vsb>      receive_data[i] := RECEIVE_DATA;
vsb>      state = NEXT_ITERATION;
vsb>      break;
vsb>    case NEXT_ITERATION:
vsb>      i++;
vsb>      if (i < length) {
vsb>        state = WAIT_FOR_TBE;
vsb>      } else {
vsb>        state = END;
vsb>      }
vsb>      break;
vsb>  }   
vsb>}
vsb>

vsb>Как видно, блокирующий алгоритм переделали в неблокирующий, теперь надо только достаточно часто вызывать process_events();

vsb>но переделка абсолютно механическая и по этому алгоритму работают многие языки, реализуя async/await под капотом именно в таком виде.

vsb>Т.е. можно было бы взять начальный код

vsb>

vsb>for (size_t i = 0; i < length; i++) {
vsb>  while (TBE == 0) yield; // ждем пока не включится флаг TRANSMIT_BUFFER_EMPTY
vsb>  TRANSMIT_DATA := transmit_data[i] // записываем первый байт
vsb>  while (RBNE == 0) yield; // ждём пока не включится флаг RECEIVE_BUFFER_NOT_EMPTY
vsb>  receive_data[i] := RECEIVE_DATA;
vsb>}
vsb>

vsb>И по yield разбить функцию на куски и каждый кусок оформить в виде куска в switch машины состояний. Ну тут нет вызовов других функций, в общем случае всё: конечно, может быть похитрей, но суть та же.

vsb>Понятно, что можно вкорячить туда какой-нибудь FreeRTOS и запускать такие алгоритмы, как полновесные процессы, но это кажется ненужным усложнением.

Не надо вкорячивать никаких ОС, это как есть PROTOTHREADS, там один файл и пяток макросов, состояния делаются автоматом на базе __COUNTER или как его, как раз то, что тебе нужно

Да, стека там нет, PROTOTHREADS хранит данные в структуре. Я на них делал здоровые автоматы строк по паре тысяч для разных роботов, никаких проблем с вызовом функций, только переменные не завести

Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ>Вообще, любой конечный автомат естественным образом ложится на объект (в предельном случае — структуру), где хранится состояние, и набор методов/функций вокруг него.

ЕМ>Если хотите, чтоб код оставался линейным, и паузы по вызову yield делались внутри функции, то не обойтись без переключения (или копирования/восстановления) стека. Для этого нужно знать, как реализация языка работает со стеком. Тут без ассемблерной обвязки вряд ли можно обойтись.

Не надо никаких переключений. PROTOTHREADS нормально делает без всякого переключения. Только структура с состоянием данного прототреда, как ты любишь

Здравствуйте, Marty, Вы писали:

M>Храни как поля структуры.

Я в таких случаях делаю объект.

M>Есть куча встраиваемых ОС, зачем писать ещё одну?

Полноценную ОС — разумеется, незачем. А просто диспетчер обработки событий часто проще сделать свой. Он всегда полностью понятен, управляем, в нем не бывает глюков, которых не понять без хорошего знания потрохов, его можно подстраивать под себя, а не подстраиваться под него, у него нет проблем с лицензированием и т.п.

Собственно, все это справедливо для любого вспомогательного кода до некоторого уровня сложности. После этого уровня уже выгоднее применять сторонние решения.

Здравствуйте, Marty, Вы писали:

M>почему бы автомат, сгенерированный компилятором, был бы сильно хуже

Мне трудно представить ситуацию, в которой автомат, сделанный компилятором, в то же самое время и заметно облегчил бы жизнь, и не оказался чрезмерно раздутым в реализации.

Если есть линейный алгоритм с ожиданиями, где количество состояний в районе десятка, то он примерно одинаково понятен и в линейном виде, и в виде единого switch, и в виде набора обработчиков, которые вызывает диспетчер событий. Если же состояний значительно больше, то в графе определенно должны быть явные узлы, которые нужно выделять в отдельные сущности и как-то изолировать.

Здравствуйте, Евгений Музыченко, Вы писали:

M>>почему бы автомат, сгенерированный компилятором, был бы сильно хуже

ЕМ>Мне трудно представить ситуацию, в которой автомат, сделанный компилятором, в то же самое время и заметно облегчил бы жизнь, и не оказался чрезмерно раздутым в реализации.

То есть ты до сих пор пишешь на асме, потому что код, сгенерированный компилятором не облегчает заметно жизнь, но чрезвычайно раздут?

ЕМ>Если есть линейный алгоритм с ожиданиями, где количество состояний в районе десятка, то он примерно одинаково понятен и в линейном виде, и в виде единого switch, и в виде набора обработчиков, которые вызывает диспетчер событий.

Диспечер событий какой-то городить. Зачем?

ЕМ>Если же состояний значительно больше, то в графе определенно должны быть явные узлы, которые нужно выделять в отдельные сущности и как-то изолировать.

Компутер умеет оптимизировать автоматы гораздо лучше человеков

Здравствуйте, Marty, Вы писали:

M>То есть ты до сих пор пишешь на асме, потому что код, сгенерированный компилятором не облегчает заметно жизнь, но чрезвычайно раздут?

Я не пишу на асме потому, что C/C++ качественно облегчает жизнь, но сгенерированный код при этом получается лишь незначительно больше, если его контролировать. Если не контролировать, а тупо применять рекомендуемые решения, то получается обычно в разы больше.

M>Диспечер событий какой-то городить. Зачем?

Чтоб код не выглядел так убого, как написанный для ProtoThreads.

M>Компутер умеет оптимизировать автоматы гораздо лучше человеков

Специализированный софт для построения автоматов — умеет. А что знает об автоматах компилятор C?

Здравствуйте, Евгений Музыченко, Вы писали:

M>>То есть ты до сих пор пишешь на асме, потому что код, сгенерированный компилятором не облегчает заметно жизнь, но чрезвычайно раздут?

ЕМ>Я не пишу на асме потому, что C/C++ качественно облегчает жизнь, но сгенерированный код при этом получается лишь незначительно больше, если его контролировать. Если не контролировать, а тупо применять рекомендуемые решения, то получается обычно в разы больше.

Почему ты думаешь, что с автоматами будет по другому?

И, кстати, а что такое — в разы больше?

Я вот, как-то забил что-то контролировать, у меня экзешник — полтора метра (x64, x86 — 1.2), всё сторонее канпеляется в него, никаких кути в отдельных DLL и тп — нет. Меня полтора метра вполне устраивают, ничего улучшать не тянет.
У меня там рисовалка на GDI/GDI+, парсер json и вирт машина сквирела, это из значимого. Мелочи даже не считаю. И да, плюсики использую в полный рост, не парюсь, что код будет пухнуть от шаблонов

M>>Диспечер событий какой-то городить. Зачем?

ЕМ>Чтоб код не выглядел так убого, как написанный для ProtoThreads.

С ProtoThreads код нормально выглядит. А вот твой диспечер, скорее всего, будет убог и коряв, и с кучей багов.

Можно пример твоего супер диспечера, чтобы он такое бы делал?

M>>Компутер умеет оптимизировать автоматы гораздо лучше человеков

ЕМ>Специализированный софт для построения автоматов — умеет. А что знает об автоматах компилятор C?

А в нем и async/await нету. Это раз. А во вторых, я думаю, даже компилятор C знает об автоматах на порядок больше тебя

Здравствуйте, Marty, Вы писали:

M>Почему ты думаешь, что с автоматами будет по другому?

Я уже объяснил пару раз, почему автомат, сгенерированный компилятором по линейному коду, будет либо примерно того же уровня сложности/управляемости, что и ручной, либо будет иметь изрядное количество обслуживающего кода, от которого невозможно ни избавиться, ни толком вмешаться в его работу.

M>И, кстати, а что такое — в разы больше?

Это вдвое, втрое, впятеро и т.п. по сравнению с тем же алгоритмом, реализованным на ассемблере.

M>Меня полтора метра вполне устраивают, ничего улучшать не тянет.

А кого-то устраивает и полтора гига, и тоже не тянет ничего улучшать. Вопрос-то не в абсолютной потребности в ресурсах, а относительно объективных параметров решаемой задачи.

M>У меня там рисовалка на GDI/GDI+, парсер json и вирт машина сквирела, это из значимого

Если из значимого это все, то полтора метра — ну очень много.

M>С ProtoThreads код нормально выглядит.

По сравнению с ассемблерным — безусловно.

M>А вот твой диспечер, скорее всего, будет убог и коряв, и с кучей багов.

Почему "скорее всего"?

M>Можно пример твоего супер диспечера, чтобы он такое бы делал?

Во-первых, он не "супер" — это совершенно заурядное решение, мне даже как-то странно, что Вы по этому поводу так возбудились. Во-вторых, я последний раз делал сколько-нибудь универсальную реализацию под DOS, исходники не факт, что сохранились, не вижу смысла их искать, ибо то был ни разу не rocket science.

M>думаю, даже компилятор C знает об автоматах на порядок больше тебя

Из каких соображений Вы так думаете, и что именно он знает?

Здравствуйте, vdimas, Вы писали:

V>>>Если пользуешь Си, то для оперирования объявленными статическими данными (структурами, массивами) необходим CRT.
M>>Что именно из CRT нужно для этого?

V>Двухфазная инициализация глобальных данных.
V>Причём, при внешнем загрузчике CRT обыгрывает только вторую фазу (динамической инициализации), а в гарварде CRT обыгрывает обе фазы.

V>Упреждая пинг-понг вопросов-ответов:
V>

V>int a = 42;
V>int b = calcB();
V>

V>Здесь в бинарном образе в сегменте данных по адресу a будет число 42, по адресу b будет 0.

V>Внешний загрузчик грузит образ в память, переменная a уже инициализирована (это первая фаза), а переменная b будет инициализирована из глобального связанного списка инициализации, где каждый узел примерно такого вида:
V>

V>struct __init_module {
V>  void (*fn)(void);
V>  __init_module * next; 
V>};
V>

V>CRT пробегается по этому списку, вызывая код динамической инициализации — это вторая фаза стандартной инициализации С/С++.

V>Для инициализации модуля, содержащего динамическую инициализацию (здесь глобальной переменной b), будет порождена безымянная ф-ия примерно такого вида:
V>

V>void __some_init_xxx() {
V>  b = calcB();
V>}
V>

V>Указатель на эту ф-ию будет в одном из узлов __init_module в глобальном списке динамической инициализации.

V>Для микриков обычно нет связанного списка, динамическая инициализация представляет собой развернутый (типа заинлайненный) код, но это всё-равно лишний код, который почти всегда не нужен, т.к. любые начальные данные или не нужны, или являются константами, тогда им не место в ОЗУ.

Честно говоря я ничего не понял. Можно пример минимальной компилируемой программы? Глобальные переменные нельзя инициализировать чем-либо кроме констант. Константы идут в .data и всё, без всяких init.

int calcB();

int a = 42;
int b = calcB();

Этот код не компилируется: error: initializer element is not constant

Здравствуйте, vsb, Вы писали:

vsb>Этот код не компилируется: error: initializer element is not constant

В чистом C такого нельзя. В C++ можно.

Здравствуйте, Евгений Музыченко, Вы писали:

vsb>>Этот код не компилируется: error: initializer element is not constant

ЕМ>В чистом C такого нельзя. В C++ можно.

А для чего-то ещё может понадобиться инициализация? Просто у меня в объектном файле откуда-то затесались пустые функции _init и _fini, при том, что libc вроде не линкуется, я и пытаюсь сообразить — что это и зачем. На С.

Здравствуйте, vsb, Вы писали:

vsb>А для чего-то ещё может понадобиться инициализация?

В C++ — для статических объектов, имеющих конструкторы.

vsb>в объектном файле откуда-то затесались пустые функции _init и _fini

В объектном коде есть их вызовы? Они попадают в конечный бинарник? Если да, кто их там вызывает?

Здравствуйте, Евгений Музыченко, Вы писали:

vsb>>в объектном файле откуда-то затесались пустые функции _init и _fini

ЕМ>В объектном коде есть их вызовы? Они попадают в конечный бинарник? Если да, кто их там вызывает?

Нет, вызовов нет. В конечный бинарник попадают, вызовов там нет. Программа почти минимальная (без оптимизации).

arm-none-eabi-objdump -d build/gd32e103_ads1298r.elf

build/gd32e103_ads1298r.elf:     file format elf32-littlearm


Disassembly of section .text:

08000150 <halt>:
 8000150:    e52db004     push    {fp}        @ (str fp, [sp, #-4]!)
 8000154:    e28db000     add    fp, sp, #0
 8000158:    e24dd00c     sub    sp, sp, #12
 800015c:    e1a03000     mov    r3, r0
 8000160:    e54b3005     strb    r3, [fp, #-5]
 8000164:    e59f3014     ldr    r3, [pc, #20]    @ 8000180 <halt+0x30>
 8000168:    e5d33000     ldrb    r3, [r3]
 800016c:    e59f200c     ldr    r2, [pc, #12]    @ 8000180 <halt+0x30>
 8000170:    e55b3005     ldrb    r3, [fp, #-5]
 8000174:    e5c23000     strb    r3, [r2]
 8000178:    e1a00000     nop            @ (mov r0, r0)
 800017c:    eafffffd     b    8000178 <halt+0x28>
 8000180:    20000000     .word    0x20000000

08000184 <start>:
 8000184:    e52db004     push    {fp}        @ (str fp, [sp, #-4]!)
 8000188:    e28db000     add    fp, sp, #0
 800018c:    e1a00000     nop            @ (mov r0, r0)
 8000190:    e28bd000     add    sp, fp, #0
 8000194:    e49db004     pop    {fp}        @ (ldr fp, [sp], #4)
 8000198:    e12fff1e     bx    lr

0800019c <foo>:
 800019c:    e52db004     push    {fp}        @ (str fp, [sp, #-4]!)
 80001a0:    e28db000     add    fp, sp, #0
 80001a4:    e59f3014     ldr    r3, [pc, #20]    @ 80001c0 <foo+0x24>
 80001a8:    e3a02001     mov    r2, #1
 80001ac:    e5832000     str    r2, [r3]
 80001b0:    e1a00000     nop            @ (mov r0, r0)
 80001b4:    e28bd000     add    sp, fp, #0
 80001b8:    e49db004     pop    {fp}        @ (ldr fp, [sp], #4)
 80001bc:    e12fff1e     bx    lr
 80001c0:    20000004     .word    0x20000004

080001c4 <clocks_init>:
 80001c4:    e52db004     push    {fp}        @ (str fp, [sp, #-4]!)
 80001c8:    e28db000     add    fp, sp, #0
 80001cc:    e1a00000     nop            @ (mov r0, r0)
 80001d0:    e28bd000     add    sp, fp, #0
 80001d4:    e49db004     pop    {fp}        @ (ldr fp, [sp], #4)
 80001d8:    e12fff1e     bx    lr

080001dc <reset_handler>:
 80001dc:    e92d4800     push    {fp, lr}
 80001e0:    e28db004     add    fp, sp, #4
 80001e4:    e24dd018     sub    sp, sp, #24
 80001e8:    ebfffff5     bl    80001c4 <clocks_init>
 80001ec:    e59f3090     ldr    r3, [pc, #144]    @ 8000284 <reset_handler+0xa8>
 80001f0:    e50b3008     str    r3, [fp, #-8]
 80001f4:    e59f308c     ldr    r3, [pc, #140]    @ 8000288 <reset_handler+0xac>
 80001f8:    e50b3014     str    r3, [fp, #-20]    @ 0xffffffec
 80001fc:    ea000004     b    8000214 <reset_handler+0x38>
 8000200:    e51b3008     ldr    r3, [fp, #-8]
 8000204:    e2832004     add    r2, r3, #4
 8000208:    e50b2008     str    r2, [fp, #-8]
 800020c:    e3a02000     mov    r2, #0
 8000210:    e5832000     str    r2, [r3]
 8000214:    e51b2008     ldr    r2, [fp, #-8]
 8000218:    e51b3014     ldr    r3, [fp, #-20]    @ 0xffffffec
 800021c:    e1520003     cmp    r2, r3
 8000220:    3afffff6     bcc    8000200 <reset_handler+0x24>
 8000224:    e59f3060     ldr    r3, [pc, #96]    @ 800028c <reset_handler+0xb0>
 8000228:    e50b300c     str    r3, [fp, #-12]
 800022c:    e59f305c     ldr    r3, [pc, #92]    @ 8000290 <reset_handler+0xb4>
 8000230:    e50b3010     str    r3, [fp, #-16]
 8000234:    e59f3058     ldr    r3, [pc, #88]    @ 8000294 <reset_handler+0xb8>
 8000238:    e50b3018     str    r3, [fp, #-24]    @ 0xffffffe8
 800023c:    ea000007     b    8000260 <reset_handler+0x84>
 8000240:    e51b200c     ldr    r2, [fp, #-12]
 8000244:    e2823004     add    r3, r2, #4
 8000248:    e50b300c     str    r3, [fp, #-12]
 800024c:    e51b3010     ldr    r3, [fp, #-16]
 8000250:    e2831004     add    r1, r3, #4
 8000254:    e50b1010     str    r1, [fp, #-16]
 8000258:    e5922000     ldr    r2, [r2]
 800025c:    e5832000     str    r2, [r3]
 8000260:    e51b2010     ldr    r2, [fp, #-16]
 8000264:    e51b3018     ldr    r3, [fp, #-24]    @ 0xffffffe8
 8000268:    e1520003     cmp    r2, r3
 800026c:    3afffff3     bcc    8000240 <reset_handler+0x64>
 8000270:    ebffffc3     bl    8000184 <start>
 8000274:    e1a00000     nop            @ (mov r0, r0)
 8000278:    e24bd004     sub    sp, fp, #4
 800027c:    e8bd4800     pop    {fp, lr}
 8000280:    e12fff1e     bx    lr
 8000284:    20000000     .word    0x20000000
 8000288:    20000008     .word    0x20000008
 800028c:    08000350     .word    0x08000350
 8000290:    20000008     .word    0x20000008
 8000294:    20000008     .word    0x20000008

08000298 <nmi_handler>:
 8000298:    e92d4800     push    {fp, lr}
 800029c:    e28db004     add    fp, sp, #4
 80002a0:    e3a00002     mov    r0, #2
 80002a4:    ebffffa9     bl    8000150 <halt>
 80002a8:    e1a00000     nop            @ (mov r0, r0)
 80002ac:    e24bd004     sub    sp, fp, #4
 80002b0:    e8bd4800     pop    {fp, lr}
 80002b4:    e12fff1e     bx    lr

080002b8 <hard_fault_handler>:
 80002b8:    e92d4800     push    {fp, lr}
 80002bc:    e28db004     add    fp, sp, #4
 80002c0:    e3a00003     mov    r0, #3
 80002c4:    ebffffa1     bl    8000150 <halt>
 80002c8:    e1a00000     nop            @ (mov r0, r0)
 80002cc:    e24bd004     sub    sp, fp, #4
 80002d0:    e8bd4800     pop    {fp, lr}
 80002d4:    e12fff1e     bx    lr

080002d8 <mem_manage_handler>:
 80002d8:    e92d4800     push    {fp, lr}
 80002dc:    e28db004     add    fp, sp, #4
 80002e0:    e3a00004     mov    r0, #4
 80002e4:    ebffff99     bl    8000150 <halt>
 80002e8:    e1a00000     nop            @ (mov r0, r0)
 80002ec:    e24bd004     sub    sp, fp, #4
 80002f0:    e8bd4800     pop    {fp, lr}
 80002f4:    e12fff1e     bx    lr

080002f8 <bus_fault_handler>:
 80002f8:    e92d4800     push    {fp, lr}
 80002fc:    e28db004     add    fp, sp, #4
 8000300:    e3a00005     mov    r0, #5
 8000304:    ebffff91     bl    8000150 <halt>
 8000308:    e1a00000     nop            @ (mov r0, r0)
 800030c:    e24bd004     sub    sp, fp, #4
 8000310:    e8bd4800     pop    {fp, lr}
 8000314:    e12fff1e     bx    lr

08000318 <usage_fault_handler>:
 8000318:    e92d4800     push    {fp, lr}
 800031c:    e28db004     add    fp, sp, #4
 8000320:    e3a00006     mov    r0, #6
 8000324:    ebffff89     bl    8000150 <halt>
 8000328:    e1a00000     nop            @ (mov r0, r0)
 800032c:    e24bd004     sub    sp, fp, #4
 8000330:    e8bd4800     pop    {fp, lr}
 8000334:    e12fff1e     bx    lr

08000338 <_init>:
 8000338:    e1a0c00d     mov    ip, sp
 800033c:    e92ddff8     push    {r3, r4, r5, r6, r7, r8, r9, sl, fp, ip, lr, pc}
 8000340:    e24cb004     sub    fp, ip, #4

08000344 <_fini>:
 8000344:    e1a0c00d     mov    ip, sp
 8000348:    e92ddff8     push    {r3, r4, r5, r6, r7, r8, r9, sl, fp, ip, lr, pc}
 800034c:    e24cb004     sub    fp, ip, #4

От:	Marty	https://www.youtube.com/channel/UChp5PpQ6T4-93HbNF-8vSYg
Дата:	02.10.23 15:26
Оценка:

От:	Marty	https://www.youtube.com/channel/UChp5PpQ6T4-93HbNF-8vSYg
Дата:	02.10.23 15:30
Оценка:

От:	Marty	https://www.youtube.com/channel/UChp5PpQ6T4-93HbNF-8vSYg
Дата:	02.10.23 15:36
Оценка:	1 (1)

От:	Marty	https://www.youtube.com/channel/UChp5PpQ6T4-93HbNF-8vSYg
Дата:	02.10.23 15:39
Оценка:

От:	Евгений Музыченко	https://software.muzychenko.net/ru
Дата:	02.10.23 16:13
Оценка:

	От:	vsb
	Дата:	07.10.23 14:02
	Оценка:

	От:	vsb
	Дата:	07.10.23 14:16
	Оценка:

	От:	vsb
	Дата:	07.10.23 14:23
	Оценка:

	От:	vsb
	Дата:	07.10.23 14:42
	Оценка: