фон-нейман

[dibr]

А эта ваша ородруина (точнее клон digispark на attiny85, но IDE там используется ардуинное) меня удивила. Я как-то не привык, что бывают компьютеры с не фон-неймановской архитектурой (а если и бывают, что это может вдруг оказаться моей, а не компилятора, проблемой), а тут вдруг. "Фон-Нейман", если что, это когда код и данные выполняются из одной памяти, а "Гарвардская архитектура" (это которая не фон-нейман), соответственно, когда данные и код "не могут быть смешаны".

Короче, я как-то привык, что байт кода и байт данных - это одинаковые по "цене" байты. И что если нужно для какого-то массива данных проделать какое-то действие (в моём случае "массив" - это положения ножек-глазиков-лампочек монстра, а "действие" - собственно дрыгание и мигание), то надо собрать массив элементов данных в "массив[элементов]" данных, и в цикле делать "действие(массив[элемент++])". Потому что можно, конечно, массив в массив не собирать, а написать много строчек вида "действие(данные1); действие(данные2); ... действие(данныеN);", но данные при этом один фиг окажутся внутри кода, плюс добавится много повторяющихся операций по засовыванию их в регистры/стек/whatever для передачи "действию" и вызов "действия", поэтому байтов в сумме понадобится больше, а зачем.

У attiny85 - 512 байт оперативной памяти "для переменных", и 8кб флэша (доступно около 6кб, остальное под бутлоадер) "для кода". Массив данных целиком ложится в оперативную память, в результате при 10 байтах на элемент и с учётом оверхеда на всё остальное, у меня получилось максимум 44 строчки-действия, дальше память заканчивалась.
А если делать через "действие(данные1); ... действие(данныеN);" - расходуемая оперативная память не изменяется, и хотя на каждое действие в результате расходуется больше памяти - это "память кода", которой у нас более чем в 10 раз больше, поэтому и действий можно упихать больше. При этом дело не в том, что "память кода" - типа read-only, а в переменные можно писать: волшебные слова типа const ничего не изменили, массив по прежнему ложился в оперативку. Видимо, данные в "памяти кода" реально нельзя адресовать как переменные, только использовать как операнды команд. Отдельно, кстати, непривычно что процессор похоже выполняет программу прямо из флэша - переписывание в "shadow RAM" как-то привычнее. Хотя, флэш там мелкий, может быть его можно адресовать быстро и "в лоб", а не как в флэш-карточках.

Впрочем, я уложился в 42 действия, так что пока некритично :-) Но забавно.

Comments

[blackyblack.livejournal.com]

Там надо размещать массив в памяти кода с атрибутом __flash или типа того. Напрямую адресовать его нельзя, но можно сделать char a = mas[i]; и уже этот a будет размещён на стеке и с ним можно творить всякое.

[dibr.livejournal.com]

Ородруинская среда разработки (Arduino IDE 1.8.2) __flash ("__flash int mydata[] = .... (http://www.atmel.com/webdoc/avrlibcreferencemanual/porting_1iar_porting_flash.html)") не съела. А вот PROGMEM из комментария выше - вроде работает (запускать не пробовал, но ошибок не выдаётся).
Видимо, разные компиляторы.

[ex0_planet]

Ошибок не выдается, но работать все равно не будет. Это старая проблема gcc-avr: класть-то в progmem он кладет, но не генерирует правильный код для работы с этой памятью; точнее, он считает все адреса принадлежащими RAM, и в любом случае генерирует код для RAM. Для части функций из libc там доступны дубликаты с суффиксом _P, а если работать самому, то надо использовать pgm_read_byte/pgm_read_word, итд, итп. Аналогично с eeprom.

[dibr.livejournal.com]

Да, про the pgm_read_* я уже прочитал, но ещё не тестировал. Будет время (если захочется усложнить дрыгоножество и глазомигательство) - проверю :-)

[blackyblack.livejournal.com]

Да, это я, по привычке, для IAR написал. Для GCC другой синтаксис.