Комментарии 14
Что-то мне кажется, что быстрее будет clang+llvm допилить, там и api плагинов нормальное и процесс разработки более публичный.
Привет. Недавно я собирал грабли в gcc добавляя в него поддержку для процессора из esp8266. Могу посмотреть на ваш случай.
Было бы отлично, если посмотрите: нужно, чтобы родилась уверенность в том, что эта задача для вас решаема.
С esp’шкой всё получилось? Правильно я понимаю, что вы для неё добавляли перевод из glimpified tree в её собственный asm?
С esp’шкой всё получилось? Правильно я понимаю, что вы для неё добавляли перевод из glimpified tree в её собственный asm?
нужно, чтобы родилась уверенность в том, что эта задача для вас решаема.
Ок. Вопросы:
— всё описанное происходит с mainline gcc или с какой-то avr-специфичной веткой/репозиторием?
— обязательно ли это должен быть плагин? Может быть добавить опцию и попробовать закоммитить в транк gcc (или avr-специфичной ветки)?
С esp’шкой всё получилось? Правильно я понимаю, что вы для неё добавляли перевод из glimpified tree в её собственный asm?
Всё получилось. Поддержка xtensa уже была в gcc, я расширил её на ABI call0. Это выразилось в основном в генерации специфических прологов и эпилогов для функций. Результат.
— всё описанное происходит с mainline gcc или с какой-то avr-специфичной веткой/репозиторием?
Рискую сейчас глупость сказать, но разве в mainline gcc нет таргета avr? avr-gcc, avr-g++ и прочие avr-* — это ж просто врапперы над каноническими gcc, g++ и т.д. Или я не прав? Если всё так, то да, стоит добавлять функционал в mainline.
— обязательно ли это должен быть плагин? Может быть добавить опцию и попробовать закоммитить в транк gcc (или avr-специфичной ветки)?
Совсем не обязательно. Даже лучше если у gcc появится какие-нибудь `-fflash-vtbl -fno-pure-vtable`. Я думал о плагине, т.к. он будет работать вне зависимости от решений людей-меинтейнеров. «Попробовать закоммитить в транк» звучит опасно. А если попытка не пройдёт? Т.е. всё работает, но просто флаг не хотят принимать по политическим причинам?
Я не знаком с настроениями среди разработчиков GCC. Быть может мои опасения напрасны?
Всё получилось.
Супер! Покопал ваши коммиты. Внушает доверие. А патч приняли в итоге в trunk?
Рискую сейчас глупость сказать, но разве в mainline gcc нет таргета avr? avr-gcc, avr-g++ и прочие avr-* — это ж просто врапперы над каноническими gcc, g++ и т.д. Или я не прав?А вот про это, собственно, и спрашивают. Так бывает, что в upstream что-то такое живёт, но реально люди пользуются каким-то форком, про который upstream ничего не знает.
«Попробовать закоммитить в транк» звучит опасно. А если попытка не пройдёт? Т.е. всё работает, но просто флаг не хотят принимать по политическим причинам?Я знаком с несколькими. Вполне адекватные люди. Ни про какие отказы что-то делать «по политическим причинам» я никогда не слышал (за исключением проблем с лицензиями, что, понятно, никак не затрагивает вновь написанный код специально для GCC).
Я не знаком с настроениями среди разработчиков GCC. Быть может мои опасения напрасны?
А вот технических требований у них бывает вагон и маленькая тележка. То есть, грубо говоря, то, что вы хотите делается «с помощью лома и какой-то матери» за несколько дней, а вот допиливание до варианта, который upstream примет — это скорее несколько недель. В основном несколько недель переписки, не кодинга.
разве в mainline gcc нет таргета avr?
Таргет есть, вопрос — им ли вы пользуетесь.
«Попробовать закоммитить в транк» звучит опасно. А если попытка не пройдёт? Т.е. всё работает, но просто флаг не хотят принимать по политическим причинам?
Судя по тому, что запись в багзилле gcc по одной из ваших ссылок не закрыта как wontfix, надежда есть.
А патч приняли в итоге в trunk?
Да, он попал в релиз 5.1. Ссылочка — как раз на официальное git-зеркало gcc на gcc.gnu.org.
Пошерстил сейчас, что за toolset кладут в Arduino IDE под Windows, какие зависимости Arduino IDE от gcc в Linux. Не вижу причин, по которым нужно что-то отличное от меинстрима. Стало быть делаем на нём.
Надежды, мечты… :) В общем да, вселяет оптимизм.
Классно! Вселяет ещё больше.
Судя по тому, что запись в багзилле gcc по одной из ваших ссылок не закрыта как wontfix, надежда есть.
Надежды, мечты… :) В общем да, вселяет оптимизм.
Да, он попал
Классно! Вселяет ещё больше.
Интересуюсь на всякий случай: шаманство с linker script (разместить все vtable в ROM, тем самым обязав конпелятор генерировть соответствующий код) не даёт результата? Или размещением vtable нельзя управлять в линкере?
Сам спросил сам отвечу. Не получится. Хотя можно (если постараться) сказать линкеру размещать vtables в ROM ничо это не меняет, инструкция ldd генерируется на этапе компиляции. Всё таки нужно в кишки gcc лезть и делать опцию.
Написал в личку, но, похоже, стоит продублировать и здесь. На ваше счастье три года назад этот туннель прокопали почти что до самого конца. Начиная с GCC 4.7 avg-gcc поддерживает ссылки на объекты в флеше (и даже 24-битные «ссылки куда угодно», хотя это вроде как тут не нужно).
Остаётся сделать опцию, которая на «невидимую» ссылку, указывающую на vtable повесит нужный атрибут. В backend'е ничего править не придётся: теоретически он сам должен будет разобраться какой командой что читать, если атрибуты будут правильно указаны. В принципе можно даже сделать версию, которая для части объектов будет держать vtable в памяти, а для части — во флеше. А можно ещё поддержку разных моделей (вспомним C/С++ в DOS, да: small/medium/compact/large вполне прозрачно накладываются на AVR, tiny и huge, понятно, смысла не имеют). Но, конечно, так широко сразу шагать не стоит — как бы штаны не порвать.
P.S. Скорее всего начать стоит именно с опции, а не с расширения N1275 для C++. А то дело увязнет на год, который уйдёт на то, чтобы придумать — как, чёрт побери, «правильно» расширить именованные адресные пространства с учётом «невидимых» указателей в C++ и что делать когда, скажем, один и тот же указатель должен бы получить два разных аттрибута (в случае одиночного наследования большинство компиляторов, в том числе GCC, делают «униварсальную» vtable которую «можно читать» как vtable для предка и для потомка… а если они должны «жить» в разных местах — как быть?).
Остаётся сделать опцию, которая на «невидимую» ссылку, указывающую на vtable повесит нужный атрибут. В backend'е ничего править не придётся: теоретически он сам должен будет разобраться какой командой что читать, если атрибуты будут правильно указаны. В принципе можно даже сделать версию, которая для части объектов будет держать vtable в памяти, а для части — во флеше. А можно ещё поддержку разных моделей (вспомним C/С++ в DOS, да: small/medium/compact/large вполне прозрачно накладываются на AVR, tiny и huge, понятно, смысла не имеют). Но, конечно, так широко сразу шагать не стоит — как бы штаны не порвать.
P.S. Скорее всего начать стоит именно с опции, а не с расширения N1275 для C++. А то дело увязнет на год, который уйдёт на то, чтобы придумать — как, чёрт побери, «правильно» расширить именованные адресные пространства с учётом «невидимых» указателей в C++ и что делать когда, скажем, один и тот же указатель должен бы получить два разных аттрибута (в случае одиночного наследования большинство компиляторов, в том числе GCC, делают «униварсальную» vtable которую «можно читать» как vtable для предка и для потомка… а если они должны «жить» в разных местах — как быть?).
На прошедших выходных у меня нахардкодился вот такой прототип: github.com/jcmvbkbc/gcc-avr/commit/a83ac3ebaed7737cbdca19b513a55911a1ff8c35
Он не валится на тривиальных примерах и вроде делает то что нужно. Продолжаем?
Он не валится на тривиальных примерах и вроде делает то что нужно. Продолжаем?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Сделаем GCC C++ для AVR и Arduino лучше?