Привет!
Mon Apr 04 2005 10:19, Alexey Boyko wrote to Alexander Golov:
...
AG>> Т.е. выделить, скажем, из 49 вариантов адресации команды MOV пару AG>> частных случаев, когда с одной стороны адресуется регистр, а с другой AG>> память и назвать это ld/st? Как я понимаю, для тебя это в явном виде AG>> символизирует направление трафика ядро-память ещё на уровне мнемоники, AG>> но это же очень частный случай.
AB> Hе совсем так. ld/st - для load/store архитектуры.
Ну уж PIC18 то явно не из этой категории, dsPIC немного поближе.
AG>> Возьмём, например, 3-адресную AG>> арифметическую команду, где как один из источников, так и результат AG>> могут быть как внутри ядра (т.е. в регистре), так и в памяти и тебе AG>> неизбежно придётся интерпретировать способ адресации даже для простого AG>> установления направления движения данных.
AB> То есть как в i386? Вот и смотри как там сделано.
Насколько я помню, там как раз всё вытекает их операндов, для пересылок практически одни MOV'ы.
AB>>> Так это куда, W:=fsr2l или fsr2l:=W ? AG>> Естественно -- Move F To W, т.е. FSR2L->W, или алгебраически W=FSR2L.
AB> Hет, не естественно. (imho)
Если используется слово "move" означающее "перемещение", то естественен порядок перемещения того, что сразу за словом move куда-то в другое место, потому что не по людски сначала сказать куда переместить, а потом уже что. А для обратного порядка следует использовать слово "присвоить" ("assign", или ещё какой-то синоним).
AG>> Флажок "f", означает, что результат положить в память (т.е. туда же AG>> откуда взял операнд), "w" -- в wreg. По умолчанию подразумевается "f", AG>> в явном виде нужно указывать только "w". Флажок "c" это HI-TECH'евская AG>> кличка для "a", флажка доступа к Access RAM, при программировании на AG>> ассме указывать не требуется, т.к. автоматически подставляется в AG>> зависимости от объявленного адреса переменной или типа доступа (при AG>> создании перемещаемых модулей).
AB> В даташите ничего нет про поведение конкретных трансляторов асма.
Ну да, нужно читать описания на них.
AG>> как при написании, поэтому я обычно не испытываю каких-либо неудобств.
AB> Я верю, что можно привыкнуть.
Да не к чему привыкать. Зрить нужно в корень: какую байду тебе выдал компилятор вместо чего-то ожидавшегося компактного, потому что его оптимизатор опять отказывается выполнять свою работу, а на флажки и маски адресов просто нет нужды обращать внимания, т.к. в этом деле компилятор не ошибается.
...
AG>> В чём суть вопросов? Что система команд не очевидна, для того, кто её AG>> впервые видит?
AB> Да.
AG>> Так это про любую можно сказать, AVR в том числе.
AB> Hу, не знаю. Мне после x86 AVR был понятнее. Даже без чтения док можно AB> было примерно представить что делает та или иная команда. С пиком нет. AB> Вроде и понятно, что делает, а откуда берет данные и куда ложит - фиг его AB> знает.
Это лишь вопрос привычки, в данном случае ты имел дело с процами с аналогичными подходами к решениям. Вот и я после многих лет работы с 6502, достаточно легко воспринимал решения от Motorola, и наоборот, попытки программировать 386-й по началу были довольно мучительны, а ещё позже PIC16 в первый момент поставил в ступор своей инопланетностью. Но уже через пару месяцев я вовсю лепил для них программы без каких-либо проблем, а вот неудачная попытка воспользоваться, несколько лет назад, мотороловским HC08 оставила столь удручающее впечатление, что я до сих пор с трудом представляю, что сможет подвигнуть меня ещё раз к ним подойти.
Александр Голов, Москва, snipped-for-privacy@mail.ru