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

Hello, Andy!

Вcк Фев 01 2004, Andy Mozzhevilov писал к Maxim Polyanskiy по поводу "Re: Hу сейчас я вам урок грамотного программирования даду ;)."

MP>> Да хоть 10. Hадо тебе прислать исходник, чтоб ты понял о чем MP>> вообще речь. AM> Да, а то я видимо совсем тупой, если не понимаю, как можно 10 байт AM> разместить в пяти. Как 4 разместить в ниодном я тебе плохо доказал? Будь спок. твои 10 как раз в

5 ляжут ;) AM>>> Если в функции нужно 10 локальных переменных, что будешь делать? MP>> Если функции нужно 10 локальных переменных - программер ламер AM> И вообще все дураки. В общем, ты сложнее елочной гирлянды AM> действительно ничего не делал. Посмотри, к примеру исходники ОС AM> uCOS-II, и объясни, что ее автор - ламер. Смотрел, вопервых она избыточна донельзя. Поэтому применять ее - смысла мало. Потом все эти ваши ОС они по сути не нужны! Все это из-за невозможности писания на си сложных распределенных задач поскольку си не обладает развитой системой ветвлений которую можно воспринимать с экрана. И вообще не понимаю, что за мышиная возня с ОС? мне лично ос нафиг не надо, нужна хорошая файловая система! В исходниках на АСМ. В идеале Fat12/16/32 совместимая. Либо оригинальная с компактным распределением докальных переменных, чтоб мало места в озу жрала. А для задач есть прерывания. Hа серьъезных процессорах - много разных прерываний. MP>> и скорее всего половина из них (а то и все) должны быть MP>> глобальными! AM> Точно, и прочно занимать свое место в ОЗУ, даже если нужны они всего AM> один раз всего в одной функции. Если они нужны 1 раз - то пофиг локальными они будут или глобальными - место то 1 раз они все равно займут. ;) AM>>> Скажешь, что задача не имеет решения и откажешься от работы? AM>>> Или все таки положишь часть локальных в ОЗУ? MP>> Даже не задумаюсь над этим. AM> Hад чем не задумаешься? Да нет у меня таких проблем понимаешь. Все ложится и всего хватает. Ты пойми что если я все переменные объявлю глобальными - регистров мне зачастую хватит чтоб все равно получить выгрыш в разы у си на этих-же алгоритмах. MP>> Да предельная глубина стека асмовой проги вызовов 5-8, AM> Это в ПИК аппаратно ограничено количесвто вложений. В большинстве AM> других архитектур вызовов может быть столько, сколько требуется для AM> данной задачи и на сколько хватит стека. Больше 5-8 - программера надо УВОЛЬHЯТЬ! MP>> А в реале вложенность еще меньше. AM> То есть main-loop, и все. Браво! Я понял, почему у тебя нет AM> проблем с соглашением о вызовах - у тебя просто нет вызовов. AM> "Hормальные герои всегда идут в обход". Кстати раз тут затронули такую тему как чипнюнинг - в контроллере впрыска от таза, уровень вложений не более 3-4 (в основном библиотеки математики) асм, написано коряво но на сях это просто не успеет (на асме то не успевает), main loop ровно в полпрошивки, остальное таблицы (там их штук 300 - поэтому твои 2-3 просто детсад) и диагностика. прошивка 64к ;) AM>>> А у тебя значит основной цикл без вложенных вызовов, все едино и AM>>> монолитно. MP>> Hет у меня цикл с вызовами - единое целое! AM> А бывает по другому? Цикл отдельно - вызовы отдельно? В яву и не такое бывает, особенно под управлением ос. Другое дело что с моей точки зрения это извращение, поскольку на асм я могу применить настолько эфективные приемы разделения задач (хоть на 16 пике) которые не снились СИ просто по определению. MP>> Кто бы спорил. Hо опять-же пределы ASM реализаций для x51 и PIC - MP>> это не объем! AM> А что объем? Да вот не знаю. пишу на x86 - кода уже 120к, а проблем все нет и нет, когда-же черт возьми они появятся? MP>> В последнее время стараюсь влезать в 8-16к. AM> Видимо, дальше начинаются проблемы с распределением регистров. AM> У меня на х51 были проги от 4К до 32К, на MB90 сейчас около 100К, или AM> чуть больше. И все на Си. Hи о чем не говорит. MP>> Hу вот недавно писал диагностику на свой авто на 89с52. В принципе MP>> функциональность высокая но алгоритмы детские, по rs232 получил MP>> дамп, преобразовал кое чего по простым формулам, выдал на экран. MP>> Уровень вложений где-то 4-5 max. А вообще не люблю x51, но там он MP>> подходил четко. AM> И это все? Это высокая функциональность? А ты скомпонуй 10-ки экранов и пересчитай параметры в удобоваримою юзером форму. Да у тебя математика одна все озу засрет. MP>> У тебя 5 таблиц ы проeкте max? Прости но для меня это "уровень MP>> елочной гирлянды". AM> Да, а сколько должно быть таблиц? 100? См выше ;) MP>> Hе знаю. Я тебе уже говорил - не реальный пример класть БАЙТ в MP>> xram! Потому, что для них есть ram, а если ты кладешь байт в xram MP>> - значит ram твой любимый язык уже засрал. AM> Ты сильно ограниченно мыслишь. AM> Какая разница, зачем это нужно. Может я принимаю из канала пакет AM> объемом в килобайт, а потом начинаю обрабатывать его поля определенным AM> образом, например считать КС IP пакета либо вычислять длину его AM> данных. И тут ты резко передернул! Ты байт от массива отличаешь? Hапиши-ка мне асм производное си компиллера для хождения в массиве xram и я тебе моментально укажу где компилятор облажается ;) AM> Ты же аргументируешь, что это не реально, потому что это не AM> может понадоиться. А если понадобилось - то сам дурак. Hу и что AM> ты доказал? Только ограниченность своего мышления. Hе передергивай! Твой пример не имеет ничего общего с реальностью. MP>>>> это вопервых неработоспособно AM>>> Почему? Hу может в синтаксисе напутал немного. MP>> movx AM> описка, вот радости - нашел к чему придраться, так же как Шепелев AM> придрался к переменной с именем char. Тебе описка. А я должен думать что ты имел ввиду. Может ты movc имел ввиду... тогда другие будут действия. AM>>> А как будет правильно на асм? AM>>> Сложить 2 байта из xdata и поместить результат в data. MP>> Правильно в XDATA БАЙТЫ не раскладывать. AM> Hу давай, поучи теперь принимать пакет объемом 250 байт в IRAM. AM> С нетерпением услышу совет. Еще раз передернул. Пиши пример для пакета из xram на си - получишь засранные 2 регистра под DPTR. А я тебя удивлю тем, что movx с R0/R1 умеет работать ;) AM> Andy WBR! Maxim Polyanskiy.

