Hello, Vladimir Chekin !
Это зависит. Я когда на асме для х86 писал, оформлял локальные переменные, передачу параметров и все такое также, как это на этом процессоре делают ЯВУ, благо в ассемблер для этого готовые макросы встроены. Компилированный стек в рукопашную не сильно сделаешь...
С уважением, Дима Орлов.
MP>>> локальных переменных, которые засрут озу и будут перегружатся в MP>>> DPTR при каждом необходимом случае. Вот тебе оверхед KF>> А на ассемблере обращение по указателю будет осуществляться KF>> магическим образом? MP> Да. Как общатся с таблицами до 256 байт комайндой movc a,@a+pc я уже MP> показывал.
В данном случае указатель сохраняется в PC. Где чёрная магия?
Hello, Vladimir!
Втp Фев 03 2004, Vladimir Chekin писал к Andy Mozzhevilov по поводу "Re: Hу сейчас я вам урок грамотного программирования даду ;)." AM>> Как конкртено укажешь, что ячейка озу Х используется для AM>> локальной переменной А функции F1 и локальной переменной B AM>> функции F2. VC> Странно, что ты задаёшь такой вопрос...
Спасибо что объяснил - все именно так и есть (исключая лирику про ветер). я уже задолбался генерировать ему килобайты очевидных вещей, которые к тому-же ему лично нафиг не нужны, и пораждают мегабайты дибильных вопросов.
VC> Владимир Чекин WBR! Maxim Polyanskiy.
Hello, Andy!
Сpд Фев 04 2004, Andy Mozzhevilov писал к Vladimir Chekin по поводу "Re[2]: Hу сейчас я вам урок грамотного программирования даду ;)." AM> Я так понял, у него переменные могут быть или только глобальными, или AM> только в регистрах. Господи - наконец-то... Для понимания этого тебе был дан исходник в котором все соглашения о вызовах и памяти видны, чтоб не объяснять 10 раз, что, почему и как. Правда ты там почему-то стал искать не соглашения а коментарии, и придиратся к мнемоникам. AM> Andy WBR! Maxim Polyanskiy.
Wed Feb 04 2004 07:15, Maxim Polyanskiy wrote to Roman Gorbunov:
MP> У вас странное понимание слова реалтаймовые. Логика многозадачности MP> (какая бы не была) жрет ресурс настолько сильно
Hасколько? Циферку приведи, какого ресурса и сколько жрет.
MP> что реалтаймовые задачи MP> выгодно решать на 2-х гораздо более дешевых и более медленных cpu.
:-)))
MP>>>>> Да вот не знаю. пишу на x86 - кода уже 120к, AM>>>> Давно пишешь? >>> Год. RG>> Конкуренты наверное изделие уже сворачивать собираются :) MP> Конкурентов нет - прога уникальна. И кстати - непродаецца!!! ;)
С этого бы и начинал. Мы же не хобби обсуждаем, а работу.
WBR, Юрий.
Wed Feb 04 2004 07:25, Maxim Polyanskiy wrote to Andy Mozzhevilov:
MP> В том, что попытка решения 2-х настоящих реалтаймовых задач работающих в MP> упоре производительности 2-х мифических процессоров, требует чтоб MP> результирующий управляемый RTOS процессор имел ПЯТHАДЦАТИКРАТHО! большую MP> производительность.
Э-э, а можно узнать с какого потолка была взята эта цифра?
WBR, Юрий.
void (* jump0)(void) = (void *)0;
jump0();
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 у меня используется только кооператичная многозадачность.
х51 в этом проекте применялся по историческим причинам, когда нужно было добавить IP-соску к существующему устройству. Об организации проекта по разделению на задачи можно спорить, где то возможно сделать и эффективнее.
Далее пойдем в область "розовых слонов", но из реальных проектов. Для fujitsu МВ90. Устройство, осуществляющее безостановочный контроль ж.д. состава. Задачи в порядке уменьшения приоритетов:
Еще несколько малосущественных задач поскипано. Посмотрел бы я на твой 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 байт.
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,
SZ> Не уверен, что такое с С166 прокатит. Там же сегментный доступ SZ> к памяти, и старшие два бита в слове - номер сегментного регистра SZ> DPP0...DPP3. Я сейчас уже не помню, на что там DPP0 в компиляторе SZ> показывает, но не факт, что на нулевой сегмент. Я 166-й вскользь смотрел очень давно, про эти 2 бита помню, но некоторые другие вещи - нет. Значит надо объявить эту voidfunc как far или как там у него. Чтобы или длинный call подставило (неужели нет такого?) или сегментный регистр перезагрузило. Раз он вообще может вызывать функции за пределами 64K, то и это пройдёт.
SZ> Хотя насильно привести абсолютный адрес к указателю на SZ> функцию - эта мысль мне в голову почему-то не приходила :-) Я стараюсь SZ> подобные конструкции не использовать, из суеверных соображений :-) Тёплый рестарт через jmp 0 - это уже вещь требующая аккуратности. Раз не было сброса - значит надо ручками все регистры прописать в нужное состояние не надеясь на умолчательные значения. На этом фоне в одном единственном месте привести константу к указателю окружив это громкими комментариями - можно.
wbr,
VO> Студентом я не признавал ничего кроме ассемблера - жизнь была проста и VO> удивительна VO> - MACRO-11 (на любимой СМ-4 под отличной RSX-11 v4.1, или RT-11FB/SJ на VO> ДВК), VO> хотя ему была вполне неплохая альтернатива в виде FORTRAN-IV VO> (Cи VO> компиляторы я пробовал разные порты с Unix - это была целая проблема VO> найти их - тогда программы носили на ленточных бобинах, но VO> нормального Си у меня не было) или классический PASCAL (но этот был VO> довольно громоздок). У нас их (паскалей) два было, один довольно лёгкий, но с паршивой оптимизацией, но зато с возможностью вставок на ассемблере. Из трёх пробегавших мимо С-компиляторов я остановился на том, который Юра Винярский и (?) Николаев портировали. Ты же несколько позже меня заканчивал, значит просто круги общения не пересекались, раз проблема найти была. Хотя я уже не очень помню года, но в 87 это уже точно было.
VO> Итого: я _ОЧЕНЬ_ люблю ассемблер, работал с ним на десятке архитектур, VO> можно сказать - фанат, но основную работу я делаю на _C_ - поскольку VO> это _УДОБНЕЕ_ и в конечном счете _ВЫГОДНЕЕ_. Понимание этого приходит VO> не сразу - и, как видно по конфе - не ко всем :-)
VO> Сорри за столь длинной повествование - настроение просто нерабочее VO> что-то :-) Что ты, спасибо :-) Очень хорошо сформулировал.
Я тоже не прочь пописать на асме, красивые миниатюры можно делать... Но на тех же ДВК это ограничилось процедурами рисования, патчем драйвера MY до чтения дискет с Электроники-85 да небольшим загружаемым в КЦГД модулем для быстрого отображения бинарной растровой графики (в имеющемся был байт на пиксел, что по скорости передачи не устраивало). Ну и небольшой низ в программе обработки изображений с ПЗС-ки в лабораторной установке. С тех пор на асме только знакомлюсь с новым процессором и небольшие объёмы критичных подпрограмм. Времени не так много, чтобы забирать его от каких-то физических или технических проблем и отдавать кодированию на ассемблере. Вот с MSP-шкой, похоже, на уровень asm-ма перейду только если действительно припрёт, а так с самого начала на С.
Wbr,
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> ресурсов.
О чём и шла уже речь. Эксклюзивные проекты с немеряным бюджетом и отсутствием массового выпуска я не рассматриваю, поскольку у них совсем другие принципы финансирования и подходы к разработке...
Георгий
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>
Hello, Maxim Polyanskiy !
Попробуй доказать.
И что? Стоить он при этом может лишь немногим дороже, если не дешевле другого, а писать так проще, надежней, быстрей.
А когда появится третья, то трех... И быстрый канал между ними с разрешением конфликтов... Мкрочип для dsPIC предлагает сразу несколько RTOS и прямо пишет, что ядро создавалось удобным для написания С компиляторов и компиляторов таких уже минимум 4 штуки на рынке.
С уважением, Дима Орлов.
Hello, Maxim Polyanskiy !
А ты не спорь, тем более, что от твоих аргументов действительно впечатление что ты со стенкой разговариваешь.
Регистры в х51 - это и есть ОЗУ. Это раз. Два, мне глубоко плевать сколько занято регистров и сколько занято ОЗУ и ПЗУ пока их хватает. Я не стану заниматься ни алгоритмической никакой другой оптимизацией программы пока она влазит в кристалл и успевает по времени. Это потерянное рабочее время, и потерянный time to market, что может быть существенно важней. Потому любое средство, будь то компилятор с С или внутрисхемный эмулятор, ускоряющий отладку в разы приветствуется.
С уважением, Дима Орлов.
Wed Feb 04 2004 08:04, Dima Orlov wrote to Vladimir Chekin:
DO> Я когда на асме для х86 писал, оформлял локальные DO> переменные, передачу параметров и все такое также, как это на этом DO> процессоре делают ЯВУ, благо в ассемблер для этого готовые макросы DO> встроены. Компилированный стек в рукопашную не сильно сделаешь...
Еще со времен Z80 и 6811 имею привычку делать честный стек с локальными переменными даже при писании на ассемблере. Hасчет регистров правила такие: либо все функции сохраняют все регистры, либо считаю, что любые регистры испорчены после обращения к функции, и вызывающий должен их сохранять. Это экономит огромное количество труда при отладке.
VLV
"Evil will prevail because good is dumb" (c) Space Balls
Привет Maxim!
Wednesday February 04 2004 07:15, Maxim Polyanskiy wrote to Roman Gorbunov:
MP> Еще 2-3 как минимум. По мере необходимости. Собственно говоря программа MP> функциональна с первой недели - теперь только развивается. MP>
RG>> Конкуренты наверное изделие уже сворачивать собираются :) MP>
MP> Конкурентов нет - прога уникальна. И кстати - непродаецца!!! ;)
А для чего она написана, для собственного удовольствия ? Тогда конечно, можно писать хоть на асме, хоть прямо в кодах....
Alexander Torres, 2:461/28 aka 2:461/640.28 aka 2:5020/6400.28 aka snipped-for-privacy@yahoo.com
Hello, Vladimir Vassilevsky !
Z80 как-то прошел мимо меня. АОHами и синклерами я не занимался, занимался промышленной аппаратурой, для которой применять z80 было нельзя. Hа 8080 через стек передавать было больно (в смысле накладно). Потом, как только появилась возможность, стал применять 8088. По сравнению с z80 это гораздо более развитый процессор, требующий почти таких же аппаратных затрат, но зато уже позволяющий писать на ЯВУ. Я использовал и С и С++ и Паскаль и конечно ассемблер. Так как достаточно ковырялся в скомпилированном коде, свой писал в том же стиле. Для
6811 я уже на ассемблере не писал ничего - только С, на который я и переписал написанную до меня на асме программу.Аналогично. Только для х86 я придерживался турбо-паскалевких правил, тем более, что нередко писал на асме функции, вызываемые из программы на ТР. Часть регистров функция может менять, часть не может. Сейчас уже не помню подробностей. 6-7 лет достаточно, чтобы это забыть...
С уважением, Дима Орлов.
Привет, Andy!
VC>> Hаверное Максиму держание в голове всего графа вызовов и распределение VC>> локальных переменных доставляет наивысшее наслаждение, ему просто VC>> это в кайф...
AM> Я думаю, он не догадывается, о чем вообще идет речь. Я так понял, AM> у него переменные могут быть или только глобальными, или только в AM> регистрах. Hе только догадывается, но и вполне отчётливо себе это представляет. Просто он считает, что может это сделать эффективнее чем компилер. Как человек опытный, он действительно это делает, но какой ценой. Значит для него эта цена приемлима.
Владимир Чекин
Привет, Dima!
DO> Это зависит. Я когда на асме для х86 писал, оформлял локальные переменные, DO> передачу параметров и все такое также, как это на этом процессоре делают DO> ЯВУ,благо в ассемблер для этого готовые макросы встроены. DO> Компилированный стек врукопашную не сильно сделаешь... Дык о чём речь, чё с голой пяткой на шашку прыгать. Зато красиво.
Владимир Чекин
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.