Hу сейчас я вам урок грамотного программирования даду ;) - Page 2

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From Russian to

Threaded View
Hу сейчас я вам урок грамотного программирования даду ;)
Hello, Maxim!

31 Янв 04 05:02, Maxim Polyanskiy wrote Yuriy K:

 MP>>> Hа самом деле правильная постановка вопроса должна звучать так
 MP>>> "какие возможности есть у ЯВУ, которых нет у АСМ" ;)
 YK>> Писать работающие и сопровождаемые программы за разумное время.
 MP> Чушь. Это возможности программиста а не языка.
Hа асме хорошо изображать мелкие задачи, которые лучше реализуются в коде, чем
это сделает компилятор. Hо когда объем проекта перерастает некоторую величину,
пусть это будет килобайт 200 текста исходника, зависимо конечно от
программиста, но в целом величина определяющая, большой проект это или нет,
чтобы не пытаться его целиком реализовать на ассемблере. Hа си можно его
написать, отладить, не отвлекаясь на мелочи. Даже более того, он может быть
отлажен на просто компьютере с виртуализованной периферией, (то есть в
процедурах общения с периферией сделан симулятор реального железа). Экономия
времени на отладку, вываливание логов в файл, построчное прохождение в
отладчике, если уж совсем тупишь и не видишь в тексте ошибку реализации
алгоритма. Это менее доступно при написании проекта в родном ассемблере целевой
системы.
 Это мне напоминает одного художника, практически слепого, он видит одним
глазом только ВБЛИЗИ и поэтому рисует чуть-ли не носом. Картина получается
крайне детальна, мельчайший штрих на ней нарисован обдуманно, но поскольку он
не видит даже часть картины целиком, не говоря уж об всей сразу, то картина
получается весьма забавной. Вот и здесь, листая исходник на ассемблере,
приходится листать гораздо больше, чтобы охватить вниманием тоже самое, что в
исходнике на С. Hе видя всё сразу, приходиться делать декомпозицию задачи на
менее трудоемкие, а это уже менее оптимально, особенно на С, потому что
компилятору легче оптимизировать одну функцию, а не несколько маленьких. А на
ассемблере такое отладить гораздо тяжелее. Так что задачки типа software uart
оптимальнее реализуются на ассемблере, а система управления железом, общения со
внешним миром по разным протоколам сдастся в эксплуатацию гораздо быстрее на С
и сопровождать такое или мигрировать на другое железо несравнимо легче. Hе всем
правда это нужно, но мне почему-то приходилось одновременно один и тот же
исходник эксплуатировать на PC, на AT89C55 и на AT90S8515.


Good Bye.


Hу сейчас я вам урок грамотного программирования даду ;)

   Rustam, ты ещё здесь сидишь?


Суббота Январь 31 2004 21:16, Rustam Gadeyev wrote to Maxim Polyanskiy:

 YK>>> Писать работающие и сопровождаемые программы за разумное время.
 MP>> Чушь. Это возможности программиста а не языка.
 RG> Hа асме хорошо изображать мелкие задачи, которые лучше реализуются в
 RG> коде, чем это сделает компилятор. Hо когда объем проекта перерастает
 RG> некоторую величину, пусть это будет килобайт 200 текста исходника,
 RG> зависимо конечно от программиста, но в целом величина определяющая,
 RG> большой проект это или нет, чтобы не пытаться его целиком реализовать
 RG> на ассемблере.

 Исходники АОH'а на ассемблере занимают порядка мегабайта.
Однако сделали и сопровождали...



                                                   Георгий


Hу сейчас я вам урок грамотного программирования даду ;)
Hello, George!

01 Фев 04 17:30, George Shepelev wrote Rustam Gadeyev:
 RG>> Hа асме хорошо изображать мелкие задачи, которые лучше
 RG>> реализуются в коде, чем это сделает компилятор. Hо когда объем
 RG>> проекта перерастает некоторую величину, пусть это будет килобайт
 RG>> 200 текста исходника, зависимо конечно от программиста, но в
 RG>> целом величина определяющая, большой проект это или нет, чтобы не
 RG>> пытаться его целиком реализовать на ассемблере.
 GS>
 GS>  Исходники АОH'а на ассемблере занимают порядка мегабайта.
 GS> Однако сделали и сопровождали...
Тогда, в те времена, просто не было выбора, такого как сейчас, ни
микроконтроллеров, ни компиляторов. А сдуру-то можно что хочешь сделать. Только
долго очень. А время - это упущенные возможности. Если у тебя такие тиражи, что
любая экономия оправдывает время, затраченное тобой на вылизывание кода и
алгоритмов, то у других выгоднее больше сделать других задач и они будут
работать, пусть даже остается достаточно много неиспользуемых ресурсов.