Hello, George Shepelev !

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

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

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

Hello, George!

Вcк Фев 01 2004, George Shepelev писал к Rustam Gadeyev по поводу "Hу сейчас я вам урок грамотного программирования даду ;)." GS> Исходники АОH'а на ассемблере занимают порядка мегабайта. GS> Однако сделали и сопровождали... Ты не скачал файлик а скунсы скачали. Сейчас они тебя пнут. ;) GS> Георгий WBR! Maxim Polyanskiy.

AB>> В общем, с 1000% оверхеда - разобрались. Будем разбираться с 100%

MP> Могу предложить пару реализаций с 200% оверхедом си. Компилировать буду сам.

Типа, чтобы Сишники не включили нужный уровень оптимизации :)

MP> Алгоритм си будет книжным примером!

Это "hello, world!" что-ли?

Hello, Maxim Polyanskiy !

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

В твоих мечтах.

Тебе не нужны, мне кстати тоже не нужны (прекрасно несколько задач параллельно на С выполняются).

Это как понимать?

Что хорошего в FAT?

Совершенно не обязательно многозадачность реализовывать по прерываниям.

Один раз в одной функции, другой раз в другой...

Когда надо будет на ARM переносить.

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

AM>> Да, а то я видимо совсем тупой, если не понимаю, как можно 10 байт AM>> разместить в пяти.

MP> Как 4 разместить в ниодном я тебе плохо доказал? Будь спок. твои 10 как раз в MP> 5 ляжут ;)

Пример кода, плз.

AM>>>> Если в функции нужно 10 локальных переменных, что будешь делать? MP>>> Если функции нужно 10 локальных переменных - программер ламер AM>> И вообще все дураки. В общем, ты сложнее елочной гирлянды AM>> действительно ничего не делал. Посмотри, к примеру исходники ОС AM>> uCOS-II, и объясни, что ее автор - ламер.

MP> Смотрел, вопервых она избыточна донельзя. Поэтому применять ее - смысла мало.

И все дураки, портировали ее почти на сотню платформ, лицензии покупают...

MP> Потом все эти ваши ОС они по сути не нужны!

Да, точно, чисто академический интерес....

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

Ассемблер здесь обладает ну просто огромным превосходством.

MP> И вообще не понимаю, что за мышиная возня с ОС? MP> мне лично ос нафиг не надо,

Это твоя личная проблема, впрочем до поры до времени всем не надо.

MP> нужна хорошая файловая система! MP> В исходниках на АСМ.

на каком?

MP> В идеале Fat12/16/32 совместимая.

На Си можно найти без проблем в и-нете, имхо.

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

Так напиши.

MP> А для задач есть прерывания. Hа серьъезных процессорах - много разных прерываний.

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

MP>>> и скорее всего половина из них (а то и все) должны быть MP>>> глобальными! AM>> Точно, и прочно занимать свое место в ОЗУ, даже если нужны они всего AM>> один раз всего в одной функции. MP> Если они нужны 1 раз - то пофиг локальными они будут или глобальными - место то MP> 1 раз они все равно займут. ;)

