SB> HÉ Ó ËÁËÉÍÉ ÄÒÕÇÉÍÉ ÓÕÝÎÏÓÔÑÍÉ ÐÒÏÇÒÁÍÍÁ ÄÅÌÁ ÎÅ ÉÍÅÅÔ.
÷ÒÅÍÑ. íÅÌËÁÑ ÔÁËÁÑ ÓÕÝÎÏÓÔØ...
SB> úÁÄÁÞÁ ÏÒÇÁÎÉÚÁÃÉÉ ÄÁÎÎÙÈ É ×ÙÂÏÒÁ ÉÈ ÐÒÅÄÓÔÁ×ÌÅÎÉÑ ÄÌÑ ÈÒÁÎÅÎÉÑ É ÄÌÑ SB> ××ÏÄÁ/×Ù×ÏÄÁ - ËÌÀÞÅ×ÏÊ ×ÏÐÒÏÓ ÌÀÂÏÇÏ ÐÒÏÅËÔÁ.
òÁÓÓËÁÖÉ, ËÁË "ÚÁÄÁÞÁ ÏÒÇÁÎÉÚÁÃÉÉ ÄÁÎÎÙÈ É ×ÙÂÏÒÁ ÉÈ ÐÒÅÄÓÔÁ×ÌÅÎÉÑ ÄÌÑ ÈÒÁÎÅÎÉÑ" Ñ×ÌÑÅÔÓÑ ËÌÀÞÅ×ÙÍ ×ÏÐÒÏÓÏÍ ÐÒÉ ÓÔÁÂÉÌÉÚÁÃÉÉ ÓËÏÒÏÓÔÉ ÄÉÚÅÌÑ, Á Ñ Ó ÉÎÔÅÒÅÓÏÍ ÐÏÓÌÕÛÁÀ.
SB> é ÇÒÏÛ ÃÅÎÁ ÌÀÂÏÊ ÏÐÔÉÍÉÚÁÃÉÉ ËÏÄÁ,
ÅÓÌÉ ÏÎÁ ÎÅ ÎÕÖÎÁ.
"We should forget about small efficiencies, about 97% of the time. Premature optimization is the root of all evil." (c) Donald Knuth
WBR, àÒÉÊ.
A
Alexander Derazhne
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.
A
Alexander Derazhne
Hello, Serge! You wrote to Andy Mozzhevilov on Tue, 20 Jan 2004 00:25:00 +0300:
MP>> 8751H я не видел ни одного коммерческого проэкта, написанного на MP>> чем либо, отличным от АСМА!
AM> Разве была какая-то обязательная регистрация всех коммерческих AM> проектов, и этим непостредственно занимался ты?
MP> Hет, просто программистов тогда нативных было побольше.
Из этого не следует, что не существовало коммерческих проектов на ЯВУ, поксольку сами компиляторы уже существовали. Тот же PL/M был выпущен Интелом практически сразу с выпуском процессора, ну может чуть позже. Сейчас перевес в сторону ЯВУ еще более выражен.
MP>> А компиляторов всю жизнь как грязи было для всего. AM> Вот если бы их не было, тогда было бы очевидно, что на них никто не AM> пишет. Я же в течение нескольких лет довольно неплохо писал на PL/M-51
MP> Тогда зачем си. Может сразу интерпретатор явы на пик портируем?
Не бросайся в крайности. Си на данный момент - наиболее оптимальный выбор по потере производительности / дополнительному оверхеду по сравнению с асмом.
MP> (к тому-же он есть в исходниках). Вон пионеры уже MP> сделали васик для пика.
Ну и что?
A
Andy Mozzhevilov
SB>> Си налагает жесткие ограничения на типы используемых данных. Что SB>> далеко ходить: даже элементарно строку переменной длины в структуру SB>> не запихать.
AM> А в ассемблере это можно сделать?
SB> Разумеется. Десятками способов, из которых надо выбрать наиболее подходящий для SB> данной задачи.
SB> И наплевать, что уже потеряли на лишнем указателе (кстати, в данном примере еще SB> и на выравнивании).
Наличие выравнивания зависит от целевого процессора и типа элемента массива. При типе char, как в примере, выравнивания скорее всего вообще не будет.
SB> Самое противное начнется, когда эта структура будет часто SB> использоваться, и при обращении к тексту сначала будет устанавливаться SB> указатель на структуру, браться указатель на текст, пушиться, перегружаться, SB> пуллиться обратно.
Одиночная структура - вообще частный случай. А вот что ты будешь делать с массивом структур, содержашей строки переменной длины на асм? Производить последовательный обход от начала?
SB> В частности, мне крайне неприятно делать на Си любой форматированный вывод. SB> Хорошо, когда printf() есть (да и тот, как известно, монстр еще тот). А вот SB> когда printf нету...
А на асме вывод уже встроен, что ли?
D
Dimmy Timchenko
Hi Ilia.
18 Jan 2004, 22:43, Ilia Tarasov writes to George Shepelev:
GS> á ÔÙ ÕÞÉÌÓÑ É ÎÁ 8080? ðÏ ÍÎÅÍÏÎÉËÁÍ ÜÔÏ ÂÙÌ ËÏÛÍÁp! :-/
И будет выдана ошибка компиляции в лучшем случае, или не выдана - в худешем. На использование адреса в инструкции .db
Тщательнее надо.
Тогда он пишется в течении часа с нужными именно тебе фичами.
Аркадий
ЗЫ В гости бы приезжал :(
O
Oleksandr Redchuk
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.
_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-битной архитектуре ещё и не одной операцией, а если в архитектуре напряг с регистрами и/или с операциям с ними, то
тоже придётся. Но зато будет _вера_, что это всё жутко эффективно, так как на асме.
SB>> é ÇÒÏÛ ÃÅÎÁ ÌÀÂÏÊ ÏÐÔÉÍÉÚÁÃÉÉ ËÏÄÁ, YK> "We should forget about small efficiencies, about 97% of the time. YK> Premature optimization is the root of all evil." (c) Donald Knuth
При разной длине и допустимом диапазоне значений, особенно если эти данные зависят от других у нас как-то очень громоздко получилось при похожей исходной идее.
С уважением, Дима Орлов.
D
Dima Orlov
Hello, Serge Bryxin !
HÉ ÔÏ É ÎÅ ÄÒÕÇÏÅ.
ðÒÏÇÒÁÍÍÁ, ÑÓÎÏÅ ÄÅÌÏ, ÏÐÅÒÉÒÕÅÔ Ó ÄÁÎÎÙÍÉ, ÐÒÉÞÅÍ ÎÅ ÐÒÏÓÔÏ Ó ÄÁÎÎÙÍÉ, Á Ó ÄÁÎÎÙÍÉ × ÒÅÁÌØÎÏÍ ×ÒÅÍÅÎÉ. á ×ÏÔ ÐÒÏÇÒÁÍÍÉÓÔ - × ÓÌÕÞÁÅ Ó embedded - Ó ÏÂßÅËÔÏÍ. úÁÄÁÞÁ ÚÁÐÉÈÉ×ÁÎÉÑ ÓÔÒÏË × ÓÔÒÕËÔÕÒÙ ÐÅÒÅÄ ÎÉÍ ÎÅ ÓÔÏÉÔ.
ó Õ×ÁÖÅÎÉÅÍ, äÉÍÁ ïÒÌÏ×.
DO> При разной длине и допустимом диапазоне значений, особенно если эти DO> данные зависят от других у нас как-то очень громоздко получилось при DO> похожей исходной идее.
Я делал такое. Идея похожая. При входе в процедуру ввода передается константа-тип числа. Формат числа описывается в структуре. Структуры собраны в массив, индексом собственно является тип вводимого числа.
В структуре описывается число знаков в числе, число знаков после запятой, тип возвращаемого значения (double, short, и т.п.), допустимый диапазон значений. Мне не требовалось делать зависимость от других значений, но это не сложно: достаточно добавить в структуру укзатели на соответствующие границы
А это собственно декларация функции. Указатель передается нетипизированным, и уже внутри функции приводится к нужному типу. Через этот же указатель возвращается результат, код ошибки (status) - возвращаемое значение.