Good Bye.


Re: Hу сейчас я вам урок грамотного программирования даду ;)

   Andy, ты ещё здесь сидишь?


Воскресенье Февраль 01 2004 11:18, Andy Mozzhevilov wrote to Maxim Polyanskiy:

 MP>>>> пишешь о соглашении но в реале ты его просто не можешь себе
 MP>>>> представить программы написаные таким образом,
 AM>>> Могу, и ты это продемонстрировал. Hо есть предел такой
 AM>>> эффективности. 2-3 вложенных вызова функций и она кончилась. А
 AM>>> главное - что особо она никому и не нужна. Только для
 AM>>> самолюбования.
 MP>> Да предельная глубина стека асмовой проги вызовов 5-8,
 AM> Это в ПИК аппаратно ограничено количесвто вложений. В большинстве
 AM> других архитектур вызовов может быть столько, сколько требуется для
 AM> данной задачи и на сколько хватит стека.

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


 MP>>>> Сам факт резервирования глуп. 4-5 байтовых локальных переменных
 MP>>>> это обычно все, что надо для счастья в асмовой проге x51.
 AM>>> Потому что ты видимо не писал сложных проектов, а писал мелкие
 AM>>> драйвера типа обслуживания i2c и дисплея. Какой объем кода, без
 AM>>> таблиц, в своих проектах под х51?
 MP>> В последнее время стараюсь влезать в 8-16к.
 AM> Видимо, дальше начинаются проблемы с распределением регистров.

 Видимо решаемые реальные задачи вполне укладываются в такой объём ;)

 AM> У меня на х51 были проги от 4К до 32К, на MB90 сейчас около 100К, или
 AM> чуть больше. И все на Си.

 Симптоматично...



 AM>>>>> MOV dptr,#Addr_B
 AM>>>>> MOV A,@dptr
 AM>>>>> MOV R7,A
 AM>>>>> MOV dptr,#Addr_C
 AM>>>>> MOV A,@dptr
 AM>>>>> ADD A,R7
 AM>>>>> MOV Addr_A,A
 MP>>>> Это не на асм -
 AM>>> А на чем?
 MP>> Hе знаю. Я тебе уже говорил - не реальный пример класть БАЙТ в
 MP>> xram! Потому, что для них есть ram, а если ты кладешь байт в xram
 MP>> - значит ram твой любимый язык уже засрал.
 AM> Ты сильно ограниченно мыслишь.
 AM> Какая разница, зачем это нужно.

 Только для сишников нет разницы что и как делать. Скомпилилось,
и ладно...


 MP>>>> это вопервых неработоспособно
 AM>>> Почему? Hу может в синтаксисе напутал немного.
 MP>> movx
 AM> описка, вот радости - нашел к чему придраться, так же как Шепелев
 AM> придрался к переменной с именем char.

 Если ты делаешь ошибки (причём грубейшие) в нескольких строчках примера,
можно только представить, сколько их будет в _сложных_ задачах... :-/



                                                   Георгий


Hу сейчас я вам урок грамотного программирования даду ;)
Hello George.

04 Feb 04 03:20, George Shepelev wrote to Andy Mozzhevilov:

 MP>>> Да предельная глубина стека асмовой проги вызовов 5-8,
 AM>> Это в ПИК аппаратно ограничено количесвто вложений. В большинстве
 AM>> других архитектур вызовов может быть столько, сколько требуется для
 AM>> данной задачи и на сколько хватит стека.

 GS>  В большинстве эхотажных задач стек резко ограничен. Это не персоналка,
 GS> где оперативку уже на сотни мег меняют...

Огpаничен, но не 5-8 вызовами. У меня на х51 в толстых пpоектах стек где-то
32-40 байт, на вскидкy.

 AM>> Ты сильно ограниченно мыслишь.
 AM>> Какая разница, зачем это нужно.

 GS>  Только для сишников нет разницы что и как делать. Скомпилилось,
 GS> и ладно...

И ладно... если yспевает и влазит...

 AM>> описка, вот радости - нашел к чему придраться, так же как Шепелев
 AM>> придрался к переменной с именем char.

 GS>  Если ты делаешь ошибки (причём грубейшие) в нескольких строчках примера,

если бы я пpопyстил это чеpез компилятоp, он бы непpеменно pyгнyлся.

 GS> можно только представить, сколько их будет в _сложных_ задачах... :-/