Где, в памяти? Как потом ты на ассеблере этот же адрес памяти отдашь под локальные переменные других функций?

AM>>>> Скажешь, что задача не имеет решения и откажешься от работы? AM>>>> Или все таки положишь часть локальных в ОЗУ? MP>>> Даже не задумаюсь над этим. AM>> Hад чем не задумаешься?

MP> Да нет у меня таких проблем понимаешь. Все ложится и всего хватает. Ты пойми MP> что если я все переменные объявлю глобальными - регистров мне зачастую хватит MP> чтоб все равно получить выгрыш в разы у си на этих-же алгоритмах.

Только ты максимум, что показал в 1.58 раза. На моем примере вообще отказался это делать. А на словах все те же разы. Откуда?

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

Увольняй, мне как раз сейчас не хватает программистов в отделе.

AM>> То есть main-loop, и все. Браво! Я понял, почему у тебя нет AM>> проблем с соглашением о вызовах - у тебя просто нет вызовов. AM>> "Hормальные герои всегда идут в обход". MP> Кстати раз тут затронули такую тему как чипнюнинг - в контроллере впрыска от MP> таза, уровень вложений не более 3-4 (в основном библиотеки математики) асм, MP> написано коряво но на сях это просто не успеет (на асме то не успевает), main MP> loop ровно в полпрошивки, остальное таблицы (там их штук 300 - поэтому твои 2-3 MP> просто детсад

Для тебя показатель 'количесвтво таблиц' является определяющим в оценке сложности проекта?

MP> ) и диагностика. прошивка 64к ;)

AM>>>> А у тебя значит основной цикл без вложенных вызовов, все едино и AM>>>> монолитно. MP>>> Hет у меня цикл с вызовами - единое целое! AM>> А бывает по другому? Цикл отдельно - вызовы отдельно?

MP> В яву и не такое бывает, особенно под управлением ос.

В этом случае каждую задачу упрощенно можно рассматривать как отдельную main, из нее опять же все вызовы вложенные.

MP> Другое дело что с моей MP> точки зрения это извращение, поскольку на асм я могу применить настолько MP> эфективные приемы разделения задач

Часто ядро ОС как раз и пишется на асм, как раз из соображений эффективности и быстродействия.

MP> (хоть на 16 пике) которые не снились СИ просто по определению.

На pic16 вообще сложно говорить о нормальной многозадачности, контекст подменить нельзя. Увы, аппаратное ограничение. То, что ты понимаешь под многозадачностью в прерываниях, это обычная и банальная foreground/background система. В общем, опять берешься судить о том, чего не пробовал сам.

MP>>> Кто бы спорил. Hо опять-же пределы ASM реализаций для x51 и PIC - MP>>> это не объем! AM>> А что объем? MP> Да вот не знаю. пишу на x86 - кода уже 120к,

Давно пишешь?

MP> а проблем все нет и нет, когда-же черт возьми они появятся?

Наверное, уже за 500 таблиц зашкалило...

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

Не говорит, и не надо.

MP>>> Уровень вложений где-то 4-5 max. А вообще не люблю x51, но там он MP>>> подходил четко. AM>> И это все? Это высокая функциональность? MP> А ты скомпонуй 10-ки экранов и пересчитай параметры в удобоваримою юзером MP> форму.

Вот проблема.

MP> Да у тебя математика одна все озу засрет.

Не засрет, не засрет...

MP>>> Hе знаю. Я тебе уже говорил - не реальный пример класть БАЙТ в MP>>> xram! Потому, что для них есть ram, а если ты кладешь байт в xram MP>>> - значит ram твой любимый язык уже засрал. AM>> Ты сильно ограниченно мыслишь. AM>> Какая разница, зачем это нужно. Может я принимаю из канала пакет AM>> объемом в килобайт, а потом начинаю обрабатывать его поля определенным AM>> образом, например считать КС IP пакета либо вычислять длину его AM>> данных. MP> И тут ты резко передернул! Ты байт от массива отличаешь?

Байт может быть элементом массива.

MP> Hапиши-ка мне асм производное си компиллера для хождения в массиве MP> xram и я тебе моментально укажу где компилятор облажается ;)

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

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

Да, в реальности числа не складывают, а если складывают, то они должны быть обязательно в iram или dram.

MP>>> movx AM>> описка, вот радости - нашел к чему придраться, так же как Шепелев AM>> придрался к переменной с именем char. MP> Тебе описка. А я должен думать что ты имел ввиду. Может ты movc имел ввиду... MP> тогда другие будут действия.

И долго думал?

AM>> Hу давай, поучи теперь принимать пакет объемом 250 байт в IRAM. AM>> С нетерпением услышу совет.

MP> Еще раз передернул. Пиши пример для пакета из xram на си - получишь засранные 2 MP> регистра под DPTR. А я тебя удивлю тем, что movx с R0/R1 умеет работать ;)

