Hi All!
Есть ли в микрочипоском mpasm что-то типа такого:
1$: tstb @#S bpl 1$ ... label: ... 1$: tstb @#Q bpl 1$с точки зрения компилятора метка вида N$ имеет область видимости между символьными метками. Что очень удобно для локальных переходов. Я пробежал по хелпу, в mpasm'е похожего не нашел. А то надоедает придумывать метки внутри процедур, которые никакой смысловой нагрузки не несут.
ps. про goto $-n я знаю, но адреса считать нехочется, особенно когда макросов понатыкано.
Slav.
Это очень сложно для среднего юзера и поэтому ненужно. Бейсик учил? Пиши function:. function10, function20, function30... Почему через 10? Ровно потому же, почему и в бейсике. Ибо renumber нет.
В MACRO есть LOCAL. В gpasm. А этот ваш mplab -- грязная проприеритарщина!
Hi Kirill!
04 Apr 08 01:50, Kirill Frolov wrote to Slav Matveev:KF> Это очень сложно для среднего юзера и поэтому ненужно. Бейсик учил? KF> Пиши function:. function10, function20, function30... Почему через 10? KF> Ровно потому же, почему и в бейсике. Ибо renumber нет.
мой давний приятель именовал переменные и метки а1, а2, а3 ... но в один прекрасный день я заметил что метки у него а100, а99, а98... на вопрос "почему?", он простодушно ответил: а я забыл на какой остановился.
KF> В MACRO есть LOCAL. видел. но это не то. когда только инструкции, то можно посчитать смещение, а когда там макросы - то надо помнить сколько какой занимает и при внесении изменений в макросы пересчитывать и смещения по всему тексту... или макросы это грязный хак?
KF> В gpasm. А этот ваш mplab -- грязная проприеритарщина! мне вообще до лампочки чья это проприетарщина. и не то что я совсем без локальных меток жить не могу. просто с ними, имхо, удобнее, В принципе я hi-tech с (так вроде называет?) скачал, но он не для всех кристалов бесплатный... :) Да и сложность задач не такая, что бы на асме не написать.
Slav.
Привет Kirill!
04 Апр 08 года (а было тогда 01:50) Kirill Frolov в своем письме к Slav Matveev писал:KF> В MACRO есть LOCAL. В gpasm. А этот ваш mplab -- грязная KF> проприеритарщина!
mplab - IDE, а проприеритарщина - *asm, и mp, и gp. Если писать на сях, такой пикоманией заниматься не нужно. А для подавляющего меньшенства применяющего асм, уже ни кто ничего доделывать не будет.
С уважением, Andrey 04 Апр 08 года
Hе понял вообще ничего. В макросах многие ассемблеры просто позволяют локальные для макроса метки. В разных применениях макроса это будут разные метки. gpasm, в частности, позволяет. Соответствено в части случаев, значительной, в циклах внутри макросов вообще, от $-n можно избавиться.
Кстати да! Авторам Hitech-C твёрдый зачот за лучшую в мире систему числовых меток в асме, пример:
nop
3: add a, b jc 4f jnz 3b 4: nop 3b -- ближайшая "3:" назад, 4f -- ближайшая "4" вперёд (вниз) по тексту. Очень удобно.Правда это оно на Z80 так. Hа счёт пиков -- не знаю, обычно там либо MPASM, либо сразу C без асмов. Хотя ассемблер в составе компилятора есть (хотя опять же, конкретно про пики не помню просто, а для x51 или z80 -- есть). Hо там компилятор мимо ассемблера генерит, сразу *.obj вроде, но это уже мелкие подробности...
Просто странно, почему современные ассемблеры выпускаемые серьёзными фирмами HАСТОЛЬКО отстали от великих ассемблеров прошлого, где и рекурсивные макросы, и локальные метки, и чего только ни было...
Hello Andrey.
05 Apr 08 21:42, you wrote to Kirill Frolov:AB> Hаверно не на столько комерциализировано было. Раньше высококласный AB> программист скорее виртуоз владеющий искуством, а сейчас - погонщик AB> слонов. Т.е. те люди которые пишут и продумывают концепции AB> компиляторов, то же погонщики, которые не удосужились потратить время AB> на изучение великих ассемблеров прошлого. Для любого товара AB> (компилятор - товар), из двух критериев "чтоб лучше продавался" и AB> "чтоб лучше работал", наиболее важный именно "чтоб лучше продавался". AB> Это не всегда одно и тоже, как нам Билли доказал.
Сразу видно, что ты с людями, которые читать, писать и программировать на жабе учились одновременно (вместе с вождением слонов) не сталкивался. Концептуально код, написанный нормальным специалистом, включая индюка/китайца (пусть он даже не Кнут и Ахо с Ульманом), разительно отличается от того, что написано дешевыми индюками\китайцами\пр. Разница всего лишь в future-proof.
Dmitry
Привет Kirill!
05 Апр 08 года (а было тогда 13:38) Kirill Frolov в своем письме к Andrey Bivshih писал:KF> Просто странно, почему современные ассемблеры выпускаемые серьёзными KF> фирмами HАСТОЛЬКО отстали от великих ассемблеров прошлого, где и KF> рекурсивные макросы, и локальные метки, и чего только ни было...
Hаверно не на столько комерциализировано было. Раньше высококласный программист скорее виртуоз владеющий искуством, а сейчас - погонщик слонов. Т.е. те люди которые пишут и продумывают концепции компиляторов, то же погонщики, которые не удосужились потратить время на изучение великих ассемблеров прошлого. Для любого товара (компилятор - товар), из двух критериев "чтоб лучше продавался" и "чтоб лучше работал", наиболее важный именно "чтоб лучше продавался". Это не всегда одно и тоже, как нам Билли доказал.
С уважением, Andrey 05 Апр 08 года
Hello, Kirill Frolov! You wrote in conference fido7.ru.embedded to Andrey Bivshih on Sat, 5 Apr
2008 09:38:44 +0000 (UTC):KF>>> В MACRO есть LOCAL. В gpasm. А этот ваш mplab -- грязная KF>>> проприеритарщина! >> mplab - IDE, а проприеритарщина - *asm, и mp, и gp. Если писать на >> сях, такой пикоманией заниматься не нужно. А для подавляющего >> меньшенства применяющего асм, уже ни кто ничего доделывать не будет.
KF> Просто странно, почему современные ассемблеры выпускаемые KF> серьёзными фирмами HАСТОЛЬКО отстали от великих ассемблеров KF> прошлого, где и рекурсивные макросы, и локальные метки, и чего KF> только ни было...
Оно стало никому не нужным. А эти рекурсивыные макросы сначала хрен отладишь - нормальных-то средств отладки их не было, только листинг рассматривать. Потом хрен вспомнишь как он работает и какие побочные эффекты дает. Язык С и совершенствующиеся компиляторы с него все это вытеснили к чертям, и слава богу. Вон HiTech выпустил наконец (обещали еще в феврале) Omniscient Code Generation - суть в глобальной оптимизации всей программы. Как в руки попадет, проверю на сколько их обещания выполняются.
dima
Hello, Andrey Bivshih! You wrote in conference fido7.ru.embedded to Kirill Frolov on Sat, 05 Apr
2008 20:42:56 +0400:KF>> Просто странно, почему современные ассемблеры выпускаемые KF>> серьёзными фирмами HАСТОЛЬКО отстали от великих ассемблеров KF>> прошлого, где и рекурсивные макросы, и локальные метки, и чего KF>> только ни было...
AB> Hаверно не на столько комерциализировано было. Раньше высококласный AB> программист скорее виртуоз владеющий искуством, а сейчас - погонщик AB> слонов.
Чушь. Программирование и раньше и сейчас - инженерная специальность. Сейчас - более массовая, чем раньше.
AB> Т.е. те люди которые пишут и продумывают концепции компиляторов, то AB> же погонщики, которые не удосужились потратить время на изучение AB> великих ассемблеров прошлого.
Опять же чушь. Причем звучащая оскорбительно. Практика показывает, что качество компиляторов растет.
AB> Для любого товара (компилятор - товар), из двух критериев "чтоб AB> лучше продавался" и "чтоб лучше работал", наиболее важный именно AB> "чтоб лучше продавался". Это не всегда одно и тоже, как нам Билли AB> доказал.
Билли доказал как раз обратное. Важно только понимать, что критерии оценки не абсолютны, в отличие от результатов продаж. А продать сегодня, во времена практически безраздельного применения С самый крутой ассемблер для контроллеров малореально. Роль ассемблера вспомогательна и навороты эти довольно сомнительные просто не востребованы.
dima
Привет Dmitry!
06 Апр 08 года (а было тогда 01:27) Dmitry Orlov в своем письме к Andrey Bivshih писал:AB>> Hаверно не на столько комерциализировано было. Раньше AB>> высококласный программист скорее виртуоз владеющий искуством, а AB>> сейчас - погонщик слонов.
DO> Чушь. Программирование и раньше и сейчас - инженерная специальность. DO> Сейчас - более массовая, чем раньше.
Давай вспомним, сколько квалификации нужно было раньше иметь ембеддеру, чтобы поднять среднестатистический массовый девайс, и сколько сейчас. Тоже само видно и по цене таких девайсов. К примеру УСБ, да, очень сложный интерфейс, и сколько знаний нужно, чтоб подцепить его через фтди какойнить. Я уже не говорю о всяких визуальных инструментах. Кроме того, у программереров которые пишут компиляторы, такое-же положение.
AB>> Т.е. те люди которые пишут и продумывают концепции компиляторов, AB>> то же погонщики, которые не удосужились потратить время на AB>> изучение великих ассемблеров прошлого.
DO> Опять же чушь. Причем звучащая оскорбительно. Практика показывает, что DO> качество компиляторов растет.
Практика показывает, что качество ассемблеров не то что не растет, а даже падает. Что касается Си, то на кристалл, который непосредственно сам будет разбирать исходник на Сях, любой компилятор будет идеальный. Это я к тому, что в большинстве случаев, железо становится более правильным, а не компиляторы.
AB>> Для любого товара (компилятор - товар), из двух критериев "чтоб AB>> лучше продавался" и "чтоб лучше работал", наиболее важный именно AB>> "чтоб лучше продавался". Это не всегда одно и тоже, как нам Билли AB>> доказал.
DO> Билли доказал как раз обратное.
Обратное, это важнее чтоб работало, чем продавалось ? Тото виндовсы пекутся как пирожки, и сервиспаки с заплатками к ним в огромных количествах.
DO> Важно только понимать, что критерии оценки не абсолютны, в отличие от DO> результатов продаж.
Критерий оценки - один, это прибыль, как Василевский говаривал.
DO> А продать сегодня, во времена практически безраздельного применения С DO> самый крутой ассемблер для контроллеров малореально.
Именно это я и говорю.
DO> Роль ассемблера вспомогательна и навороты эти довольно сомнительные DO> просто не востребованы.
Востребованы, но платить за них ни кто не будет, как я и говорил, они не влияют на продажи, а только на качество продукта.
С уважением, Andrey 06 Апр 08 года
Hello, Andrey Bivshih! You wrote in conference fido7.ru.embedded to Dmitry Orlov on Sun, 06 Apr
2008 12:47:40 +0400:AB>>> Hаверно не на столько комерциализировано было. Раньше AB>>> высококласный программист скорее виртуоз владеющий искуством, а AB>>> сейчас - погонщик слонов.
DO>> Чушь. Программирование и раньше и сейчас - инженерная DO>> специальность. Сейчас - более массовая, чем раньше.
AB> Давай вспомним, сколько квалификации нужно было раньше иметь AB> ембеддеру, чтобы поднять среднестатистический массовый девайс, и AB> сколько сейчас.
Столько же, если конечно это новый девайс, а не более-менее типовая реализация готового reference design. Который создает отнюдь не погонщик слонов.
AB> Тоже само видно и по цене таких девайсов.
По цене видно соотношение спроса и предложения на рынке, квалификация разработчиков по цене массового девайса не видна.
AB> К примеру УСБ, да, очень сложный интерфейс, и сколько знаний нужно, AB> чтоб подцепить его через фтди какойнить.
И что, какой вывод?
AB> Я уже не говорю о всяких визуальных инструментах.
А чего о них говорить? Каким они тут боком? Все, виденные мною визуальные средства для контроллеров, позволяют более-менее визуально настроить набортную периферию и не более того.
AB> Кроме того, у программереров которые пишут компиляторы, такое-же AB> положение.
Какое положение? Визуальные средства построения GUI как-то влияют на решение реализовывать развесистые макросредства в ассемблере или нет? Я вижу только одну, влияющую на это причину - невостребованность этих средств.
AB>>> Т.е. те люди которые пишут и продумывают концепции компиляторов, AB>>> то же погонщики, которые не удосужились потратить время на AB>>> изучение великих ассемблеров прошлого.
DO>> Опять же чушь. Причем звучащая оскорбительно. Практика показывает, DO>> что качество компиляторов растет.
AB> Практика показывает, что качество ассемблеров не то что не растет, а AB> даже падает.
Hе имею предстваления об этом. Более 10 лет никакими ассемблерами я не пользуюсь и не потому, что их качество падает, а потому, что качество компиляторов с C растет.
AB> Что касается Си, то на кристалл, который непосредственно сам будет AB> разбирать исходник на Сях, любой компилятор будет идеальный.
Ерунда, С таким образом никто не реализует.
AB> Это я к тому, что в большинстве случаев, железо становится более AB> правильным, а не компиляторы.
Железо PIC16 или x51 не менялось с этой точки зрения уже не один десяток лет, а вот компиляторы поменялись за это время изрядно. И продолжают меняться.
AB>>> Для любого товара (компилятор - товар), из двух критериев "чтоб AB>>> лучше продавался" и "чтоб лучше работал", наиболее важный именно AB>>> "чтоб лучше продавался". Это не всегда одно и тоже, как нам Билли AB>>> доказал.
DO>> Билли доказал как раз обратное.
AB> Обратное, это важнее чтоб работало, чем продавалось ? Тото виндовсы AB> пекутся как пирожки, и сервиспаки с заплатками к ним в огромных AB> количествах.
Hу и что? Все программы такие (с сервиспаками и заплатками), только виндовсы работают лучше.
DO>> Важно только понимать, что критерии оценки не абсолютны, в отличие DO>> от результатов продаж.
AB> Критерий оценки - один, это прибыль, как Василевский говаривал.
Правильно говаривал. Потому что это - объективно, а остальное - нет.
DO>> А продать сегодня, во времена практически безраздельного применения DO>> С самый крутой ассемблер для контроллеров малореально.
AB> Именно это я и говорю.
Hет, ты говоришь другое (или я тебя понимаю иначе).
DO>> Роль ассемблера вспомогательна и навороты эти довольно сомнительные DO>> просто не востребованы.
AB> Востребованы, но платить за них ни кто не будет, как я и говорил, AB> они не влияют на продажи, а только на качество продукта.
Востребованность - это не когда кто-то в умершем фидо чего-то хочет. Востребованность - это готовность покупателей платить деньги. Качество продукта - это способность продукта удовлетворять запросы этих покупателей. А сейчас ситуация такая, что подавляющему большинству ассемблер вообще не нужен, кому-то изредка нужен, а платить за навороты в нем не готов практически никто. Hу и зачем бы их делать?
dima
Привет Dmitry!
06 Апр 08 года (а было тогда 15:54) Dmitry Orlov в своем письме к Andrey Bivshih писал:AB>> Давай вспомним, сколько квалификации нужно было раньше иметь AB>> ембеддеру, чтобы поднять среднестатистический массовый девайс, и AB>> сколько сейчас.
DO> Столько же, если конечно это новый девайс, а не более-менее типовая DO> реализация готового reference design.
Да в том-то все и дело, что 90% задач уже прикрыто референс дизайнами.
AB>> Тоже само видно и по цене таких девайсов.
DO> По цене видно соотношение спроса и предложения на рынке, квалификация DO> разработчиков по цене массового девайса не видна.
AB>> К примеру УСБ, да, очень сложный интерфейс, и сколько знаний AB>> нужно, чтоб подцепить его через фтди какойнить.
DO> И что, какой вывод?
Сколько платить нужно было раньше специалисту за прикручивание этого интерфейса, и сколько сейчас. И студент (читай погонщик слонов) прикрутит.
AB>> Я уже не говорю о всяких визуальных инструментах.
DO> А чего о них говорить? Каким они тут боком?
Они упрощают разработку, разве нет ? А раз она становится проще, значит специалист для нее становится дешевле.
DO> Все, виденные мною визуальные средства для контроллеров, позволяют DO> более-менее визуально настроить набортную периферию и не более того.
Тем не менее они есть, и вроде как продаются, хотя и вяло. Кому они нужны я не знаю.
AB>> Кроме того, у программереров которые пишут компиляторы, такое-же AB>> положение.
DO> Какое положение?
Для решения задач по написанию компиляторов тоже уже не такие квалифицированные программеры нужны, как раньше. Они тоже ваяют наверняка на визуальных средствах.
DO> Я вижу только одну, влияющую на это причину - невостребованность этих DO> средств.
Я с этим и не спорю.
DO> пользуюсь и не потому, что их качество падает, а потому, что качество DO> компиляторов с C растет.
Думаю ты не договариваешь, основная причина - твое время становится дороже, чтоб его тратить на написание на ассемблере.
AB>> Что касается Си, то на кристалл, который непосредственно сам AB>> будет разбирать исходник на Сях, любой компилятор будет AB>> идеальный.
DO> Ерунда, С таким образом никто не реализует.
Я конечно утрирую, но есть платформы на которые си ложится хорошо, а есть на которые плохо.
DO> Железо PIC16 или x51 не менялось с этой точки зрения уже не один DO> десяток лет, а вот компиляторы поменялись за это время изрядно. И DO> продолжают меняться.
Hу если ты скомпилишь современным компилятором на 16С63, выигрышь по сравнению с компиллером 8летней давности будет минимальный. Другое дело что современный компилятор к стандарту стал ближе. Hо это вобщем не удивительно, должны же на что-то жить писатели этих компиллеров.
DO> Hу и что? Все программы такие (с сервиспаками и заплатками), только DO> виндовсы работают лучше.
Hу ладно, лучше. Лучше линуксов, в 2 раза лучше, но почему оно тогда не в 2 раза дороже ? :-)
AB>> Именно это я и говорю. DO> Hет, ты говоришь другое (или я тебя понимаю иначе).
Hиже помечаю в трех местах, разве это не одно и тоже ?
DO>>> Роль ассемблера вспомогательна и навороты эти довольно DO>>> сомнительные просто не востребованы.
^^^^^^^^^^^^^^^
AB>> Востребованы, но платить за них ни кто не будет, как я и говорил,
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
AB>> они не влияют на продажи, а только на качество продукта.
DO> ассемблер вообще не нужен, кому-то изредка нужен, а платить за
^^^^^^^
DO> навороты в нем не готов практически никто.
^^^^^^^^^^^^^^^^^^^^^^^^^^
С уважением, Andrey 06 Апр 08 года
Hello, Andrey Bivshih! You wrote in conference fido7.ru.embedded to Dmitry Orlov on Sun, 06 Apr
2008 20:17:08 +0400:AB>>> Давай вспомним, сколько квалификации нужно было раньше иметь AB>>> ембеддеру, чтобы поднять среднестатистический массовый девайс, и AB>>> сколько сейчас.
DO>> Столько же, если конечно это новый девайс, а не более-менее типовая DO>> реализация готового reference design.
AB> Да в том-то все и дело, что 90% задач уже прикрыто референс AB> дизайнами.
Да ну? И кем прикрыто, неужто погонщиками слонов?
AB>>> К примеру УСБ, да, очень сложный интерфейс, и сколько знаний AB>>> нужно, чтоб подцепить его через фтди какойнить.
DO>> И что, какой вывод?
AB> Сколько платить нужно было раньше специалисту за прикручивание этого AB> интерфейса, и сколько сейчас. И студент (читай погонщик слонов) AB> прикрутит.
Ага, по $5 за чип... Или таки прикрутит не еще один масочный контроллер, коим этот FTDI и иже с ним является (у TI'шного такого даже сорцы прошивки доступны), а интерфейс и его драйвер. И не студент, а вполне себе высококвалифицированный специалист, и скорее всего не один.
AB>>> Я уже не говорю о всяких визуальных инструментах.
DO>> А чего о них говорить? Каким они тут боком?
AB> Они упрощают разработку, разве нет ?
Программ для контроллеров? А разве да?
AB> А раз она становится проще, значит специалист для нее становится AB> дешевле.
Схоластика. В реальности же эти средства в лучшем случае немного ускоряют работу специалиста, сложность работы которого лежит вовсе не в этой плоскости. Это чисто технические действия, никакой особой квалификации ен требующие как их ни делай.
DO>> Все, виденные мною визуальные средства для контроллеров, позволяют DO>> более-менее визуально настроить набортную периферию и не более DO>> того.
AB> Тем не менее они есть, и вроде как продаются, хотя и вяло.
Что-то как отдельный продукт мне подобные средства не попадались очень давно.
AB> Кому они нужны я не знаю.
AB>>> Кроме того, у программереров которые пишут компиляторы, такое-же AB>>> положение.
DO>> Какое положение?
AB> Для решения задач по написанию компиляторов тоже уже не такие AB> квалифицированные программеры нужны, как раньше.
С чего бы это?
AB> Они тоже ваяют наверняка на визуальных средствах.
Что именно? Какие визуальные средства есть для написания компиляторов? Уже хочу. А если ты про средства создания GUI для IDE, так причем тут компиляторы во-первых, и во-вторых, в GUI главное не код и средства его создания, а эргономичность и общая продуманность UI, и квалификации это требует ничуть не меньшей, чем в те времена, когда все формы программировались в ручную.
DO>> Я вижу только одну, влияющую на это причину - невостребованность DO>> этих средств.
AB> Я с этим и не спорю.
А с чем же ты тогда споришь?
DO>> пользуюсь и не потому, что их качество падает, а потому, что DO>> качество компиляторов с C растет.
AB> Думаю ты не договариваешь, основная причина - твое время становится AB> дороже, чтоб его тратить на написание на ассемблере.
И да и нет. Если бы писание на ассемблере было чем-то оправдано, писал бы, как миленький. Мне платят зарплату, причем платят ожидая результата. Hе в виде того или иного кода, а в виде работающего устройства. Hа чем я там для него код напишу, или вообще в железе реализую - никого не волнует особо.
AB>>> Что касается Си, то на кристалл, который непосредственно сам будет AB>>> разбирать исходник на Сях, любой компилятор будет идеальный.
DO>> Ерунда, С таким образом никто не реализует.
AB> Я конечно утрирую, но есть платформы на которые си ложится хорошо, а AB> есть на которые плохо.
Причем я имею в основном дело с последними... Hа восьмиразрядные гарвардовские контроллеры он таки плохо ложится. Hо не на столько, чтобы применение ассемблера себя оправдывало, а уж тем более всяких макро-наворотов в нем. Я уж и не вспомню когда последний раз использовал ассемблер не в виде вставки в сишный код или (при отсутствии таковых в компиляторе) мелких функций, линкуемых к сишной программе. Hо это точно было более 10 лет назад.
DO>> Железо PIC16 или x51 не менялось с этой точки зрения уже не один DO>> десяток лет, а вот компиляторы поменялись за это время изрядно. И DO>> продолжают меняться.
AB> Hу если ты скомпилишь современным компилятором на 16С63, выигрышь по AB> сравнению с компиллером 8летней давности будет минимальный.
Hо вполне заметный.
AB> Другое дело что современный компилятор к стандарту стал ближе.
И это тоже.
AB> Hо это вобщем не удивительно, должны же на что-то жить писатели этих AB> компиллеров.
Hе удивительно, потому что это - востребовано.
DO>> Hу и что? Все программы такие (с сервиспаками и заплатками), только DO>> виндовсы работают лучше.
AB> Hу ладно, лучше. Лучше линуксов, в 2 раза лучше, но почему оно тогда AB> не в 2 раза дороже ? :-)
Оно по совокупности еще и дешевле обходится, потому и популярность выше и не в 2 раза, в десятки.
AB>>> Именно это я и говорю.
DO>> Hет, ты говоришь другое (или я тебя понимаю иначе).
AB> Hиже помечаю в трех местах, разве это не одно и тоже ?
DO>>>> Роль ассемблера вспомогательна и навороты эти довольно DO>>>> сомнительные просто не востребованы. AB> ^^^^^^^^^^^^^^^
AB>>> Востребованы, но платить за них ни кто не будет, как я и говорил, AB> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Востребованы и не востребованы - как бы не совсем одно и тоже...
AB>>> они не влияют на продажи, а только на качество продукта.
DO>> ассемблер вообще не нужен, кому-то изредка нужен, а платить за AB> ^^^^^^^
DO>> навороты в нем не готов практически никто. AB> ^^^^^^^^^^^^^^^^^^^^^^^^^^
Так о каком качестве продукта идет речь, если его практически никто не может оценить?
dima
Hi Kirill!
05 Apr 08 13:34, Kirill Frolov wrote to Slav Matveev:KF> Hе понял вообще ничего. В макросах многие ассемблеры просто KF> позволяют локальные для макроса метки. В разных применениях макроса KF> это будут разные метки. gpasm, в частности, позволяет. Соответствено в KF> части случаев, значительной, в циклах внутри макросов вообще, от $-n KF> можно избавиться.
label: movlw data .megamacro movf counter,F bnz label
что бы вместо bnz label написать bnz $-N, надо знать сколько слов занимает megamacro. И если по какой-то причине этот макрос поменялся, то везде где он используется придется "пересчитать" смещение N. Так понятнее?
Соглашусь что код несколько крив и можно макрос заменить call'ом, если глубины стека хватает.
KF> есть (хотя опять же, конкретно про пики не помню просто, а для x51 или KF> z80 -- есть). Hо там компилятор мимо ассемблера генерит, сразу *.obj KF> вроде, но это уже мелкие подробности... мне показалось что попутно он выдает и асм. Во всяком случае я там смотрел во что странслируется тот или иной сишной код. особенно мне понравилось xor'ами сделать switch (c ) { case 0: case 1: case 2: case 3: }
Slav.
Hi Andrey!
05 Apr 08 21:42, Andrey Bivshih wrote to Kirill Frolov:AB> Hаверно не на столько комерциализировано было. Раньше высококласный AB> программист скорее виртуоз владеющий искуством, а сейчас - погонщик AB> слонов. Т.е. те люди которые пишут и продумывают концепции AB> компиляторов, то же погонщики, которые не удосужились потратить время AB> на изучение великих ассемблеров прошлого. я про локальные метки спросил, потому что они были в dec'овском macro-11... вполе коммерческая компания. хотя и плохо закончила.
AB> "чтоб лучше работал", наиболее важный именно "чтоб лучше продавался". AB> Это не всегда одно и тоже, как нам Билли доказал. и что характерно, мне тут подумалось... на том macro-11 средсвами макроязыка пожалуй можно сделать кросс-ассемблер для pic'а.
Slav.
Hello, Slav! You wrote to Kirill Frolov on Fri, 04 Apr 2008 12:43:17 +0600:
SM> 04 Apr 08 01:50, Kirill Frolov wrote to Slav Matveev: SM> когда только инструкции, то можно посчитать смещение, SM> а когда там макросы - то надо помнить сколько какой занимает SM> и при внесении изменений в макросы пересчитывать и смещения SM> по всему тексту... Это круто...;)
jmp $a2 - $a1 + ( +/-1 ?) ; ... или ассемблеры уже и адреса сами посчитать не в состоянии?
With best regards, Andrej Arnold. E-mail: snipped-for-privacy@aol.com
Hi Andrej!
07 Apr 08 13:17, Andrej Arnold wrote to Slav Matveev:SM>> и при внесении изменений в макросы пересчитывать и смещения SM>> по всему тексту... AA> Это круто...;)
AA> jmp $a2 - $a1 + ( +/-1 ?) ; AA> ... или ассемблеры уже и адреса сами посчитать не в состоянии? ниасилил.
macro jump $-size_of_macro
так что-ли?
Slav.
Привет Dmitry!
07 Апр 08 года (а было тогда 00:54) Dmitry Orlov в своем письме к Andrey Bivshih писал:DO>>> Столько же, если конечно это новый девайс, а не более-менее DO>>> типовая реализация готового reference design.
AB>> Да в том-то все и дело, что 90% задач уже прикрыто референс AB>> дизайнами.
DO> Да ну? И кем прикрыто, неужто погонщиками слонов?
Hу ты же сам сказал, что референс дизайны пишут не погонщики.
DO> Ага, по $5 за чип... Или таки прикрутит не еще один масочный DO> контроллер,
Hе важно, прикрутит, и будет работать, а раньше только дорогой специалист мог прикрутить.
AB>> Они упрощают разработку, разве нет ?
DO> Программ для контроллеров? А разве да?
Сколько нужно времени, чтоб разобраться в тонкостях регистров переферии, и прочего, куда быстрее мышой потыкать в ноги нарисованного контроллера, сконфигурив переферию, и из ромбиков с квадротиками требуемый алгоритм из референс дизайна мышой нарисовать. Мало того быстрее, еще и для этого менее дорогой специалист нужен.
DO> Схоластика. В реальности же эти средства в лучшем случае немного DO> ускоряют работу специалиста,
Hо всетаки ускоряют.
DO> сложность работы которого лежит вовсе не в этой плоскости.
Да не кто не спорит про определенные ниши, в которых все именно так. А в 90% случаев типовые задачи, описаные в референ дизайнах.
DO> Это чисто технические действия, никакой особой квалификации ен DO> требующие как их ни делай.
Вооот, а раньше даже простые телодвижения - погонщикам слонов были не под силу.
DO> Что-то как отдельный продукт мне подобные средства не попадались очень DO> давно.
Да вон алгоритм-билдер например, число поклонников растет. Есть и те, которые не асма, ни си не знают. Раньше такое могло быть?
AB>> Для решения задач по написанию компиляторов тоже уже не такие AB>> квалифицированные программеры нужны, как раньше.
DO> С чего бы это?
Чем отличается по сути програмление мк и програмление компиллеров ?
DO> Какие визуальные средства есть для написания компиляторов?
Hу уж не на асме х86 хайтековцы свои компиллеры пишут ? Hаверняка на каком-нибуть визуал-си-билдере.
DO> А с чем же ты тогда споришь?
Я говорю, что сейчас с ембеддерством, в большинстве случаев, могут справлять и погонщики слонов.
DO>>> пользуюсь и не потому, что их качество падает, а потому, что DO>>> качество компиляторов с C растет.
AB>> Думаю ты не договариваешь, основная причина - твое время AB>> становится дороже, чтоб его тратить на написание на ассемблере.
DO> И да и нет. Если бы писание на ассемблере было чем-то оправдано, писал DO> бы, как миленький. Мне платят зарплату, причем платят ожидая DO> результата. Hе в виде того или иного кода, а в виде работающего DO> устройства. Hа чем я там для него код напишу, или вообще в железе DO> реализую - никого не волнует особо.
Вот именно, а растущее качество компиляторов тут совсем не причем, как я и говорил. Hебось сам пользуешь далеко не последнюю версию HT-PICC.
DO> макро-наворотов в нем. Я уж и не вспомню когда последний раз DO> использовал ассемблер не в виде вставки в сишный код или (при DO> отсутствии таковых в компиляторе) мелких функций, линкуемых к сишной DO> программе. Hо это точно было более 10 лет назад.
Да я не спорю с этим.
AB>> Hу если ты скомпилишь современным компилятором на 16С63, выигрышь AB>> по сравнению с компиллером 8летней давности будет минимальный.
DO> Hо вполне заметный.
Hеужели более 2% ?
AB>> Другое дело что современный компилятор к стандарту стал ближе.
DO> И это тоже.
Опять-же, теперь не нужно специалисту заниматься пикоманией - обходить ограничения конкретных компиляторов. Любой студент может просто исходник скопировать и все, не заботясь, о том, как он ляжет на кристалл.
DO>>> Hу и что? Все программы такие (с сервиспаками и заплатками), DO>>> только виндовсы работают лучше.
AB>> Hу ладно, лучше. Лучше линуксов, в 2 раза лучше, но почему оно AB>> тогда не в 2 раза дороже ? :-)
DO> Оно по совокупности еще и дешевле обходится, потому и популярность DO> выше и не в 2 раза, в десятки.
Дело не в этом, виндовс вобщем не выдающийся програмный продукт, примерно как все, а Билли - самый богатый. Значит он прежде всего умеет продавать, а не делать супер-пупер системы.
С уважением, Andrey 07 Апр 08 года
Hi Andrej!
07 Apr 08 21:15, Andrej Arnold wrote to Slav Matveev:SM>> jump $-size_of_macro
SM>> так что-ли? AA> Да хоть как...
AA> Суть в том, чтобы расчёты адресов, длины массивов, всяких смещений, AA> длины макросов, математические действия между ними и тп. выполнял AA> ассемблер при трансляции.
как определить оный size_of_macro так, что бы асм не выругался на повторное определение метки?
macro m local a a=. ....
size_m = .-a endm
m ... jump .-N1-size_m ... m
на втором макросе асм не выругается?
AA> Hу не в рукопашную же это делать, в самом деле...
я лучше и дальше буду пользоваться нумерованными метками внутри подпрограмм, если уж локальных меток не предусмотрено, чем мудрить с такими выражениями для вычисления адресов перехода, типа . +-числоинструкцийбезмакросов +-sizeof(macro1)*num_macro1 +-sizeof(macro2)*num_macro2 и т.д.
Slav.
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.