Изменение размера кода при использовании дальних указателей в C
Я работаю в отделе софтверной компании, которая занимается в основном проектированием автомобильных сетей. Мы пишем стеки сетевых протоколов в основном на C. Недавно мне был назначен проект, который требовал использования контроллера HC12 Freescale. Первоначально написанный стек протоколов поддерживал использование небанкованной оперативной памяти и как накопленной, так и небанкованной флэш-памяти. В назначенном мне проекте клиент требует использования оперативной памяти в банках, а не оперативной памяти (причина мне неизвестна). Работая над разработкой этого проекта, я понял, что могу использовать дальние указатели для доступа (чтения / записи) к оперативной памяти.
Мой вопрос: когда я использовал дальние указатели для доступа к банковской оперативной памяти, размер кода моей библиотеки увеличился на 10 Кбайт. Это нормально? В справочном руководстве компилятора, который я использую (codewarrior), размер дальнего указателя упоминается как 3 байта, в отличие от обычного указателя, который имеет размер 2 байта. Может ли этот дополнительный 1 байт действительно вызвать такую разницу в размере кода? Есть ли другой способ, который не включает использование дальних указателей, где я все еще могу получить доступ к банковской памяти?
Любые полезные ответы на мои вопросы будут высоко оценены.
2 ответа
Первоначально банковская память на HCS12 использовалась только для программного кода во флэш-памяти, и в этом случае вы не заметите большой разницы в размере программы. Единственная разница будет заключаться в том, что вызовы подпрограмм должны будут использовать инструкции в банковской памяти (CALL, RTC, а не JMP, RTS), которым требуется на несколько байтов больше памяти программ на вызов функции.
Позже они выпустили устройства, которые имели как флэш-память, так и оперативную память (некоторые из HCS12X и т. Д.). ОЗУ явно предназначено для данных, а не для памяти программ.
Проблема в том, что HCS12 является 16-битным процессором, поэтому он не может легко обрабатывать 24-битные указатели данных. Это означает, что все такие данные обработки кода в банковской памяти станут довольно неэффективными: для каждого доступа (через "дальний" указатель и т. Д.) Потребуется настроить регистр страниц, который представляет старшие 8 бит 24-битного адреса. Как только это будет сделано, он может читать / записывать данные в 16-битную часть адреса с помощью обычных инструкций, и аппаратное обеспечение отобразит их на правильной странице. И как только это будет сделано, программа также должна восстановить регистр страницы.
Вполне возможно, что компилятор не сможет хорошо оптимизировать доступ к выгружаемым данным - теоретически вы можете установить регистр страницы, а затем получить доступ ко всем данным на этой странице, прежде чем вам нужно будет восстановить их. Но во время компиляции компилятор может не знать, где именно будет размещена переменная.
Вы можете легко увидеть, какой код на самом деле генерируется с помощью дизассемблера Codewarrior. Также обратите внимание, что Codewarrior всегда был довольно нефункциональным, когда речь заходит об оптимизации: никогда не совсем понятно, какие оптимизации должны быть явно включены, а какие являются "встроенными". Убедитесь, что у вас действительно включены все соответствующие оптимизации.
В целом, по возможности избегайте накопленной памяти. Вы можете использовать небанкованную модель памяти объемом до 64 КБ. Только когда вы выходите за эти пределы, вам нужна страничная память. Возможно, именно поэтому ваш клиент требует этого, скорее всего, он исчерпал ОЗУ.
Да, обязательно увеличивается не размер указателя, а код, который обрабатывает "дальние" указатели (какими бы они ни были на hc12)
Само ядро действительно поддерживает только 16-битные указатели, и эта подкачка страниц является чем-то вроде дополнения и требует, чтобы программа работала в ручном режиме.
Хорошая новость в том, что теперь вы пользуетесь пейджингом, так что 10k не ужасно.