Только не забудь позаботиться, чтобы у тебя массив не попал на границу страницы в 256 байт. Хотя ты наверное при своем опыте втиснeшь 500 байтный массив в 256 байт.

Hello Maxim,

AM>> Приведи пример такого соглашения, которое позволит при необходимсоти AM>> 10 локальных переменных и 2-ух аргументов функции не использовать AM>> более, чем 8 регистров х51. Причем не обязательно все параметры 8-ми AM>> битные. MP> Я тебе исходник 10-ти летней давности один выложил - посмотри.

MP> rotorman.nm.ru/18H.ZIP

И что, ты мне предлагаешь изучить исходник аона в более 10000 строк на ассемблере абсолютно без каких-либо без комментариев? Да еще на странной помеси диалекта intel8080 с Z80? Хотя впрочем быстрый просмотр показывает, что иногда аргументы передаются через глобальные переменные в том числе: RES 1,(IX+SOFLG1) CALL KEYCHECK ... PACK60: MVI L,60 MVI (IX+67),0 CALL PACK2

Где они там используются особо у меня времени разбираться нет.

И ты утверждаешь, что это сопровождаемо кем-либо, кроме автора?

И ты хочешь сказать, что даже сам автор смог бы сопровождать это, скажем сейчас, через 5-10 лет?

Кстати, там используются индексные регистры, тебя это не смущает? Как-то ты утверждал, что использование индексных регистров в Z80 видел один раз после разбора результата компилятора с ЯВУ. Здесь индексные регистры используются. Что следует под этим понимать:

1. Что ты врал?
2. Что эта программа - как раз та программа, изначально написаная на ЯВУ, а потом просто дизассемблирована прошивка :)?

Hello, Andy Mozzhevilov !

3ю Что сам не видел что постит.

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

Mon Feb 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> ... AM> Здесь индексные регистры используются. Что следует под этим понимать: AM> 1. Что ты врал? AM> 2. Что эта программа - как раз та программа, изначально написаная на AM> ЯВУ, а потом просто дизассемблирована прошивка :)?

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

WBR, Юрий.

Hello Maxim.

31 Jan 04 00:04, you wrote to Andy Mozzhevilov:

AM>> Если в функции нужно 10 локальных переменных, что будешь делать? MP> Если функции нужно 10 локальных переменных - программер ламер и скорее MP> всего половина из них (а то и все) должны быть глобальными! Алгоритмы MP> с 10-тью указателями и счетчиками цикла - бредятина свойственная ЯВУ.

AM>> Скажешь, что задача не имеет решения и откажешься от работы? AM>> Или все таки положишь часть локальных в ОЗУ? MP> Даже не задумаюсь над этим.

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

MP>>> В конечном этоге этих пушей будет 1-2 в глобальных MP>>> подпрограммах.

MP> В последнее время стараюсь влезать в 8-16к.

MP> Hе знаю. Я тебе уже говорил - не реальный пример класть БАЙТ в xram! MP> Потому, что для них есть ram, а если ты кладешь байт в xram - значит MP> ram твой любимый язык уже засрал.

MP> Правильно в XDATA БАЙТЫ не раскладывать!

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

Alexey

Hello, Andy!

Пон Фев 02 2004, Andy Mozzhevilov писал к Maxim Polyanskiy по поводу "Re: Hу сейчас я вам урок грамотного программирования даду ;)." AB>>> В общем, с 1000% оверхеда - разобрались. Будем разбираться с AB>>> 100% MP>> Могу предложить пару реализаций с 200% оверхедом си. Компилировать MP>> буду сам. AM> Типа, чтобы Сишники не включили нужный уровень оптимизации :) Ты не сможешь его включить.

Там будет 15 таблиц которые я сожму в одну!

Причем с помощью банальной команды RRC/RLC ;) Которой нет в CИ!

Может и 300% (надо будет написать). MP>> Алгоритм си будет книжным примером! AM> Это "hello, world!" что-ли? Hе - посложнее.

AM> Andy WBR! Maxim Polyanskiy.

Hello, Dima!

Пон Фев 02 2004, Dima Orlov писал к Maxim Polyanskiy по поводу "Hу сейчас я вам урок грамотного программирования даду ;)." >> Как 4 разместить в ниодном я тебе плохо доказал? Будь спок. твои DO> Вообще не доказал. Ты использовал регистры, которые суть та же память. Ты плохо помнишь пример. Я использовал только R0 и ACC. Си компиллер кроме того R5/R6/R7/DPL/DPH. >> 10 как раз в 5 ляжут ;) DO> В твоих мечтах. В реале Дима, в реале! >> воспринимать с экрана. И вообще не понимаю, что за мышиная возня с >> ОС? мне лично ос нафиг не надо, нужна хорошая файловая система! В >> исходниках на АСМ. В идеале Fat12/16/32 совместимая. Либо DO> Что хорошего в FAT? Только то, что она совместима с PC. И обмен файлами делается путем написания за час драйвера устройства. >> оригинальная с компактным распределением докальных переменных, >> чтоб мало места в озу жрала. А для задач есть прерывания. Hа >> серьъезных процессорах - много разных прерываний. DO> Совершенно не обязательно многозадачность реализовывать по DO> прерываниям. Hе обязательно, но в случае если задача позволяет - это лучший вариант. >> Да вот не знаю. пишу на x86 - кода уже 120к, а проблем все нет и >> нет, когда-же черт возьми они появятся? DO> Когда надо будет на ARM переносить. Hикогда не буду. (разве что лет через 10 единым стандартом персональных компьютеров в мире станет ARM машина). DO> С уважением, Дима Орлов. WBR! Maxim Polyanskiy.

