Вопрос к ассемблерщикам, Автоматическая растановка адресов Опции

[_Алексей_]

Пример: .equ Napruga = SRAM_START+123
Таких директив может быть сотня и более.
Иногда возникает необходимость вставить посередине новую директиву или расширить массив. Из-за этого возникают проблемы, что нужно менять адресацию. Приходиться много править.
Существуют ли какие-нибудь методы или вспомогательные программы позволяющие решить данную проблему?

[CDT]

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

Если не хочется чего - не то делать - надо подумать, как этого не делать.

Код

.dseg

.org ... (если очень хочется, но мне не разу не понадобилось. Опять потом искать и менять)

dRcvdBuf:;начало буфера (например, приема)
  dRcvdLen:    .byte    1
  dRcvdAdr:    .byte    2
  dRcvdTime:    .byte    4
  dRcvdName:    .byte    20
  dRcvdErrors:    .byte    1
  dRcvdVolts:    .byte    2
dRcvdBufEnd:;это что бы следить за концом буфера

;И вставляй, что хочешь, само настроиться

;что бы привязать к началу буфера (для использоввания указателей и поддержания
одинакового смещения в разных программах) можно посчитать смещения от начала буфера

Код

.equ shRcvdLen=dRcvdLen-dRcvdBuf
.equ shRcvdAdr=dRcvdAdr-dRcvdBuf
;....................................................
.equ cRcvdBufLen=dRcvdBufE-dRcvdBuf;длина буфера

   ldd   rTmp,z+shRcvdLen

;Можно макрос написать:

Код

.macro mac_BufSet
    @0: .byte @2
    .equ @1=@0-BufStart
.endm
;-------------------------------
.dseg
dRcvdBuf:    
.set BufStart=dRcvdBuf

  mac_BufSet dRcvdLen,shRcvdLen,1
  mac_BufSet dRcvdAdr,shRcvdAdr,2
  mac_BufSet dRcvdTime,shRcvdTime,4
  mac_BufSet dRcvdName,shRcvdName,20
...................
dRcvdBufEnd:

Как и на зеркало, не стоит на ассемблер пенять раньше времени.
Там еще препроцессор есть. Весьма удобная вещь, если научиться.

P.S.
Пришла по дороге идея, но прямо сейчас не на чем проверить:

Код

macro mac_BufSet
    d@0: .byte @1
    .equ sh@0=d@0-BufStart
.endm

  mac_BufSet RcvdLen,1
  mac_BufSet RcvdAdr,2

Еще меньше писанины

[_Pasha]

;Можно макрос написать:

Код

.macro mac_BufSet
    @0: .byte @2
    .equ @1=@0-BufStart
.endm
;-------------------------------

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

error: .byte directive illegal in macro definition

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

[galjoen]

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

+1
А я вот не совсем по теме, но то, что всегда применяю. Тоже про доступ к данным.
Чаще всего приходится использовать таблицы в FLASH или ОЗУ размером до 256 байт или слов. В регистре находится N элемента (индекс массива) и к этому N нужно прибавить адрес начала массива. А массив не выровнен, т.е. может переходить через границу 256. Т.е. старший байт адреса может отличаться на 1. Стандартный способ это 4 такта. Но есть способ лучше. Я написал макро, и всегда и использую.

Код

.MACRO TAB_Z
    subi    ZL,low(-low(@0)); получение
    sbc    ZH,ZH    ; адреса в
    subi    ZH,low(-high((@0)-1))-1; таблице
.ENDMACRO

Перед вызовом смещение д.б. в ZL. Параметр в этой макрокоманде - адрес начала таблицы. В байтах если это данные, в словах если это таблица переходов.
Такие макрокоманды у меня обычно и для Y и для X описаны. Рекомендую...

[_Pasha]

Но есть способ лучше.

Респект! А говорят, что про асм и AVR уже все известно... 

[Maik-vs]

Какое странное и невнятное обсуждение. То есть некоторые обвиняют ассемблер в его "бедности", не понимании структур и т.д. А я вот видел множество обсуждений сишников: то как объявить переменную в нужной памяти, то как проинвертировать бит в порту то ещё что-нибудь, что у ассемблерщика вызовет недоумённую улыбку.
Такой язык. И можно написать кучу макросов каждому на свой вкус, в том числе и для доступа к структурам. К Вашим структурам. А вообще-то конечно, кому что - есть и VBA или вот ЛИСП интересный язык

[SasaVitebsk]

Какое странное и невнятное обсуждение. То есть некоторые обвиняют ассемблер в его "бедности", не понимании структур и т.д. А я вот видел множество обсуждений сишников: то как объявить переменную в нужной памяти, то как проинвертировать бит в порту то ещё что-нибудь, что у ассемблерщика вызовет недоумённую улыбку.
Такой язык. И можно написать кучу макросов каждому на свой вкус, в том числе и для доступа к структурам. К Вашим структурам. А вообще-то конечно, кому что - есть и VBA или вот ЛИСП интересный язык