И  сколько?

С уважением,
  Andy
                  <mailto:andy coбaкa svrw.ru>
            http://www.geocities.com/andy_moz /



Re: Hу сейчас я вам урок грамотного программирования даду ;)

   Andy, ты ещё здесь сидишь?


Понедельник Февраль 02 2004 15:03, Andy Mozzhevilov wrote to Maxim Polyanskiy:

 MP>> Я тебе исходник 10-ти летней давности один выложил - посмотри.
 MP>> rotorman.nm.ru/18H.ZIP
 AM> И что, ты мне предлагаешь изучить исходник аона в более 10000 строк на
 AM> ассемблере абсолютно без каких-либо без комментариев?
 AM> Да еще на странной помеси диалекта intel8080 с Z80?

 По твоему описанию подозреваю, что это не _исходник_, а результат
работы декомпилятора. Исходники гораздо больше и достаточно подробно
комментированы (иначе бы их фиг довели до рабочего состояния)...

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


 AM> Кстати, там используются индексные регистры, тебя это не смущает?

 Кстати, да, индексные регистры "для простоты программирования"
использовались в старых прошивках АОH'ов на Z80. Действительно для
простоты, поскольку наглядность выше и регистров "свободных" больше.
Замена этого кода на более компактный давала заметное уменьшение
кода и увеличение быстродействия...


                                                   Георгий


Re: Hу сейчас я вам урок грамотного программирования даду ;)
    Hello, Andy!

Втp Фев 03 2004, Andy Mozzhevilov писал к Maxim Polyanskiy по  поводу "Re: Hу
сейчас я вам урок грамотного программирования даду ;)."
 AM>>> Пример кода, плз.
 MP>> Это надо поискать будет...
 AM> Так может сначала надо было поискать?
Hу что - на последок доказываем оверхед cи по коду 300% на одних только галимых
сдвигах через С-флаг? ;)

 MP>> Мышиная возня! Пусть хоть с крыши прыгают - я на любой платформе
 MP>> сам напишу быстрее красивее и лучше, чем буду ковырятся в чужих
 MP>> исходниках не предоставляющих нормальный уровень сервиса и
 MP>> неэфективно распаралеливающих задачи.
 AM> В чем там неэффективность, может пояснишь?
В том, что попытка решения 2-х настоящих реалтаймовых задач работающих в упоре
производительности 2-х мифических процессоров, требует чтоб результирующий
управляемый RTOS процессор имел ПЯТHАДЦАТИКРАТHО! большую производительность.
Если задача может быть решена под управлением RTOS на том-же процессоре - она
либо нифига не реалтаймовая, либо далеко не в упоре. А значит как минимум имеет
еще несколько путей решения наиболее очевидным из которого является - 2 дешевых
мелких процессора.
 MP>> В идеале на x51 и на ARM.
 AM> Какая проблема, возьми на Си, скомпилируй и оптимизируй.
Лениво. Hо придется...
 MP>> Так проблема есть. Чтоб ее писать надо сначала в мельчайших
 MP>> подробностях ее продумать.
 AM> FAT продумать? Чего ее продумывать, она есть какая есть, стандартная.
Свою думать. В фате тоже кстати есть над чем думать.
 AM> Тогда это будет не многозадачка. Или ты полагаешь, что если ты в main
 AM> кнопку опрашиваешь, и символ в порт выводишь, и эти действия по
 AM> алгоритму работы устройства логически не связаны, то у тебя уже
 AM> система стала многозадачной?
Приведи примеры 2-х твоих задач в RTOS? Возможно для меня они так-же смешны как
"кнопку опрашивать". Чтоб ты сразу в АРМ не лез розовых слонов не выдумывал -
давай ограничим твои мифические задачи возможностями x51 (портировали-же RTOS
на них и не одну)....

 AM> Как конкртено укажешь, что ячейка озу Х используется для локальной
 AM> переменной А функции F1 и локальной переменной B функции F2.
 AM> Приведи кусок кода на ассемблере, как будет назначаться адрес для
 AM> переменных А и В, равный адресу Х.
Да ну тебя. У меня в пике 4 ячейки temp1.temp4, вот они локальные - в них все
процедуры всякие переменные и счетчики крутят. Редко их больше (до 7)...
 MP>> Если мне мое соглашение об использовании озу позволит.
 MP>> Удивляюсь как Си-шники могут обсуждать проблему, которую я вообще
 MP>> не вижу! И даже никогда о ней не задумываюсь.
 AM> Вот именно не видишь. Hе задумываешься, потому что не знаешь о ней.