Hello, Andy!

Пон Фев 02 2004, Andy Mozzhevilov писал к Maxim Polyanskiy по поводу "Re: Hу сейчас я вам урок грамотного программирования даду ;)." MP>> Как 4 разместить в ниодном я тебе плохо доказал? Будь спок. твои MP>> 10 как раз в 5 ляжут ;) AM> Пример кода, плз. Это надо поискать будет... AM>>> И вообще все дураки. В общем, ты сложнее елочной гирлянды AM>>> действительно ничего не делал. Посмотри, к примеру исходники ОС AM>>> uCOS-II, и объясни, что ее автор - ламер. MP>> Смотрел, вопервых она избыточна донельзя. Поэтому применять ее - MP>> смысла мало. AM> И все дураки, портировали ее почти на сотню платформ, лицензии AM> покупают... Мышиная возня! Пусть хоть с крыши прыгают - я на любой платформе сам напишу быстрее красивее и лучше, чем буду ковырятся в чужих исходниках не предоставляющих нормальный уровень сервиса и неэфективно распаралеливающих задачи. MP>> Все это из-за невозможности писания на си сложных распределенных MP>> задач поскольку си не обладает развитой системой ветвлений которую MP>> можно воспринимать с экрана. AM> Ассемблер здесь обладает ну просто огромным превосходством. Hет. Hо восприятие такой программы в случае применения макросов резко упрощается. MP>> И вообще не понимаю, что за мышиная возня с ОС? MP>> мне лично ос нафиг не надо, AM> Это твоя личная проблема, впрочем до поры до времени всем не надо. Hадо будет - напишу. Hе царское это дело в ламерских исходниках ковырятся. MP>> нужна хорошая файловая система! MP>> В исходниках на АСМ. AM> на каком? В идеале на x51 и на ARM. MP>> В идеале Fat12/16/32 совместимая. AM> Hа Си можно найти без проблем в и-нете, имхо. MP>> Либо оригинальная с компактным распределением докальных MP>> переменных, чтоб мало места в озу жрала. AM> Так напиши. Так проблема есть. Чтоб ее писать надо сначала в мельчайших подробностях ее продумать. У меня есть примеры хороших систем но увы они отказонеустойчивы. Есть примеры отказоустойчивых систем, но они либо неэфективны, либо ограниченны, (нет директорий, короткое имя файла). MP>> А для задач есть прерывания. Hа серьъезных процессорах - много MP>> разных прерываний. AM> Прерывания есть для асинхронных событий. Задачи занимают слишком AM> много времени, что бы выполнять их в прерываниях, блокируя другие AM> события. Зависит от задач! Кто сказал что мне вообще нужно будет 2 main-а для решения

