SMS

Hello, Serge! You wrote to Dima Orlov on Tue, 20 Jan 2004 00:49:00 +0300:

SB> Пусть (это достаточно стандартно) устанавливаемые цифры у нас SB> перебираются кнопками Up/Dn, кнопка Ok прыгает между цифрами, кнопка SB> Esc - выход. Тогда для состояния формы ввода кнопки Up/Dn/Ok будут SB> отрабатываться как переход на то же самое состояние с функциями SB> выхода из состояния, меняющими содержимое соответствующих SB> переменных. После повторного входа в состояние новые значения SB> автоматически отбразятся, об этом не надо думать. Кнопка Esc SB> единственная указывает на другое состояние.

Поскипано. Сергей, по опыту - уже двухуровневое меню в двухстрочной ЖКИ-амбразуре _невероятно_ неудобно. Добраться до нужного места, установить нужные IP адреса и корректно выйти обратно... жалко мне пользователей, я-то через инженерную консоль всё это проделываю :-)). Далее. Описываемый тобой механизм сводится к спин-боксам двух типов - с непосредственным числовым значением при установленных ограничениях (считаем только от 0 до 59) и с косвенной выборкой (выбор перебором одной из мнемоник). "Форма" сводится к комментарию (напомнить пользователю где и что мы сейчас делаем) и описанию входящих в неё спинбоксов - какую ячейку памяти они должны использовать; какие ограничения/где лежит массив мнемоник; ширины полей. Т.е. множества функций для такой простой задачи писать не нужно. Всё значительно усложнится, если потребуется верификация [совместимости] вводимых значений на лету и/или появятся связи между значениями, например, при выборе в поле "Месяц" придётся менять границы для поля "Число" и, возможно, корректировать его (сбрасывать с 31 до 30). Подобные проверки, нерегулярности и взаимозависимости довольно тяжело вылавливаются и без машины состояний, тут вопрос совсем не в механизме описания.

With best regards, Alexander Derazhne.

MP>> 8751H я не видел ни одного коммерческого проэкта, написанного на MP>> чем либо, отличным от АСМА!

AM> Разве была какая-то обязательная регистрация всех коммерческих AM> проектов, и этим непостредственно занимался ты?

MP> Hет, просто программистов тогда нативных было побольше.

Из этого не следует, что не существовало коммерческих проектов на ЯВУ, поксольку сами компиляторы уже существовали. Тот же PL/M был выпущен Интелом практически сразу с выпуском процессора, ну может чуть позже. Сейчас перевес в сторону ЯВУ еще более выражен.

MP>> А компиляторов всю жизнь как грязи было для всего. AM> Вот если бы их не было, тогда было бы очевидно, что на них никто не AM> пишет. Я же в течение нескольких лет довольно неплохо писал на PL/M-51

MP> Тогда зачем си. Может сразу интерпретатор явы на пик портируем?

Не бросайся в крайности. Си на данный момент - наиболее оптимальный выбор по потере производительности / дополнительному оверхеду по сравнению с асмом.

MP> (к тому-же он есть в исходниках). Вон пионеры уже MP> сделали васик для пика.

Ну и что?

SB>> Си налагает жесткие ограничения на типы используемых данных. Что SB>> далеко ходить: даже элементарно строку переменной длины в структуру SB>> не запихать.

AM> А в ассемблере это можно сделать?

SB> Разумеется. Десятками способов, из которых надо выбрать наиболее подходящий для SB> данной задачи.

SB> Самое тривиальное, конечно,

SB> MyStruct: .db 1,2,3,4,5,"вышел зайчик погулять",0

Инициализированне на этапе компиляции строки особого интереса не представляют.

Но тем не менее struct { char v1; char v2; char *str; } my_st = {1,2, "12345"};

Чем оно хуже? Будет лишь использоваться доп.память под указатель.

SB> Hо бывает удобно использовать оффсеты на каждый элемент в начале структуры.

Поясни, что ты понимаешь под оффсетами? Дай кусок кода.

SB> Или длину элементов. Или код его типа... в общем - что удобнее в конкретном случае.

Ничего не понял.

SB> Это _не_ будет структурами в Сишном понимании. Hу и что?..

SB> Конечно, все это в принципе пишется на Си. И конечно, никто так на Си не пишет. SB> Совершенно очевидно, будет написано:

SB> MyStruct: .db 1,2,3,4,5,MyText SB> MyText: .db "вышел зайчик погулять",0

SB> И наплевать, что уже потеряли на лишнем указателе (кстати, в данном примере еще SB> и на выравнивании).

