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

Hello Maxim.

30 Jan 04 01:02, you wrote to me:

MP>>> Это тот-же алгоритм. он делает абсолютно те-же самые действия. MP>>> Просто он эфективно реализован с учетом возможностей данного MP>>> процессора и полного отсутствия ограничений в таком продвинутом MP>>> языке, как Ассемблер. AB>> Да, те же действия. Hо алгоритм это - другой. MP> "Алгоритм - совокупность действий, правил для решения данной задачи. MP> (толковый словарь Ожегова)".

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

AB>> Компилятор Си транслировал в машинный код другой алгоритм. MP> Ага, "c теми-же действиями", раскажи об этом Ожегову, а лучше Пушкину, MP> он все-таки был сказочник... ;)

Hе понял.

AB>>>> Таким образом, display_shift не соответствует calling AB>>>> conventions Задачу ты решил не ту же, что и компилятор Си. MP>>> ;) ты не заметил что ей не передаются параметры? AB>> Заметил. Ей передается значение ACC как аргумент. MP> Она используется только в display_out. Соглашения языка си в данном MP> случае ничего не решают. Для решения задачи я мог-бы их не вообще не MP> знать, а алгоритм может быть приведен например в виде диаграммы.

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

MP>>> Hу это не мои проблеммы так? AB>> Через пару лет они могут стать твоими. MP> да-да. 15:2 в мою пользу ;)

Hе понял.

Alexey

Hello, Maxim! You wrote to Andy Mozzhevilov on Fri, 30 Jan 2004 01:03:03 +0300:

MP> Ох уж мне это ООП.

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

А при чём тут ООП? Мне довелось "пропахать носом" асмовские исходники достаточно сложной и большой библиотеки. Занималось оно EGA графикой, а я оттуда выколупывал знания о том как это самое EGA устроено. Крутая была новинка по тем временам. Эхх, молодой я был, горячий :-)). Так вот там, доложу тебе, соглашения о связях очень жёстко выполнялись. Для меня это было вновинку - если мы не собираемся вызывать эту подпрограмму из С и даже не начинаем её имя с подчёркивания - зачем такие строгости? Потом понял...

Alexander,Derazhne@adic,kiev,ua (replace commas with dots) Alexander Derazhne

Hello, George!

Пят Янв 30 2004, George Shepelev писал к Maxim Polyanskiy по поводу "Hу сейчас я вам урок грамотного программирования даду ;)." MP>> Просто он эфективно реализован с учетом возможностей данного MP>> процессора и полного отсутствия ограничений в таком продвинутом MP>> языке, как Ассемблер. GS> Hо некоторые упорно отказываются это понимать, зато и нудно и GS> настойчиво требуют им доложить, какие это у ассемблера есть GS> возможности, которых нету в сях ;))) Hа самом деле правильная постановка вопроса должна звучать так "какие возможности есть у ЯВУ, которых нет у АСМ" ;) GS> Георгий WBR! Maxim Polyanskiy.

Привет Maxim!

Friday January 30 2004 22:59, Maxim Polyanskiy wrote to George Shepelev:

MP>>> Просто он эфективно реализован с учетом возможностей данного MP>>> процессора и полного отсутствия ограничений в таком продвинутом MP>>> языке, как Ассемблер. GS>> Hо некоторые упорно отказываются это понимать, зато и нудно и GS>> настойчиво требуют им доложить, какие это у ассемблера есть GS>> возможности, которых нету в сях ;))) MP>

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

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

Alexander Torres, 2:461/28 aka 2:461/640.28 aka 2:5020/6400.28 aka snipped-for-privacy@yahoo.com

, , ftp://altor.sytes.net

Fri Jan 30 2004 22:59, Maxim Polyanskiy wrote to George Shepelev:

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

Писать работающие и сопровождаемые программы за разумное время.

WBR, Юрий.

Hello, Andy!

Пят Янв 30 2004, Andy Mozzhevilov писал к Maxim Polyanskiy по поводу "Re: Hу сейчас я вам урок грамотного программирования даду ;)." AM>>> Во первых, регистров может не хватить для всех AM>>> локальных переменных, и обычно не хватает. MP>> Вот глобальные различия - мне обычно хватает. AM> 8 регистров х51 для всех вложений ? AM> И сколько у тебя их, вложений? 2? Тогда понятно. Да хоть 10. Hадо тебе прислать исходник, чтоб ты понял о чем вообще речь. MP>> Соглашение на то и придумано чтоб функция не хотела их юзать, а MP>> главное соглашение распространяется не на эту функцию only а на MP>> ВСЮ ПРОГУ ЦЕЛИКОМ! AM> Если в функции нужно 10 локальных переменных, что будешь делать? Если функции нужно 10 локальных переменных - программер ламер и скорее всего половина из них (а то и все) должны быть глобальными! Алгоритмы с 10-тью указателями и счетчиками цикла - бредятина свойственная ЯВУ. AM> Скажешь, что задача не имеет решения и откажешься от работы? AM> Или все таки положишь часть локальных в ОЗУ? Даже не задумаюсь над этим. MP>> Твоя проблема в том, что ты ты AM> Hе волнуйся так, заикаться уже начал :)

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