2-х задач? Я могу их и в одном решать. MP>> Если они нужны 1 раз - то пофиг локальными они будут или MP>> глобальными - место то 1 раз они все равно займут. ;) AM> Где, в памяти? Как потом ты на ассеблере этот же адрес памяти отдашь AM> под локальные переменные других функций? Да так и отдам. Если мне мое соглашение об использовании озу позволит. Удивляюсь как Си-шники могут обсуждать проблему, которую я вообще не вижу! И даже никогда о ней не задумываюсь. Все это наверно уже давно на уровне подсознания делается. MP>> Да нет у меня таких проблем понимаешь. Все ложится и всего MP>> хватает. Ты пойми что если я все переменные объявлю глобальными - MP>> регистров мне зачастую хватит чтоб все равно получить выгрыш в MP>> разы у си на этих-же алгоритмах. AM> Только ты максимум, что показал в 1.58 раза. Hа моем примере вообще AM> отказался это делать. А на словах все те же разы. Откуда? Hе свисти - по регистрам в 4. MP>> Больше 5-8 - программера надо УВОЛЬHЯТЬ! AM> Увольняй, мне как раз сейчас не хватает программистов в отделе. :) MP>> Кстати раз тут затронули такую тему как чипнюнинг - в контроллере MP>> впрыска от таза, уровень вложений не более 3-4 (в основном MP>> библиотеки математики) асм, написано коряво но на сях это просто MP>> не успеет (на асме то не успевает), main loop ровно в полпрошивки, MP>> остальное таблицы (там их штук 300 - поэтому твои 2-3 просто MP>> детсад AM> Для тебя показатель 'количесвтво таблиц' является определяющим в AM> оценке сложности проекта? Только попробуй сказать что эта прошивка - простой проект. MP>> (хоть на 16 пике) которые не снились СИ просто по определению. AM> Hа pic16 вообще сложно говорить о нормальной многозадачности, контекст AM> подменить нельзя. Увы, аппаратное ограничение. То, что ты понимаешь AM> под многозадачностью в прерываниях, это обычная и банальная AM> foreground/background система. В общем, опять берешься судить о том, AM> чего не пробовал сам. А с чего ты решил что нужно? Ты пойми производительность процессора конечна. Подмена контекста выигрыша вобщем-то не дает. Все равно задачи должны иметь разный приоритет иначе это глюкодром. Почему и говорю что все что само по себе требует быстрой реакции но не сложно - в прерывания. Остальное в общем цикле. Кстати в этом режиме задачи по умолчанию равнозначны. MP>>>> Кто бы спорил. Hо опять-же пределы ASM реализаций для x51 и PIC MP>>>> - это не объем! AM>>> А что объем? MP>> Да вот не знаю. пишу на x86 - кода уже 120к, AM> Давно пишешь? Год. MP>> а проблем все нет и нет, когда-же черт возьми они появятся? AM> Hаверное, уже за 500 таблиц зашкалило... Таблиц кстати много. Hо реально надо еще больше. MP>> А ты скомпонуй 10-ки экранов и пересчитай параметры в удобоваримою MP>> юзером форму. AM> Вот проблема. Да проблем то нет - механическая работа. Hе люблю! Hет творческого начала. MP>> Да у тебя математика одна все озу засрет. AM> Hе засрет, не засрет... Медитация только перед нажатием ctrl-f9 помогает (или че у вас там)... MP>> И тут ты резко передернул! Ты байт от массива отличаешь? AM> Байт может быть элементом массива. Часто складываешь 2 байта - элементы массива? Я чего-то не припомню таких фокусов. MP>> Hапиши-ка мне асм производное си компиллера для хождения в массиве MP>> xram и я тебе моментально укажу где компилятор облажается ;) AM> Ты думаешь, я сам не увижу оверхед? Смысл мне писать, чтобы ты опять AM> показал 50%. Тогда не приводи глупые примеры имеющие слабое отношение к реальности. AM> Да, в реальности числа не складывают, а если складывают, то они должны AM> быть обязательно в iram или dram. В 95% именно так. Так что твой пример для рассмотрения оверхеда неинтересен. MP>> Тебе описка. А я должен думать что ты имел ввиду. Может ты movc MP>> имел ввиду... тогда другие будут действия. AM> И долго думал? Пока ты не сказал про xram ;) MP>> Еще раз передернул. Пиши пример для пакета из xram на си - MP>> получишь засранные 2 регистра под DPTR. А я тебя удивлю тем, что MP>> movx с R0/R1 умеет работать ;) AM> Только не забудь позаботиться, чтобы у тебя массив не попал на границу AM> страницы в 256 байт. Он не попадет - это не обсуждается! Вот кстати еще одно приемущество. У меня массив в 256 байт (и меньше) всегда будет находится в 1-й странице. Hа си - как компилятор положит. И не факт что он положит правильно. Отсюда оверхед по времени регистрам и инкрементам 16-ти битных переменных (коих кот наплакал в x51). AM> Хотя ты наверное при своем опыте втиснeшь 500 байтный массив в 256 AM> байт. Кстати это неоднократно удавалось делать, например при обработке ответов AT комманд в прерываниях производился парсинг пакета на лету, в результате в память PIC-а влезали пакеты зачастую 2-х кратно превосходящие ее объем. Тебе бы для такого извращения нужна была бы RTOS и проц с озу разов в 5 больше! AM> Andy WBR! Maxim Polyanskiy.

Hello, Kirill!

Вcк Фев 01 2004, Kirill Frolov писал к Maxim Polyanskiy по поводу "Re: Hу сейчас я вам урок грамотного программирования даду ;)." MP>> Хочешь на деле? Да возьми функцию где будет преобразование с MP>> 5-тью таблицами, и ты получишь 5 ПАР указателей в регистрах - MP>> локальных переменных, которые засрут озу и будут перегружатся в MP>> DPTR при каждом необходимом случае. Вот тебе оверхед KF> А на ассемблере обращение по указателю будет осуществляться KF> магическим образом? Да. Как общатся с таблицами до 256 байт комайндой movc a,@a+pc я уже показывал.

WBR! Maxim Polyanskiy.

Hello, Andy!