Ещё раз отмечаю. Само написание проги на асме, как правило занимает даже меньше времени (особенно для млких проектов) чем на асме. Я имею ввиду грамотное написание там и там. Но ... сопровождение и развитие проекта на Си ... на порядок быстрее и комфортнее. На порядок это в 10 раз. И это не для красного словца, а это приблизительно мои оценки затрат.

По обсуждаемой теме всётаки на мой взгляд правильнее автоматическое выделение памяти. А не относительное со смещением.
То есть я не вижу преимуществ (Зато кучу недостатков) в конструкции типа:

Код

.equ    SRAM_NEXT_1          = SRAM_START + 1;
.equ    SRAM_NEXT_2          = SRAM_NEXT_1 + 10;
.equ    SRAM_NEXT_3          = SRAM_NEXT_2 + 100;

На мой взгляд правильнее конструкция типа:

Код

            .dseg
    .org    SRAM_START_ADR
SRAM_START:     .byte     1
SRAM_NEXT_1:   .byte     10
SRAM_NEXT_2:   .byte     100
SRAM_NEXT_2:

Причём 1,10,100 я бы задал через "equ".

Точно также я работаю и со структурами.
Например:

Код

; Структура X(i-1), Y(i-1)*2, Y(i-2)*2, Z(i-1)*2, Z(i-2)*2
MADC:        .byte    6*9    ; Измерения по каналам
MADC_SR:                ; Усреднённое значение измерения по каналам
MADC_0:        .byte    1    ; Усреднённое значение измерения канала 0
MADC_1:        .byte    1    ; Усреднённое значение измерения канала 1
MADC_2:        .byte    1    ; Усреднённое значение измерения канала 2
MADC_3:        .byte    1    ; Усреднённое значение измерения канала 3
MADC_4:        .byte    1    ; Усреднённое значение измерения канала 4
MADC_5:        .byte    1    ; Усреднённое значение измерения канала 5
MADC_SRx2:    .byte    6    ; Усреднённое значение измерения по каналам после второго усреднения
MStrel:        .byte    12    ; Значение для стрелки в шагах
MTStrel:                ; Текущее значение для стрелки в шагах
MTStr0:        .byte    2
MTStr1:        .byte    2
MTStr2:        .byte    2
MTStr3:        .byte    2
MTStr4:        .byte    2
MTStr5:        .byte    2

Для IAR ассемблера, естественно, используется принцип размещения структур Си. Причём очень органично всё получается.

Приведу пример:
Вот структура в Си

Код

struct
{
uint8_t    OutBuf[32];                                    // 0
uint8_t    *HeadOutBuf,*EndOutBuf;                        // +32 +34
uint8_t    AddrWake;                                    // +36
uint8_t    ComAnswerWake,                                // +37
            ParComAnswer,                                // +38
            Com485;                                        // +39
uint16_t    LenPack485;                                    // +40  RS232. Длина    передаваемого пакета данных
uint8_t    *EndInBuf;                                    // +42  RS232. Указатель на конец принятых данных
struct
{
   uint8_t    Answ485     : 1,                            // Выдать ответ по rs485
            Esc485      : 1,                            // Пришёл код FESC с RS485
            RcvCompl    : 1,                            // Разрешить исполнение    команд
            Ldr            : 1,                            // Разрешить загрузку ПО
            NoEndPacket    : 1;                            // Пакет незавершён
} Flag;                                                // +44
}  volatile Out485;

Вот её объявление на ASMе

Код

EXTERN    Out485

#define        HeadOutBuf        32                            // +32
#define        EndOutBuf        34                            // +34
#define        AddrWake        36                            // +36
#define        ComAnswerWake    37                            // +37
#define        ParComAnswer    38                            // +38
#define        Com485            39                            // +39
#define        LenPack485        40                            // +40  RS232. Длина    передаваемого пакета данных 16
#define        EndInBuf        42                            // смещение +41  RS232. Указатель на конец принятых данных
#define        FlagS            44                            // +43 Признаки
#define        Answ485            0                            // Бит 0 Выдать ответ по rs485
#define        Esc485            1                            // Бит 1 Пришёл код FESC с RS485
#define        RcvCompl        2                            // Бит 2 Разрешить исполнение команд
#define        Ldr                3                            // Бит 3 Разрешить загрузку ПО
#define        NoEndPacket        4                            // Бит 4 Пакет незавершён

Вот пример обращения к полю

Код

        ldd        crc485,Z+AddrWake            // AddrWake
        std        Z+HeadOutBuf,ZL                // HeadOutBuf
        std        Z+HeadOutBuf+1,ZH            // HeadOutBuf+1
        ldi        data485,FEND

[adc]

Само написание проги на асме, как правило занимает даже меньше времени (особенно для млких проектов) чем на асме.

"Золотые слова Юрий Бенедиктович и человек ты золотой,не бережёшь ты себя,отдохнуть тебе надо." (НР)