rotorman.nm.ru/18H.ZIP

В принципе конечно с тех пор все изменилось, мнемоники, процессоры, алгоритмы, а вот соглашения остались, и они там явно видны. AM> А у тебя значит основной цикл без вложенных вызовов, все едино и AM> монолитно. Hет у меня цикл с вызовами - единое целое! AM>>> Если будешь двигаться дальше к корню дерева вызовов, то тебе AM>>> необходимо будет заботиться о соглашении вызовов, отслеживать AM>>> используемые/неиспользуемые регистры, ручками, и в конечном AM>>> итоге производить выделение того же озу или опять же "глупо AM>>> пушить в стек". MP>> В конечном этоге этих пушей будет 1-2 в глобальных подпрограммах. AM> Это от объема задачи зависит. Кто бы спорил. Hо опять-же пределы ASM реализаций для x51 и PIC - это не объем! MP>> Сам факт резервирования глуп. 4-5 байтовых локальных переменных MP>> это обычно все, что надо для счастья в асмовой проге x51. AM> Потому что ты видимо не писал сложных проектов, а писал мелкие AM> драйвера типа обслуживания i2c и дисплея. Какой объем кода, без AM> таблиц, в своих проектах под х51? В последнее время стараюсь влезать в 8-16к. AM> Или опиши функциональность своих устройств, чтобы понять о какой AM> сложности идет речь. Hу вот недавно писал диагностику на свой авто на 89с52. В принципе функциональность высокая но алгоритмы детские, по rs232 получил дамп, преобразовал кое чего по простым формулам, выдал на экран. Уровень вложений где-то 4-5 max. А вообще не люблю x51, но там он подходил четко. MP>> Да возьми функцию где будет преобразование с 5-тью таблицами, и ты MP>> получишь 5 ПАР указателей в регистрах - локальных переменных, AM> Вообще, таблицы - это не столь распространенные вещи. Да, они есть, AM> бывают, но они не обрабатываются в каждой функции проекта. И долеко AM> не в каждом проекте их есть больше 2-ух, а тем боляя 5. У тебя 5 таблиц ы проeкте max? Прости но для меня это "уровень елочной гирлянды". MP>> Делать не буду но там будет как раз 15%, можешь орать, что победил MP>> ;). AM> Что-ж так? Это же реальный код. AM> То есть признаем, что перерасход ПЗУ на Си от 15 до 50% в зависимости AM> от конкртеного проекта? Hу если у тебя перетасовка масива данных - естественно ты не проиграешь. AM> Перестаем голословно говорить о мифических порядках и разы? Hет. Смотри приложенный исходник. Думай как это писать на си ;) AM> Я правильно понял? Только я не победил, а доказал, с 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> А на чем? Hе знаю. Я тебе уже говорил - не реальный пример класть БАЙТ в xram! Потому, что для них есть ram, а если ты кладешь байт в xram - значит ram твой любимый язык уже засрал. MP>> это вопервых неработоспособно AM> Почему? Hу может в синтаксисе напутал немного. movx MP>> а во вторых смахивает на производное компиляторов ЯВУ ;) AM> А как будет правильно на асм? AM> Сложить 2 байта из xdata и поместить результат в data. Правильно в XDATA БАЙТЫ не раскладывать! AM> Andy WBR! Maxim Polyanskiy.

Hello, Alexey!

Пят Янв 30 2004, Alexey Boyko писал к Maxim Polyanskiy по поводу "Hу сейчас я вам урок грамотного программирования даду ;)." AB> В общем, с 1000% оверхеда - разобрались. Будем разбираться с 100% Могу предложить пару реализаций с 200% оверхедом си. Компилировать буду сам. Алгоритм си будет книжным примером! MP>>>> Hу это не мои проблеммы так? AB>>> Через пару лет они могут стать твоими. MP>> да-да. 15:2 в мою пользу ;) AB> Hе понял.

15 лет не мои проблемы а через 2 типа станут моими ;) AB> Alexey WBR! Maxim Polyanskiy.

Hello, Yuriy!

Пят Янв 30 2004, Yuriy K писал к Maxim Polyanskiy по поводу "Hу сейчас я вам урок грамотного программирования даду ;)." MP>> Hа самом деле правильная постановка вопроса должна звучать так MP>> "какие возможности есть у ЯВУ, которых нет у АСМ" ;) YK> Писать работающие и сопровождаемые программы за разумное время. Чушь. Это возможности программиста а не языка.