Наличие выравнивания зависит от целевого процессора и типа элемента массива. При типе char, как в примере, выравнивания скорее всего вообще не будет.

SB> Самое противное начнется, когда эта структура будет часто SB> использоваться, и при обращении к тексту сначала будет устанавливаться SB> указатель на структуру, браться указатель на текст, пушиться, перегружаться, SB> пуллиться обратно.

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

SB> В частности, мне крайне неприятно делать на Си любой форматированный вывод. SB> Хорошо, когда printf() есть (да и тот, как известно, монстр еще тот). А вот SB> когда printf нету...

А на асме вывод уже встроен, что ли?

И будет выдана ошибка компиляции в лучшем случае, или не выдана - в худешем. На использование адреса в инструкции .db

Тщательнее надо.

Тогда он пишется в течении часа с нужными именно тебе фичами.

Аркадий

ЗЫ В гости бы приезжал :(

20-Jan-04 00:25 Serge Bryxin wrote to Andy Mozzhevilov:

SB>>> Си налагает жесткие ограничения на типы используемых данных. Что SB>>> далеко ходить: даже элементарно строку переменной длины в структуру SB>>> не запихать.

AM>> А в ассемблере это можно сделать?

SB> Самое тривиальное, конечно, SB> MyStruct: .db 1,2,3,4,5,"вышел зайчик погулять",0

"вы будете смеяться" :-))))))