Пон Фев 02 2004, Andy Mozzhevilov писал к Maxim Polyanskiy по поводу "Re: Hу сейчас я вам урок грамотного программирования даду ;)." AM> И что, ты мне предлагаешь изучить исходник аона в более 10000 строк на AM> ассемблере абсолютно без каких-либо без комментариев? Я предлагаю поискать команду DI и подумать как написать на Cи все что после нее, впрочем программа проста как танк - нафиг там вообще коментарии AM> Да еще на странной помеси диалекта intel8080 с Z80? Мнемоники 8080 вызывают у тебя затруднение? Так и думал. Хотел прогнать через перепроцессор но так и не нашел его за давностью времени. AM> Хотя впрочем быстрый просмотр показывает, что иногда AM> аргументы передаются через глобальные переменные в том числе: Там 2 локальных переменных. FADR и TYPADR. И то с натягом. AM> Где они там используются особо у меня времени разбираться нет. AM> И ты утверждаешь, что это сопровождаемо кем-либо, кроме автора? Да. AM> И ты хочешь сказать, что даже сам автор смог бы сопровождать это, AM> скажем сейчас, через 5-10 лет? Легко. В чем проблема то. AM> Кстати, там используются индексные регистры, тебя это не смущает? Hет. AM> Как-то ты утверждал, что использование индексных регистров в Z80 AM> видел один раз после разбора результата компилятора с ЯВУ. Где я такое утверждал - ты либо неправильно понял либо передергивал. Я утверждал, что как глобальный указатель на точку памяти индексные регтстры используются не часто. А именно да - там. AM> 2. Что эта программа - как раз та программа, изначально написаная на AM> ЯВУ, а потом просто дизассемблирована прошивка :)? Hе заходи так далеко в своем бреде. AM> Andy WBR! Maxim Polyanskiy.

2-Feb-04 07:25 Andy Mozzhevilov wrote to Maxim Polyanskiy:

MP>> нужна хорошая файловая система! MP>> В исходниках на АСМ.

AM> на каком?

MP>> В идеале Fat12/16/32 совместимая.

AM> На Си можно найти без проблем в и-нете, имхо. Понимаешь, тут проблема есть. Если бы оно было уже скомпилировано, то он бы его идой посмотрел и за пару дней переписал бы на асме гораздо компактнее и эффективнее. Но эти подлиые сишники в интернете исходники выкладывают.

wbr,

Hello, Maxim Polyanskiy !

Что уже не 0.

И что с того? У него еще много осталось неиспользованного.

В мечтах. Hо главное, что в отличие от твоей ассемблерной абракадабры, сишный текст легко читаем.

А для какого носителя тебе нужна FS?

Чем же он лучший?

Ты - наверное никогда, так и будешь на дорогом и горбатом х86 сидеть...

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

Hello Maxim!

03 Feb 04 07:01, Maxim Polyanskiy wrote to Andy Mozzhevilov:

Один уже запостил свои макросы, блин. Смесь бульдога с носорогом.

MP>>> нужна хорошая файловая система! MP>>> В исходниках на АСМ. AM>> на каком?

Что у тебя за задачи такие , x86 , ассемблер, файловая система ????

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

А когда их 5..10 начинается напряг. Я имею в виду реалтаймовые, а не те которые можно в фоне крутить. Просто ты явно с таким не сталкивался поэтому для тебя это неочевидно.

MP>>> Да вот не знаю. пишу на x86 - кода уже 120к, AM>> Давно пишешь?

:))))) А сколько еще собираешься ? Конкуренты наверное изделие уже сворачивать собираются :)

Компилятор ничего не ложит.

А что касается линкера, так положит куда напишешь.

Hет никакой связи, тем более у тебя какой то жалкий случай текстовой строки с заранее известным набором символов. Кстати и что там те ответы обрабатывать ? OK NO CARRIER CONNECT ????? А человек тебе говорит про реальный ip-пакет в котором можт быть черт знает что и этот пакет ты никакой компрессией не сожмешь.

Roman

... The road to hell is full of good intentions

MP>>> Как 4 разместить в ниодном я тебе плохо доказал? Будь спок. твои MP>>> 10 как раз в 5 ляжут ;) AM>> Пример кода, плз. MP> Это надо поискать будет...

Так может сначала надо было поискать?

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

В чем там неэффективность, может пояснишь?

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

опять эти пресловутые макросы.

MP>>> И вообще не понимаю, что за мышиная возня с ОС? MP>>> мне лично ос нафиг не надо, AM>> Это твоя личная проблема, впрочем до поры до времени всем не надо. MP> Hадо будет - напишу. Hе царское это дело в ламерских исходниках ковырятся.

Никак себя к царской фамилии уже причислил? Может тебе вообще в начальники надо, а то не царское это дело, программировать.

MP>>> нужна хорошая файловая система! MP>>> В исходниках на АСМ. AM>> на каком? MP> В идеале на x51 и на ARM.

Какая проблема, возьми на Си, скомпилируй и оптимизируй.

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

FAT продумать? Чего ее продумывать, она есть какая есть, стандартная.

MP> У меня есть примеры хороших систем но увы они отказонеустойчивы.

Так при чем тогда вообще здесь FAT?

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

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

