Если вы можете сказать своему компилятору C надежно поместить некоторую метку (или переменную) buffer_end
сразу после uint32_t buffer[32];
, ваш код на ассемблере может просто использовать эту ссылку buffer_end
вместо того, чтобы неловко заставить компоновщик добавить два значения .
Это легко сделать, если определить буфер в файле .S
, но не так просто в файле .c
.
FWIW, возможно, что .o
файлы содержат некоторую информацию о размере. Я генерирую файл .o
из файла с двоичными данными для одной из моих систем:
$ avr-objcopy -B avr -I binary -O elf32-avr --readonly-text --rename-section .data=.text,contents,alloc,load,readonly,code foo.bin foo.o
Это дает мне foo.o
, который производит следующее после nm foo.o
:
00000c00 T _binary_foo_bin_end
00000c00 A _binary_foo_bin_size
00000000 T _binary_foo_bin_start
Тип _binary_foo_bin_size
может быть полезен, если его можно адаптировать к вашему случаю - если вам все-таки нужен размер над ярлыком buffer_end
.
Кстати, если вы пишете для одного из чипов AVR, которые имеют более 256 байтов SRAM, ваш код, вероятно, должен будет правильно использовать макросы lo8
/ hi8
для проверки всех 16 битов адреса.