mpasm и локальные метки.

Это очень сложно для среднего юзера и поэтому ненужно. Бейсик учил? Пиши function:. function10, function20, function30... Почему через 10? Ровно потому же, почему и в бейсике. Ибо renumber нет.

В MACRO есть LOCAL. В gpasm. А этот ваш mplab -- грязная проприеритарщина!

Hi Kirill!

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!

KF> В MACRO есть LOCAL. В gpasm. А этот ваш mplab -- грязная KF> проприеритарщина!

mplab - IDE, а проприеритарщина - *asm, и mp, и gp. Если писать на сях, такой пикоманией заниматься не нужно. А для подавляющего меньшенства применяющего асм, уже ни кто ничего доделывать не будет.

С уважением, Andrey 04 Апр 08 года

Hе понял вообще ничего. В макросах многие ассемблеры просто позволяют локальные для макроса метки. В разных применениях макроса это будут разные метки. gpasm, в частности, позволяет. Соответствено в части случаев, значительной, в циклах внутри макросов вообще, от $-n можно избавиться.

Кстати да! Авторам Hitech-C твёрдый зачот за лучшую в мире систему числовых меток в асме, пример:

nop

Правда это оно на Z80 так. Hа счёт пиков -- не знаю, обычно там либо MPASM, либо сразу C без асмов. Хотя ассемблер в составе компилятора есть (хотя опять же, конкретно про пики не помню просто, а для x51 или z80 -- есть). Hо там компилятор мимо ассемблера генерит, сразу *.obj вроде, но это уже мелкие подробности...

Просто странно, почему современные ассемблеры выпускаемые серьёзными фирмами HАСТОЛЬКО отстали от великих ассемблеров прошлого, где и рекурсивные макросы, и локальные метки, и чего только ни было...

Hello Andrey.

AB> Hаверно не на столько комерциализировано было. Раньше высококласный AB> программист скорее виртуоз владеющий искуством, а сейчас - погонщик AB> слонов. Т.е. те люди которые пишут и продумывают концепции AB> компиляторов, то же погонщики, которые не удосужились потратить время AB> на изучение великих ассемблеров прошлого. Для любого товара AB> (компилятор - товар), из двух критериев "чтоб лучше продавался" и AB> "чтоб лучше работал", наиболее важный именно "чтоб лучше продавался". AB> Это не всегда одно и тоже, как нам Билли доказал.

Сразу видно, что ты с людями, которые читать, писать и программировать на жабе учились одновременно (вместе с вождением слонов) не сталкивался. Концептуально код, написанный нормальным специалистом, включая индюка/китайца (пусть он даже не Кнут и Ахо с Ульманом), разительно отличается от того, что написано дешевыми индюками\китайцами\пр. Разница всего лишь в future-proof.

Dmitry

Привет Kirill!

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

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

KF>> Просто странно, почему современные ассемблеры выпускаемые KF>> серьёзными фирмами HАСТОЛЬКО отстали от великих ассемблеров KF>> прошлого, где и рекурсивные макросы, и локальные метки, и чего KF>> только ни было...

AB> Hаверно не на столько комерциализировано было. Раньше высококласный AB> программист скорее виртуоз владеющий искуством, а сейчас - погонщик AB> слонов.

Чушь. Программирование и раньше и сейчас - инженерная специальность. Сейчас - более массовая, чем раньше.

AB> Т.е. те люди которые пишут и продумывают концепции компиляторов, то AB> же погонщики, которые не удосужились потратить время на изучение AB> великих ассемблеров прошлого.

Опять же чушь. Причем звучащая оскорбительно. Практика показывает, что качество компиляторов растет.

AB> Для любого товара (компилятор - товар), из двух критериев "чтоб AB> лучше продавался" и "чтоб лучше работал", наиболее важный именно AB> "чтоб лучше продавался". Это не всегда одно и тоже, как нам Билли AB> доказал.

Билли доказал как раз обратное. Важно только понимать, что критерии оценки не абсолютны, в отличие от результатов продаж. А продать сегодня, во времена практически безраздельного применения С самый крутой ассемблер для контроллеров малореально. Роль ассемблера вспомогательна и навороты эти довольно сомнительные просто не востребованы.

dima

Привет Dmitry!

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

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!

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

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!

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!

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!

SM>> и при внесении изменений в макросы пересчитывать и смещения SM>> по всему тексту... AA> Это круто...;)

AA> jmp $a2 - $a1 + ( +/-1 ?) ; AA> ... или ассемблеры уже и адреса сами посчитать не в состоянии? ниасилил.

macro jump $-size_of_macro

так что-ли?

Slav.

Привет Dmitry!

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!

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.