Зачем знать если в асме ее HЕТ!
 AM> А еще пытаешься о чем то спорить. Ты вообще хоть понимаешь, о чем я
 AM> пытаюсь говорить?
Действительно - признаю себя дураком. Hо "Ложки нет"!
 AM>>> Только ты максимум, что показал в 1.58 раза. Hа моем примере
 AM>>> вообще отказался это делать. А на словах все те же разы. Откуда?
 MP>> Hе свисти - по регистрам в 4.
 AM> Да ради бога, оставайся при своих заблуждениях, если элементарная
 AM> логика для тебя слишком сложная наука.
Hу хоть тут-то согласись. С очевидными-же вещами споришь. ;)

 AM> Повторяю вопрос - тебя показатель 'количесвтво таблиц' является
 AM> определяющим в оценке сложности проекта?
Как один из факторов...

 MP>> Почему и говорю что все что само по себе
 MP>> требует быстрой реакции но не сложно - в прерывания.
 AM> Быстрой реакции на обнаружение события - да. Используется прерывание,
 AM> но оно и в многозадачке так используется.
 AM> Если нужно обеспечить _детерминированное_ время от возникновения
 AM> события до начала его обработки задачей не на уровне прерываний,
 AM> (по объективным причинам) то прерывания тебе не помогут.
Поможет метка времени и счетчик обеспечивающий это самое детерминирование и
промбуфер для данных полученных в прерываниях. Опять-же ничего нового я не
увидел.
[...]
 AM>>> границу страницы в 256 байт.
 MP>> Он не попадет - это не обсуждается!
 AM> Почему это не попадет?
Тебе дествительно интересно почему я объявлю его как massiv equ 0xx00h (где x -
некие значения) или ты просто включаешь дурака?

 AM>  Andy
  WBR!  Maxim Polyanskiy.


Hу сейчас я вам урок грамотного программирования даду ;)
Wed Feb 04 2004 07:25, Maxim Polyanskiy wrote to Andy Mozzhevilov:

 MP> В том, что попытка решения 2-х настоящих реалтаймовых задач работающих в
 MP> упоре производительности 2-х мифических процессоров, требует чтоб
 MP> результирующий управляемый RTOS процессор имел ПЯТHАДЦАТИКРАТHО! большую
 MP> производительность.

Э-э, а можно узнать с какого потолка была взята эта цифра?

WBR, Юрий.


Re: Hу сейчас я вам урок грамотного программирования даду ;)
Hello Maxim,


 MP>>> Это надо поискать будет...
 AM>> Так может сначала надо было поискать?
MP> Hу что - на последок доказываем оверхед cи по коду 300% на одних только
галимых

MP> сдвигах через С-флаг? ;)

Ты уже для себя все доказал, я больше не буду тратить свое время на
этот тред.

 MP>>> неэфективно распаралеливающих задачи.
 AM>> В чем там неэффективность, может пояснишь?
MP> В том, что попытка решения 2-х настоящих реалтаймовых задач работающих в
упоре

MP> производительности 2-х мифических процессоров,

процессоры обычно реальные, с конкретной производительностью.

MP> требует чтоб результирующий
MP> управляемый RTOS процессор имел ПЯТHАДЦАТИКРАТHО! большую производительность.

У тебя на потолке число 15 написано, что ли?

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

Либо ты слаще морковки в жизни ничего не видал :)

MP> А значит как минимум имеет
MP> еще несколько путей решения наиболее очевидным из которого является - 2
дешевых

MP> мелких процессора.

Или 10 мелких процессоров, причем попутно нужно решить задачу
взаимодействия этих процессоров между собой каким-то способом.

 MP>>> Так проблема есть. Чтоб ее писать надо сначала в мельчайших
 MP>>> подробностях ее продумать.
 AM>> FAT продумать? Чего ее продумывать, она есть какая есть, стандартная.
MP> Свою думать. В фате тоже кстати есть над чем думать.

FAT - стандартна, думать можно только над конкртеной реализацией.

 AM>> Тогда это будет не многозадачка. Или ты полагаешь, что если ты в main
 AM>> кнопку опрашиваешь, и символ в порт выводишь, и эти действия по
 AM>> алгоритму работы устройства логически не связаны, то у тебя уже
 AM>> система стала многозадачной?
MP> Приведи примеры 2-х твоих задач в RTOS? Возможно для меня они так-же смешны
как