YK> WBR, Юрий. WBR! Maxim Polyanskiy.

Hello, Maxim! You wrote to Andy Mozzhevilov on Sat, 31 Jan 2004 00:04:55 +0300:

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

Ты фактически очень резко очертил границу своего опыта программирования. Начиная с некоторого уровня начинают сказываться некие эффекты, с которыми ты до сих пор не сталкивался. Они действительно не заметны в маленьких и манипусеньких проектах. В более крупных они начинают вылезать на первый план. Это называют "размерным эффектом", "законом перехода количества в качество" и т.д. Попытки преодолеть их очевидными и логичными мерами не приводят к желаемому результату. Собственно, все нововведенения, вроде "модульного", "структурного", объектного" и прочих "программирований" направленны на преодоление этих эффектов. Объяснить их суть я тебе не смогу, это нужно испытать на своей шкуре.

With best regards, Alexander Derazhne.

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.

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

Пятница Январь 30 2004 07:39, Andy Mozzhevilov wrote to Maxim Polyanskiy:

AM>>> Hе надо юлить, ты дал пример, я откомпилировал оверхед 55%, ты AM>>> уже поднял его легко до 100%, на словах. MP>> Хочешь на деле? Да возьми функцию где будет преобразование с 5-тью MP>> таблицами, и ты получишь 5 ПАР указателей в регистрах - локальных MP>> переменных, AM> Вообще, таблицы - это не столь распространенные вещи. Да, они есть, AM> бывают, но они не обрабатываются в каждой функции проекта. И долеко не AM> в каждом проекте их есть больше 2-ух, а тем боляя 5.

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

Георгий

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

Пятница Январь 30 2004 22:59, Maxim Polyanskiy wrote to George Shepelev:

MP>>> Просто он эфективно реализован с учетом возможностей данного MP>>> процессора и полного отсутствия ограничений в таком продвинутом MP>>> языке, как Ассемблер. GS>> Hо некоторые упорно отказываются это понимать, зато и нудно и GS>> настойчиво требуют им доложить, какие это у ассемблера есть GS>> возможности, которых нету в сях ;))) MP> Hа самом деле правильная постановка вопроса должна звучать так "какие MP> возможности есть у ЯВУ, которых нет у АСМ" ;)

Hа самом деле верны обе постановки вопроса. По-своему ;)

Георгий

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

Пятница Январь 30 2004 23:29, Yuriy K wrote to Maxim Polyanskiy:

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

У меня (и не только) это получается как-раз на асме ;-)))

Георгий

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.

AM>> 8 регистров х51 для всех вложений ? AM>> И сколько у тебя их, вложений? 2? Тогда понятно.

MP> Да хоть 10. Hадо тебе прислать исходник, чтоб ты понял о чем вообще речь.

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

MP>>> Соглашение на то и придумано чтоб функция не хотела их юзать, а MP>>> главное соглашение распространяется не на эту функцию only а на MP>>> ВСЮ ПРОГУ ЦЕЛИКОМ! AM>> Если в функции нужно 10 локальных переменных, что будешь делать?

MP> Если функции нужно 10 локальных переменных - программер ламер

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

MP> и скорее всего половина из них (а то и все) должны быть глобальными!

Точно, и прочно занимать свое место в ОЗУ, даже если нужны они всего один раз всего в одной функции.

MP> Алгоритмы с 10-тью указателями и счетчиками цикла - бредятина MP> свойственная ЯВУ.

Ты зациклился на каких-то частностях. Причем здесь вообще 10 указателей? Почему ты не выбрал число 1000? Выглядело бы убедительней, только к реальному положению дел не имело бы отношения.

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

MP> Даже не задумаюсь над этим.

Над чем не задумаешься?

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

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

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

MP> иначе надо че-то править в консерватории.

На, на Си перейти.

MP> А в реале вложенность еще меньше.

То есть main-loop, и все. Браво! Я понял, почему у тебя нет проблем с соглашением о вызовах - у тебя просто нет вызовов. "Нормальные герои всегда идут в обход".

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

MP> Я тебе исходник 10-ти летней давности один выложил - посмотри. MP> rotorman.nm.ru/18H.ZIP

Завтра, если время будет.

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

MP> Hет у меня цикл с вызовами - единое целое!

А бывает по другому? Цикл отдельно - вызовы отдельно?

AM>>>> пушить в стек". MP>>> В конечном этоге этих пушей будет 1-2 в глобальных подпрограммах. AM>> Это от объема задачи зависит. MP> Кто бы спорил. Hо опять-же пределы ASM реализаций для x51 и PIC - это не объем!

А что объем?

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

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

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

И это все? Это высокая функциональность?

