Статья объясняет идеологию мультисегментных приложений для PalmOS с использованием GCC. В информатике существует малоизвестный термин ABI - Application Binary Interface. Этим термином называют набор особенностей компьютерной архитектуры, которые нужно учитывать при создании приложения. ABI может накладываться процессором: направление роста стека, размер элемента данных в стеке, порядок байт в слове итд. Также ABI может накладываться операционной системой. Тогда в ABI входит способ вызова системного API, специфика использования адресного пространства и прочие нюансы. Изменения, которые вносятся в GCC для компиляции под PalmOS, нужны именно для соответствия PalmOS ABI. Что такое приложение с точки зрения PalmOS? Приложение - это база ресурсов. Четыре ресурса из этой базы используются для исполнения программы. Это ресурс 'code' #1, в котором собственно и хранится исполняемый код, который запускается с нулевого байта ресурса. Также из ресурса 'code' #0 берется размеры области глобальных данных. Из ресурса 'pref' #0 берется размер стека. И ресурс 'data' #0 используется для инициализации глобальных данных. Все! До всего остального содержимого базы приложения PalmOS дела нет. Подробности можно почитать здесь: http://www.linuxmafia.com/pub/palmos/development/prc-format.html Такой способ позволяет запускать программы практически "на месте", выделяя только память под стек и глобальные переменные. Какие ограничения накладываются на простое односегментное приложение? * Размер ресурса 'code' #0 ограничен 64К. Это ограничение было у PalmOS включая версию 4 и у Хотсинка до версии 5 включительно. Условное ограничение сегмента GCC в 32К лечится заменой скрипта для линкера на text_64k. * Ограничение смещения у команды вызова процедуры в 32К. То есть, если сегмент больше 32К, то функция из начала не может вызвать функцию в конце сегмента. Это можно обойти путем перемещения вызываемых функций "поближе" к вызываемым или созданием функций-заглушек в середине сегмента. * Ограничение размера глобальных данных программы. Общий объем глобальных данных (в сумме инициализированных и неинициализированных) должен укладываться в 64К. Замечу, что константные инициализированные данные помещаются в сегмент кода. Что усложнится при попытке добавить новый сегмент? Самая большая проблема - межсегментный вызов процедуры. В случае одного сегмента расстояние между процедурами постоянно и код вызова не меняется после компиляции. В случае межсегментного вызова ресурсы могут располагаться в произвольных участках памяти и смещение нужно корректировать. Замечу, что в односегментном приложении также происходит коррекция области данных. В нижележащем примере значение переменной pfn будет скорректировано. Это возможно, поскольку сегмент данных находится в динамической памяти. Копировать же все сегменты в динамическую память для коррекции неразумно и расточительно. void foo(void){ } void *pfn = foo; Все (оба ;-) ) производители компиляторов для PalmOS предлагают свои поддержки мультисегментности. Gcc предлагает следующий способ: * Всем функциям приписывается атрибут с именем сегмента. Функции помещаются в соответствующие сегменты единственного получаемого ELF-файла. * В области глобальных переменных хранятся адреса всех сегментов * При вызове функции из другого семента происходит сложение смещения функции от начала сегмента к адресу сегмента из глобальной памяти В чем ограничения такого метода: * Использование глобальных данных. Это обозначает, что при вызове программы без глобальных переменных, вызов функций из других сегментов попросту невозможен. При попытке вызвать произойдет обращение к несуществующей области глобалных данных и Fatal Alert неизбежен. * Этот способ никак не расширяет область глобальных данных. * Проблемы с доступом к константным данным. Константные данные могут оказаться в другом сегменте и тебовать наличия глобальных данных. * Неявные функции и методы класса. C++ богат на неявную генерацию неявного кода. Следует контролировать куда будет помещен код темплейтов и не инлайновых инлайнов. Подробное описание мультисегментной архитектуры GCC здесь: http://prc-tools.sourceforge.net/doc/prc-tools_3.html Существует альтернативный способ создания мультисегментных приложений с помощью утилиты multilink. Смотри описание здесь: http://www.djw.org/product/palm/multilink/ Multilink использует другую идею: * Исходные файлы компилируются как обычно. Не нужно указывать сегменты в исходном коде * Утилита получает на вход объектные файлы и необязательный список разбиения функций по сегментам. * Утилита разбивает все функции по сегментам по списку и добивает оставшиеся до указанного размера сегментов. * Если функция foo из сегмента segA вызывает bar из сегмента srgB, то в segA добавляется заглушка для bar, вызывающая bar. * Для вычисления адреса bar используются данные, которые хранятся в feature memory. Тем самым наличие глобальных данных необязательно. * Полученные сегменты добавляются в программу. У этого решения есть один большой минус - невозможен доступ к константным данным из другого сегмента.