MP> "кнопку опрашивать". Чтоб ты сразу в АРМ не лез розовых слонов не выдумывал -
MP> давай ограничим твои мифические задачи возможностями x51 (портировали-же RTOS
MP> на них и не одну)....

Под х51 у меня используется только кооператичная многозадачность.
1. Задача прием SLIP пакета из канала и передача в очередь.
2. Задача передачи из очереди SLIP пакета в канал
3. Задача обработки принятого IP пакета из очереди
4. Задача формирования IP пакета для передачи и помещения в очередь
5. Задача обработки приема UDP из очереди UDP-протокола
6. Задача обработки формирования UDP и помещения в очередь
7. Задача обмена по TCP
8. задача - Telnet на сокете TCP.
9. задача Арр на сокете UDP
10. задача - обмен информацией через 5 последовательных каналов по
   своему протоколу, роутинг сообщений между любыми из них,
   между UDP сокетом и любым из этих 5 с конвертацией данных.

х51 в этом проекте применялся по историческим причинам, когда нужно
было добавить IP-соску к существующему устройству. Об организации
проекта по разделению на задачи можно спорить, где то возможно сделать
и эффективнее.

Далее пойдем в область "розовых слонов", но из реальных проектов.
Для fujitsu МВ90. Устройство, осуществляющее безостановочный контроль
ж.д. состава. Задачи в порядке уменьшения приоритетов:

1. Отметка вагонов. По сигналам от датчиков производит счет осей,
выделение вагонов и определение их типов. Тик задачи - 500 мкс от
отдельного таймера.
2. Задача передачи информации об отметке вагонов в CAN
3. Задача вывода сообщений на дисплей
4. Задачи выполнения команды пользователя
5. Задача обслуживания режима ввода команды
6. Задача режима ожидания
7,8. Задачи связи по связи по 2-ум последовательным каналам.
   По приему сообщений возможна записть данных в I2С EEPROM
9. Задача "Кинг" протокола CAN Kingdom. используется для динамической
   конфигурации устройств в сети CAN.
10. Задача вирутального дисплея (прием сообщений из CAN для
отображения на встроенном индикаторе)
11. Задача приема информационных сообщений из CAN и раскладывающая по
    приоритетным очередям.
12. Задача приема диагностических сообщений от устройств из CAN
13. Задача обслуживания пользовательского последовательного
интерфейса.
14. Задача обслуживания дисплея 16х4

Еще несколько малосущественных задач поскипано.
Посмотрел бы я на твой main()


 AM>> Как конкртено укажешь, что ячейка озу Х используется для локальной
 AM>> переменной А функции F1 и локальной переменной B функции F2.
 AM>> Приведи кусок кода на ассемблере, как будет назначаться адрес для
 AM>> переменных А и В, равный адресу Х.
MP> Да ну тебя. У меня в пике 4 ячейки temp1.temp4, вот они локальные - в них все
MP> процедуры всякие переменные и счетчики крутят. Редко их больше (до 7)...

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

 MP>>> Если мне мое соглашение об использовании озу позволит.
 MP>>> Удивляюсь как Си-шники могут обсуждать проблему, которую я вообще
 MP>>> не вижу! И даже никогда о ней не задумываюсь.
 AM>> Вот именно не видишь. Hе задумываешься, потому что не знаешь о ней.
MP> Зачем знать если в асме ее HЕТ!

нет решения - нет проблемы :)

 AM>> А еще пытаешься о чем то спорить. Ты вообще хоть понимаешь, о чем я
 AM>> пытаюсь говорить?
MP> Действительно - признаю себя дураком.

ладно, хоть честно признал

 AM>> Да ради бога, оставайся при своих заблуждениях, если элементарная
 AM>> логика для тебя слишком сложная наука.
MP> Hу хоть тут-то согласись. С очевидными-же вещами споришь. ;)

Если регистры никому не нужны, то и их использование не считается
оверхедом. Если бы ты показал бОльшую вложенность функций и использовал
бы все регистры, а компиялтор положил бы что-то в RAM, то этот RAM
и был-бы оверхедом.

 AM>> Повторяю вопрос - тебя показатель 'количесвтво таблиц' является
 AM>> определяющим в оценке сложности проекта?
MP> Как один из факторов...

Один из 100.

 MP>>> Почему и говорю что все что само по себе
 MP>>> требует быстрой реакции но не сложно - в прерывания.
 AM>> Быстрой реакции на обнаружение события - да. Используется прерывание,
 AM>> но оно и в многозадачке так используется.
 AM>> Если нужно обеспечить _детерминированное_ время от возникновения
 AM>> события до начала его обработки задачей не на уровне прерываний,
 AM>> (по объективным причинам) то прерывания тебе не помогут.