typedef struct _MyStruct_ { unsigned char a, b, c, d, e; char s[]; // именно так, пустые скобки! } MyStruct;

// в некоторых реализациях надо|можно s[0] или s[1] // что для переносимости можно решить при помощи // #define INCOMPLETE_ARRAY // char s[INCOMPLETE_ARRAY] // заодно прозрачнее код будет. в WIN32 API таких структур // с TYPE NAME[1]; в конце -- просто изобилие, вот хотя бы // typedef struct tagBITMAPINFO { // BITMAPINFOHEADER bmiHeader; // RGBQUAD bmiColors[1]; // } BITMAPINFO, // и этих _структур_ RGBQUAD в конце BITMAPINFO может быть до 256

MyStruct my_struct1 = { 1, 2, 3, 4, 5, "a hear go for a walk" };

void foo(char *str);

void foo1(void) { foo( my_struct1.s); }

.global my_struct1 .data .type my_struct1, @object .size my_struct1, 5 my_struct1: .byte 1 .byte 2 .byte 3 .byte 4 .byte 5 .string "a hear go for a walk" .text .global foo1 .type foo1, @function foo1: ldi r24,lo8(my_struct1+5) ldi r25,hi8(my_struct1+5) call foo ret

Segment: _DATA DWORD USE32 0000001A bytes

0000 _my_struct1: 0000 01 02 03 04 05 61 20 68 65 61 72 20 67 6F 20 66 .....a hear go f 0010 6F 72 20 61 20 77 61 6C 6B 00 or a walk.

Segment: _TEXT PARA USE32 0000000A bytes

0000 foo1_: 0000 B8 05 00 00 00 mov eax,offset _my_struct1+0x5 0005 E9 00 00 00 00 jmp foo_

_DATA segment dword public use32 'DATA' _my_struct1 label byte db 1 db 2 db 3 db 4 db 5 db 97 db 32 ; покоцано кучу одиночных db db 108 db 107 db 0 _DATA ends _TEXT segment dword public use32 'CODE' align 4 _foo1 proc near push offset _my_struct1+5 call _foo pop ecx ret _foo1 endp

Впрочем, Keil/C51 6.20 и IAR/AVR 1.40 отказались это кушать (как и Borland C++/DOS 3.0), чему я лично сейчас был очень удивлён. Я это знаю очень давно (но практически не пользуюсь, равно как и не пользовался при работе на асме, не так оно хорошо, как кажется). И, сейчас глянул, в C99 оно тоже не пропало:

16 As a special case, the last element of a structure with more than one named member may have an incomplete array type; this is called a flexible array member. [покоцано]

17 EXAMPLE Assuming that all array members are aligned the same, after the declarations: struct s { int n; double d[]; }; struct ss { int n; double d[1]; };

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

Menu: MenuItem1: .db 1,2,3,4,5,"вышел зайчик погулять", 0 MenuItem2: .db 5,6,7,8,9,"Посадил дед Репку. Вышел Репка и убил деда", 0

а потом для доступа к предыдущему элементу меню идти от начала меню (либо от текущего места) перебором/просмотром байтов (размер кода от этого не уменьшится, быстродействие сильно упадёт, особенно если само меню лежит в "не очень легко доступной" памяти типа code у mcs51 или вообще во внешней последовательной).

либо завести ещё MenuIndex: .dw MenuItem1 .dw MenuItem2 Так не проще ли завести сразу в структуре указатель на строку, что будет по объёму, занятому меню, равно варианту с MenuIndex, и не будет уступать ему по скорости?

SB> Hо бывает удобно использовать оффсеты на каждый элемент в начале структуры. Ничем не проще, чем указатели. Слегка меньше по объёму самих структур, но в зависимости от архитектуры может увеличить объём кода.

SB> Конечно, все это в принципе пишется на Си. И конечно, никто так на Си не SB> пишет. Совершенно очевидно, будет написано:

SB> MyStruct: .db 1,2,3,4,5,MyText SB> MyText: .db "вышел зайчик погулять",0 Причём все строки при этом нормальный компилятор поместит в отдельную секцию .string (имя по вкусу) и на них проблем с выравниванеим не будет.

SB> Самое противное начнется, когда эта структура будет часто SB> использоваться, и при обращении к тексту сначала будет устанавливаться SB> указатель на структуру, браться указатель на текст, Там немного выше была одна строка, я её поближе скопирую: SB> Hо бывает удобно использовать оффсеты на каждый элемент в начале структуры.

оффсет, суммироваться с указателем, а на 8-битной архитектуре ещё и не одной операцией, а если в архитектуре напряг с регистрами и/или с операциям с ними, то

тоже придётся. Но зато будет _вера_, что это всё жутко эффективно, так как на асме.

wbr,

Hello, Serge Bryxin !

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

С уважением, Дима Орлов.

Hi Dima, hope you are having a nice day!

20 Янв 04, Dima Orlov wrote to Serge Bryxin:

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

Я делал такое. Идея похожая. При входе в процедуру ввода передается константа-тип числа. Формат числа описывается в структуре. Структуры собраны в массив, индексом собственно является тип вводимого числа.

const rom struct num_type num_types[] = { {NUM_TYPE_DOUBLE, -999.999, 9999.999, 1000, 1, 3}, // NUM_TYPE_DBL43 {NUM_TYPE_DOUBLE, -99.9999, 999.9999, 10000, 1, 4}, // NUM_TYPE_DBL34 {NUM_TYPE_DOUBLE, -99.9, 99.9, 10, 4, 1}, // NUM_TYPE_DBL31 {NUM_TYPE_UDOUBLE, 0.1000, 1.1000, 10000, 3, 4}, // NUM_TYPE_DBL14U {NUM_TYPE_UDOUBLE, 0.000, 0.999, 1000, 4, 3}, // NUM_TYPE_DBL13U {NUM_TYPE_UDOUBLE, 0.000, 9999.999, 1000, 1, 3}, // NUM_TYPE_DBL43U {NUM_TYPE_UDOUBLE, 10.0, 100.0, 10, 4, 1}, // NUM_TYPE_DBL31U {NUM_TYPE_UDOUBLE, 0.0, 100.0, 10, 4, 1}, // NUM_TYPE_MANPWR {NUM_TYPE_WORD, 0, 9999, 1, 4, 0}, // NUM_TYPE_PWD {NUM_TYPE_WORD, 50, 60000, 0.02, 4, 0}, // NUM_TYPE_PPRD {NUM_TYPE_BYTE, 0, 250, 0.2, 6, 1}, // NUM_TYPE_DLY1 {NUM_TYPE_BYTE, 25, 250, 0.2, 6, 1}, // NUM_TYPE_DLY2 {NUM_TYPE_BYTE, 5, 250, 0.2, 6, 1}, // NUM_TYPE_RFRSH {NUM_TYPE_BYTE, 0, 20, 1, 6, 0} // NUM_TYPE_REGN };

В структуре описывается число знаков в числе, число знаков после запятой, тип возвращаемого значения (double, short, и т.п.), допустимый диапазон значений. Мне не требовалось делать зависимость от других значений, но это не сложно: достаточно добавить в структуру укзатели на соответствующие границы

А это собственно декларация функции. Указатель передается нетипизированным, и уже внутри функции приводится к нужному типу. Через этот же указатель возвращается результат, код ошибки (status) - возвращаемое значение.

unsigned char ioWriteNumber(void *arg, unsigned char type);

WBR, AVB

ICQ# 43835774 mailto: avb<at>dialup.etr.ru