PC +/- … Опции

[Wise]

..Борюсь с атмегами.. о, как они мне не нравятся.. ну всё, буквально, претит..

..Вопрос такой.
У PIC-ов есть возможность написать: гоу ту доллар +/-, скажем, 7.
И программа перейдет по указанному адресу.
У атмег, аналогичный вариант выглядит, как, PC +/- 7.
Как бы, это работает. Но, недавно, что-то не пошло, пришлось по фрагментам в студии рассматривать. И обнаружил, что не прыгает оно на семь указанных строчек, а прыгает на шесть. А в других случаях прыгало..
Если указать восемь, будет прыгать на семь.
..Это глюк такой или есть нюансы, которых не знаю?
..С PIC-ами таких проблем не было.

P.S. Настоятельная просьба ко всем, решившим сюда ответить: ни слова о Си. О его достоинствах, преимуществах и т. д. Ни слова! Или сразу закрою тему.

[Oldring]

Даже хуже. Как верно заметил rx3apf, SREG не попадает в область IO, соответственно, никакие из его флагов не доступны командам sbic/sbis.

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

[SysRq]

По битам в i/o или в регистрах - да. А вот по битам в регистре состояния - облом.

Да. Но команда IN флаги не меняет, насколько я помню.

--

Для замены BRGE что предложите?

Осмысленные метки, я их изначально предлагаю Ежели доводить до абсурда, то разложить на составляющие результат BRGE тоже возможно.

Ну, если включать иногда на секунду мозг считается извращением...

Вряд ли извращением, конечно, но неоправданным риском точно. Доверять сие стоит лишь транслятору с ЯВУ, т.к. он не ошибается.

[aaarrr]

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

Нет, батенька, не тянут такие конструкции на "хак": слишком уж просто и очевидно.

P.S. Блестящий, остроумнейший неологизм! Примите мои искренние поздравления, маэстро.

Да. Но команда IN флаги не меняет, насколько я помню.

Код

in      reg, SREG
sbrc    reg, BIT
rjmp    xxx

Несколько вычурно, не находите? Да и с GE/LT все равно облом.

Вряд ли извращением, конечно, но неоправданным риском точно. Доверять сие стоит лишь транслятору с ЯВУ, т.к. он не ошибается.

Объясните мне, где я рискую ошибиться в такой конструкции:

Код

brhs    PC + 2
rjmp    xxx

[Oldring]

Нет, батенька, не тянут такие конструкции на "хак": слишком уж просто и очевидно.

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

Объясните мне, где я рискую ошибиться в такой конструкции:

Код

brhs    PC + 2
rjmp    xxx

На первый взгляд, конечно, кажется, что "brhs PC + 2" текстуально полностью эквивалентно скипу следующего rjmp, если применять единообразно. Но это неверно. Помню, как-то ради быстрого перехода на больший кристалл заменил в проекте все rjmp и rcall на jmp и call текстовой заменой

Доверять сие стоит лишь транслятору с ЯВУ, т.к. он не ошибается.

Все врут.

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

[SysRq]

Несколько вычурно, не находите?

Нахожу, конечно же. Однако, информативность кода та же, что без меток, но меньше шансов ляпнуть ошибку.

Да и с GE/LT все равно облом.

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

Объясните мне, где я рискую ошибиться в такой конструкции:

Код

brhs    PC + 2
rjmp    xxx

В процессе правки заменить rjmp на jmp, потому что код разросся (а правили сложно, долго, и где-то много ниже этого вот места), и компилятор ругался на невозможность relative jump. Ошибка по невнимательности. Человеческий фактор.

[aaarrr]

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

Какой текстовый поиск? Речь идет об очевидных конструкциях. Ну куда еще может быть передано управление командой "rjmp PC - 1", кроме как на предыдущую?

Нахожу, конечно же. Однако, информативность кода та же, что без меток, но меньше шансов ляпнуть ошибку.

Информативность много ниже. Я уж не говорю о потерянном времени и затраченном регистре.

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

Ну, так можно и до виртуальной машины дойти потихоньку.

На первый взгляд, конечно, кажется, что "brhs PC + 2" текстуально полностью эквивалентно скипу следующего rjmp, если применять единообразно. Но это неверно. Помню, как-то ради быстрого перехода на больший кристалл заменил в проекте все rjmp и rcall на jmp и call текстовой заменой

В процессе правки заменить rjmp на jmp, потому что код разросся (а правили сложно, долго, и где-то много ниже этого вот места), и компилятор ругался на невозможность relative jump. Ошибка по невнимательности. Человеческий фактор.

Если уж мы имеем дело с ассемблером, то человеческий фактор и так проявляется на каждом шагу. В конце концов, можно и метку в процессе copy-paste воткнуть не туда. Поэтому элементарную внимательность никто не отменяет.

[SysRq]

В конце концов...

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

[aaarrr]

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

Я далек от того, чтобы вводить классификацию ошибок. А время на поиск и устранение вообще трудно предсказать. Вот попробуйте найти ошибку в такой конструкции:

Код

    ldi     r16, 0
    sbrс    r17, 2
    ldi     r16, 1

Пример вполне себе из жизни. Не дословно, конечно, но изюминка сохранена.

[SysRq]

Вот попробуйте найти ошибку...

Чесгря, шрифты ошибку сдали сразу (сглаживание не работает на латинице в [сode]). Но, однако, разве компилятор не предупреждает о подобном?

[aaarrr]

Но, однако, разве компилятор не предупреждает о подобном?

Не знаю, как на новых, но аврасм из студии 3.56 даже не морщится.
Да со шрифтами тогда мне так не повезло, естественно

[forever_student]

Вы с чего взяли, что я не читал дэйтшиты и книги Евстифеева?
На чем такая уверенность основана, на том, что я задал вопрос?

Sorry, если обидел... Не хотел.
Не уверенность, а , скорее, удивление ... не тому, что задан вопрос, а
какой вопрос задан.

..А книг, могу еще штук 16 перечислить, хотите?

Смысл? Их читать надо

..Я сказал, что выложу все свои "фи" атмегам, а их много накопилось, и выложу.
Но, сейчас я занят. Все позже..

Было бы очень интересно.

[demiurg_spb]

Я далек от того, чтобы вводить классификацию ошибок. А время на поиск и устранение вообще трудно предсказать. Вот попробуйте найти ошибку в такой конструкции:

Код

    ldi     r16, 0
     sbrс    r17, 2
     ldi     r16, 1

Пример вполне себе из жизни. Не дословно, конечно, но изюминка сохранена.

Что-то не прожевать изюминку. Не вижу ничего криминального.
Колитесь, в чём фишка

[SysRq]

Колитесь, в чём фишка

Не можем. Топикстартер просил ни слова о том, что тут только кажется таковым, создавая фишку

[demiurg_spb]

Так ведь интересно!

[ILYAUL]

Да интересно. Хоть я понял в чём ошибка решил проверить , а поймает её студия и получил результат не ловит. Хотя шрифт тут же ее выдал

Эскизы прикрепленных изображений