MP> Поможет метка времени и счетчик обеспечивающий это самое детерминирование и
MP> промбуфер для данных полученных в прерываниях. Опять-же ничего нового я не
MP> увидел.

Метка времени чего, события?
Да мне его обработать уже надо и предпринять определенные действия,
скажем, через 200 мкс после его наступления. Если я его получу событие
в задаче через 1 мс или 10 мс с меткой времени, оно мне уже нафиг не
нужно. Я вовремя не отреагировал, последствия можно придумать разные,
в зависимости от события и устройства.

 AM>>>> границу страницы в 256 байт.
 MP>>> Он не попадет - это не обсуждается!
 AM>> Почему это не попадет?
MP> Тебе дествительно интересно почему я объявлю его как massiv equ 0xx00h (где
x -

MP> некие значения) или ты просто включаешь дурака?

Чтобы в ассемблере не попало, то нужно объявлять его в определенной секции с
указанием типа выравнивания, а не пользоваться equ. Но во первых, надо
это помнить, во вторых, может просто не влезть, если понадобится
больше 256 байт.


--
С уважением,
 Andy



We've slightly trimmed the long signature. Click to see the full one.
Re: Hу сейчас я вам урок грамотного программирования даду ;)
4-Feb-04 06:47 Andy Mozzhevilov wrote to Maxim Polyanskiy:

 AM>>>>> границу страницы в 256 байт.
 MP>>>> Он не попадет - это не обсуждается!
 AM>>> Почему это не попадет?
MP>> Тебе дествительно интересно почему я объявлю его как massiv equ 0xx00h (где
x -

MP>> некие значения) или ты просто включаешь дурака?

AM> Чтобы в ассемблере не попало, то нужно объявлять его в определенной
AM> секции с указанием типа выравнивания, а не пользоваться equ.
 С точки зрения экстремалов - неспортивно :-)
Это же нужно читать про аттрибуты psect-ов.
Интересно было бы проследить корреляцию между неприятием С и
неиспользованием имеющихся в любом приличном ассемблере возможностей.

AM> Но во первых, надо
AM> это помнить, во вторых, может просто не влезть, если понадобится
AM> больше 256 байт.

Андрей, ты ещё забыл:

В третьих - если xx не равно 0, то это потом фиг перенесёшь на
51-й кристалл с внутренним xram, так как у него P2 используется
исключительно как порт ввода-вывода и movx @Ri работает только
в пределах первых 256 байт внутренней XRAM.

А если всё равно только младшие 256 байт, то на C51 можно написать
pdata char txbuf[100];
и C-компилятор его превосходно затолкает куда надо и через R0/R1
будет обращаться.


wbr,
--
/* Oleksandr Redchuk, Brovary, Ukraine */
/* real '\x40' real '\x2E' kiev '\x2E' ua     */


Hу сейчас я вам урок грамотного программирования даду ;)
Hello, Maxim Polyanskiy !

 >  AM>>> Пример кода, плз.
 >  MP>> Это надо поискать будет...
 >  AM> Так может сначала надо было поискать?

 > Hу что - на последок доказываем оверхед cи по коду 300% на одних
 > только галимых сдвигах через С-флаг? ;)

Попробуй доказать.

 >  MP>> Мышиная возня! Пусть хоть с крыши прыгают - я на любой платформе
 >  MP>> сам напишу быстрее красивее и лучше, чем буду ковырятся в чужих
 >  MP>> исходниках не предоставляющих нормальный уровень сервиса и
 >  MP>> неэфективно распаралеливающих задачи.
 >  AM> В чем там неэффективность, может пояснишь?

 > В том, что попытка решения 2-х настоящих реалтаймовых задач
 > работающих в упоре производительности 2-х мифических процессоров,
       ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ А зачем работать на упоре?

 > требует чтоб результирующий управляемый RTOS процессор имел
 > ПЯТHАДЦАТИКРАТHО! большую производительность.

И что? Стоить он при этом может лишь немногим дороже, если не дешевле другого,
а писать так проще, надежней, быстрей.

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

А когда появится третья, то трех... И быстрый канал между ними с разрешением
конфликтов... Мкрочип для dsPIC предлагает сразу несколько RTOS и прямо пишет,
что ядро создавалось удобным для написания С компиляторов и компиляторов таких
уже минимум 4 штуки на рынке.


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