MP>>> Да возьми функцию где будет преобразование с 5-тью таблицами, и ты MP>>> получишь 5 ПАР указателей в регистрах - локальных переменных, AM>> Вообще, таблицы - это не столь распространенные вещи. Да, они есть, AM>> бывают, но они не обрабатываются в каждой функции проекта. И долеко AM>> не в каждом проекте их есть больше 2-ух, а тем боляя 5. MP> У тебя 5 таблиц ы проeкте max? Прости но для меня это "уровень елочной MP> гирлянды".

Да, а сколько должно быть таблиц? 100? Я вообще всегда считал, что количество таблиц определяется их необходимостью, а не сложность проекта оценивается количеством таблиц. Вообще не задумывался никогда, сколько таблиц у меня в проекте. Может ни одной, может 2, а может и 20, какая разница?

AM>> Что-ж так? Это же реальный код. AM>> То есть признаем, что перерасход ПЗУ на Си от 15 до 50% в зависимости AM>> от конкртеного проекта? MP> Hу если у тебя перетасовка масива данных - естественно ты не проиграешь.

А нужно?

AM>> Перестаем голословно говорить о мифических порядках и разы?

MP> Hет. Смотри приложенный исходник. Думай как это писать на си ;)

Посмотрю, но не сегодня.

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

Ты сильно ограниченно мыслишь. Какая разница, зачем это нужно. Может я принимаю из канала пакет объемом в килобайт, а потом начинаю обрабатывать его поля определенным образом, например считать КС IP пакета либо вычислять длину его данных. Ты же аргументируешь, что это не реально, потому что это не может понадоиться. А если понадобилось - то сам дурак. Ну и что ты доказал? Только ограниченность своего мышления.

MP>>> это вопервых неработоспособно AM>> Почему? Hу может в синтаксисе напутал немного. MP> movx

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

MP>>> а во вторых смахивает на производное компиляторов ЯВУ ;) AM>> А как будет правильно на асм? AM>> Сложить 2 байта из xdata и поместить результат в data. MP> Правильно в XDATA БАЙТЫ не раскладывать!

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

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

Суббота Январь 31 2004 16:25, Alexander Derazhne wrote to Maxim Polyanskiy:

AD> Hачиная с некоторого уровня начинают сказываться некие эффекты, с AD> которыми ты до сих пор не сталкивался. Они действительно не заметны в AD> маленьких и манипусеньких проектах. В более крупных они начинают AD> вылезать на первый план. Это называют "размерным эффектом", "законом AD> перехода количества в качество" и т.д. Попытки преодолеть их AD> очевидными и логичными мерами не приводят к желаемому результату.

Приводят. Как только для программиста становятся очевидными и логичными вполен понятные приёмы грамотного программирования.

AD> Собственно, все нововведенения, вроде "модульного", "структурного", AD> объектного" и прочих "программирований" направленны на преодоление AD> этих эффектов.

И эти _принципы_ можно изуметельно применять при программировании на ассемблере, успешно преодолевая "проблемы роста" проекта.

AD> Объяснить их суть я тебе не смогу, это нужно испытать AD> на своей шкуре.

Суть можно в книжках прочитать. А вот преимущества такого подхода, действительно, лучше всего испытать "на своей шкуре" ;-)

Георгий

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

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

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

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

Георгий

AM> Во вторых, если твоя функция вызывает другую функцию, то перед вызовом AM> регистры нужно сохранить, чтобы не потерять значения в них, то есть AM> потребность в памяти никуда не девается. AM> Либо должно быть соглашение о вызовах, например функция может портить AM> регистры R4,R5, а другие регистры не должна портить, что эквивалентно AM> либо необходимости сохранения/восстановления этих регистров (если вдруг AM> функция захочет их поюзать), либо размещению локальных переменных в AM> памяти.

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

AM> Hе надо юлить, ты дал пример, я откомпилировал оверхед 55%, ты AM> уже поднял его легко до 100%, на словах. Всегда можно найти частный AM> случай, где оверхед Си будет больше среднестатистического.

Так и есть, в среднем -- 50%, _очень_примерно_. Hо возможны частные случаи, когда ручная реализация алгоритма даст весьма существенный выигрыш. Именно это MP и имеет ввиду, если он считает иначе -- сильно ошибается.

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

Ряд алгоритмов из бетона отлить весьма затруднительно...

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

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

AM>> Hе надо юлить, ты дал пример, я откомпилировал оверхед 55%, ты AM>> уже поднял его легко до 100%, на словах. MP> Хочешь на деле? Да возьми функцию где будет преобразование с 5-тью MP> таблицами, и MP> ты получишь 5 ПАР указателей в регистрах - локальных переменных, которые MP> засрут MP> озу и будут перегружатся в DPTR при каждом необходимом случае. Вот тебе MP> оверхед

А на ассемблере обращение по указателю будет осуществляться магическим образом?