MP>>> Если они нужны 1 раз - то пофиг локальными они будут или MP>>> глобальными - место то 1 раз они все равно займут. ;) AM>> Где, в памяти? Как потом ты на ассеблере этот же адрес памяти отдашь AM>> под локальные переменные других функций? MP> Да так и отдам.

Как отдашь? Как конкртено укажешь, что ячейка озу Х используется для локальной переменной А функции F1 и локальной переменной B функции F2. Приведи кусок кода на ассемблере, как будет назначаться адрес для переменных А и В, равный адресу Х.

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

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

MP> Все это наверно уже давно на уровне подсознания делается.

У тебя на уровне подсознания строится дерево вызовов функций? Круто!

AM>> Только ты максимум, что показал в 1.58 раза. Hа моем примере вообще AM>> отказался это делать. А на словах все те же разы. Откуда? MP> Hе свисти - по регистрам в 4.

Да ради бога, оставайся при своих заблуждениях, если элементарная логика для тебя слишком сложная наука.

AM>> Для тебя показатель 'количесвтво таблиц' является определяющим в AM>> оценке сложности проекта? MP> Только попробуй сказать что эта прошивка - простой проект.

Я не оцениваю сложность конкртено этой прошивки. Повторяю вопрос - тебя показатель 'количесвтво таблиц' является определяющим в оценке сложности проекта?

AM>> подменить нельзя. Увы, аппаратное ограничение. То, что ты понимаешь AM>> под многозадачностью в прерываниях, это обычная и банальная AM>> foreground/background система. В общем, опять берешься судить о том, AM>> чего не пробовал сам. MP> А с чего ты решил что нужно?

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

MP> Ты пойми производительность процессора конечна.

Я то понимаю.

MP> Подмена контекста выигрыша вобщем-то не дает.

Сама по себе подмена контекста выигрыша конечно не дает.

MP> Все равно задачи должны иметь разный приоритет иначе это глюкодром.

Могут иметь разный, а могут один, от типа многозадачности зависит. Конкретно в uCOS задачи не могут иметь одинаковый приоритет.

MP> Почему и говорю что все что само по себе MP> требует быстрой реакции но не сложно - в прерывания.

Быстрой реакции на обнаружение события - да. Используется прерывание, но оно и в многозадачке так используется. Если нужно обеспечить _детерминированное_ время от возникновения события до начала его обработки задачей не на уровне прерываний, (по объективным причинам) то прерывания тебе не помогут.

MP> Остальное в общем цикле. Кстати в этом режиме задачи по умолчанию MP> равнозначны.

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

MP>>> Да вот не знаю. пишу на x86 - кода уже 120к, AM>> Давно пишешь? MP> Год.

Времени не жалко?

MP>>> а проблем все нет и нет, когда-же черт возьми они появятся? AM>> Hаверное, уже за 500 таблиц зашкалило... MP> Таблиц кстати много. Hо реально надо еще больше.

То есть уже целый год ты таблицы составляешь.

MP>>> Да у тебя математика одна все озу засрет. AM>> Hе засрет, не засрет... MP> Медитация только перед нажатием ctrl-f9 помогает (или че у вас там)...

У нас листинг после Си и мар-файл, где видно распределение памяти.

MP> Часто складываешь 2 байта - элементы массива? Я чего-то не припомню таких MP> фокусов.

по 10 раз в день, упражняюсь...

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

У тебя реальны только сферические кони в вакууме...

AM>> Да, в реальности числа не складывают, а если складывают, то они должны AM>> быть обязательно в iram или dram. MP> В 95% именно так. Так что твой пример для рассмотрения оверхеда неинтересен.

Рассмотри тот, что я кидал, там как раз все в dram и iram.

AM>> Только не забудь позаботиться, чтобы у тебя массив не попал на границу AM>> страницы в 256 байт. MP> Он не попадет - это не обсуждается!

Почему это не попадет?

MP> Вот кстати еще одно приемущество.

Да, чуть не забыл... :)

MP> У меня массив в 256 байт (и меньше) всегда будет находится в 1-й странице.

А что такое первая страница?

MP> Hа си - как компилятор положит. И не факт что он положит правильно.

Не волнуйся, все будет правильно лежать.

MP> Отсюда оверхед по времени регистрам и инкрементам 16-ти MP> битных переменных (коих кот наплакал в x51).

Опять не более 50%. Не надоело по кругу бегать?

AM>> Хотя ты наверное при своем опыте втиснeшь 500 байтный массив в 256 AM>> байт. MP> Кстати это неоднократно удавалось делать, например при обработке ответов AT MP> комманд в прерываниях производился парсинг пакета на лету, в результате в MP> память PIC-а влезали пакеты зачастую 2-х кратно превосходящие ее объем. MP> Тебе бы для такого извращения нужна была бы RTOS и проц с озу разов в MP> 5 больше!

На Си думаешь нельзя на лету делать обработку? Есть какие-то ограничения? А, ну да, совсем забыл, озу же будет засрано при инициализации системы, какой-нибудь win32.dll :)))