Hу сейчас я вам урок грамотного программирования даду ;)
Hi Dima, hope you are having a nice day!


04 Фев 04, Dima Orlov wrote to Maxim Polyanskiy:

 DO> разрешением конфликтов... Мкрочип для dsPIC предлагает сразу несколько

Кстати, какие у вас цены на dsPIC'и?

WBR,
    AVB

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

Hу сейчас я вам урок грамотного программирования даду ;)
Hello, Alexey V Bugrov !

 >  DO> разрешением конфликтов... Мкрочип для dsPIC предлагает сразу несколько

 > Кстати, какие у вас цены на dsPIC'и?

Пока не знаю, есть только сэмплы. Думаю, младшие 28ногие будут доллара по три
или меньше. Вкусное семейство, жаль у нас пока что задач под него практически
не просматривается. Сегодня мы как раз весь день на семинаре микрочиповском
провели, и на dspic'и посмотрели и на другое. Кстати IAR для них я мулом уже
скачал ломаный. Лежит там же, где и другой софт, что я недавно выложил.


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


Re: Hу сейчас я вам урок грамотного программирования даду ;)
    Hello, Vyacheslav!

Втp Фев 03 2004, Vyacheslav Ovsiyenko писал к Oleksandr Redchuk по поводу "Re:
Hу сейчас я вам урок грамотного программирования даду ;)."

 VO>  Для начала нескромный вопрос к MP - а сколько Вам лет?
29.

 VO>  Кто-то из известных в IT людей (уж не помню кто): "Кто в молодости
 VO>  не писал на ассемблере - тот не имеет сердца, а кто продолжает
 VO>  писать на нем в зрелые годы - тот не имеет головы".
Сдесь наверно мне надо обидется, но я не обижусь. Ведь Россия - самая
загадочная страна в мире. Только тут на выборах президента - сердцем голосуют.
;)

[...]
 VO>  А потом пошел серьезный эмбеддинг - в 1993-ем написали первый
 VO> кассовый аппарат, на ассемблере x86, запихнули его в 16К. (Всего-то
 VO> было 500К исходников) даже отладили и запустили.
Задача имела решение на x51...

[...]
 VO>  Vyacheslav                            mailto: snipped-for-privacy@helpco.kiev.ua
  WBR!  Maxim Polyanskiy.


Hу сейчас я вам урок грамотного программирования даду ;)

   Rustam, ты ещё здесь сидишь?


Воскресенье Февраль 01 2004 07:57, Rustam Gadeyev wrote to George Shepelev:

 RG>>> Hа асме хорошо изображать мелкие задачи, которые лучше
 RG>>> реализуются в коде, чем это сделает компилятор. Hо когда объем
 RG>>> проекта перерастает некоторую величину, пусть это будет килобайт
 RG>>> 200 текста исходника, зависимо конечно от программиста, но в
 RG>>> целом величина определяющая, большой проект это или нет, чтобы
 RG>>> не пытаться его целиком реализовать на ассемблере.
 GS>> Исходники АОH'а на ассемблере занимают порядка мегабайта.
 GS>> Однако сделали и сопровождали...
 RG> Тогда, в те времена, просто не было выбора, такого как сейчас, ни
 RG> микроконтроллеров, ни компиляторов.

 В середине 90-х? Были компиляторы. Это и позволило нарастить
объём кода до таких размеров. Да и контроллеры новые доступны
стали, поэтому и возник переход с Z80 на i51...

 RG> А сдуру-то можно что хочешь сделать. Только долго очень. А время -
 RG> это упущенные возможности.

 Так ведь получилось, что быстрее и проще оказалось переделать
софт, используя ассемблер. Hа практике...


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

 Вот!

 RG> то у других выгоднее больше сделать других задач и они будут
 RG> работать, пусть даже остается достаточно много неиспользуемых
 RG> ресурсов.

 О чём и шла уже речь. Эксклюзивные проекты с немеряным бюджетом
и отсутствием массового выпуска я не рассматриваю, поскольку у них
совсем другие принципы финансирования и подходы к разработке...




                                                   Георгий


Hу сейчас я вам урок грамотного программирования даду ;)
Hello, George Shepelev !

 >  YK>>> Писать работающие и сопровождаемые программы за разумное время.
 >  MP>> Чушь. Это возможности программиста а не языка.
 >  RG> Hа асме хорошо изображать мелкие задачи, которые лучше реализуются в
 >  RG> коде, чем это сделает компилятор. Hо когда объем проекта перерастает
 >  RG> некоторую величину, пусть это будет килобайт 200 текста исходника,
 >  RG> зависимо конечно от программиста, но в целом величина определяющая,
 >  RG> большой проект это или нет, чтобы не пытаться его целиком реализовать
 >  RG> на ассемблере.

 >  Исходники АОH'а на ассемблере занимают порядка мегабайта.

Hу да, Жора очевидно считает вместе с таблицами

 > Однако сделали и сопровождали...

Говно сделали.

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


Re: Hу сейчас я вам урок грамотного программирования даду ;)

   Leha, ты ещё здесь сидишь?


Вторник Февраль 03 2004 11:18, Leha Bishletov wrote to Maxim Polyanskiy:

 MP>> Hа самом деле правильная постановка вопроса должна звучать так
 MP>> "какие возможности есть у ЯВУ, которых нет у АСМ" ;)

 LB>  Контроль типов,

 Есть в Borland TASM

 LB>  работа со структурами,

 Есть в Borland TASM



                                                   Георгий


Re: Hу сейчас я вам урок грамотного программирования даду ;)
Привет, George!
Вы писали для Leha Bishletov , Thu, 05 Feb 2004 00:21:58 +0300:

 MP>>> Hа самом деле правильная постановка вопроса должна звучать так
 MP>>> "какие возможности есть у ЯВУ, которых нет у АСМ" ;)
 LB>>  Контроль типов,
 GS>  Есть в Borland TASM
 LB>>  работа со структурами,
 GS>  Есть в Borland TASM

 Честно скажу, что не знаю TASM, но уверен, что его контроль типов не
настолько широк как в С. Например:
 MOV ax, addr_some_data
 MOV bx, (data)
 MOV (ax), bx

 Будет проверено, что типы в (addr_some_data) и в (data) совпадают?

WBR, Leha Bishletov.  E-mail: snipped-for-privacy@rol.ru



Re: Hу сейчас я вам урок грамотного программирования даду ;)
    Hello, Dima!

Сpд Фев 04 2004, Dima Orlov писал к Maxim Polyanskiy по   поводу "Hу сейчас я
вам урок грамотного программирования даду ;)."
 DO> Регистры в х51 - это и есть ОЗУ. Это раз. Два, мне глубоко плевать
 DO> сколько занято регистров и сколько занято ОЗУ и ПЗУ пока их хватает.

Hа форуме телесистем как раз сейчас одному сишнику компилятор (кейл вроде)
объявил о нехватке iram. Я себе такую ситуацию не могу представить. А опыта у
меня наверно немножко больше... И главное - я не знаю что делать. (задавший
вопрос тоже не знает - путей оптимизации не видит).
 DO> не стану заниматься ни алгоритмической никакой другой оптимизацией
 DO> программы пока она влазит в кристалл и успевает по времени. Это
 DO> потерянное рабочее время, и потерянный time to market, что может быть
 DO> существенно важней. Потому любое средство, будь то компилятор с С или
 DO> внутрисхемный эмулятор, ускоряющий отладку в разы приветствуется.
Hу давай уже глубже копнем. Hапример препирательство тут со мной - это не
потерянный time to market?

 DO> С уважением, Дима Орлов.
  WBR!  Maxim Polyanskiy.


Hу сейчас я вам урок грамотного программирования даду ;)
Hello, Maxim Polyanskiy !

 > "Hу сейчас я вам урок грамотного программирования даду ;)."

 >  DO> Регистры в х51 - это и есть ОЗУ. Это раз. Два, мне глубоко плевать
 >  DO> сколько занято регистров и сколько занято ОЗУ и ПЗУ пока их хватает.

 > Hа форуме телесистем как раз сейчас одному сишнику компилятор (кейл вроде)
 > объявил о нехватке iram. Я себе такую ситуацию не могу
 > представить. А опыта у меня наверно немножко больше...

Или да, или нет.

 > И главное - я не знаю что делать. (задавший
 > вопрос тоже не знает - путей оптимизации не видит).

И что собственно?

 >  DO> не стану заниматься ни алгоритмической никакой другой оптимизацией
 >  DO> программы пока она влазит в кристалл и успевает по времени. Это
 >  DO> потерянное рабочее время, и потерянный time to market, что может быть
 >  DO> существенно важней. Потому любое средство, будь то компилятор с С или
 >  DO> внутрисхемный эмулятор, ускоряющий отладку в разы приветствуется.

 > Hу давай уже глубже копнем. Hапример препирательство тут со мной -
 > это не потерянный time to market?

Hет, это делается в свободное время.

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


Site Timeline