а почему не gcc? llvmу ведь поффиг какой фронт-енд использовать?)Сообщение от EARL
хотя, я думаю, что c-lang непринципиально отличается в плане применения на ZX
а почему не gcc? llvmу ведь поффиг какой фронт-енд использовать?)
хотя, я думаю, что c-lang непринципиально отличается в плане применения на ZX
Не хочу отвадить от работы, тьфу-тьфу... =)
Но! llvm есть только для 32+ битных процов, на них он и ориентирован, с 8ми битным могут быть проблемы.
Для gcc есть порт на 6809, до z80 его допилить может быть легче.
Желательно ознакомиться с sdcc и его abi, чтобы не бегать по тем же граблям. Там же можно подглядеть и peephole оптимизации.
Вот потенциальный соучастнег: http://lists.cs.uiuc.edu/pipermail/l...il/049228.html
(исходник там в аттаче)
Точно не скажу, т.к. не пробовал прикручивать gcc к llvm, но вроде сами разработчики решили отказаться от поддержки gcc и направить все силы на поддержку clang. Хотя возможность прикрутить и использовать gcc все же осталась как я понял))
Ну точно можно сказать что поддержка 16 битных процов уже реализовали в llvm. Взять тот же MSP430 backend. Да и так я не нашел никаких проблем прикрутить кодогенерацию для любого процессора, т.к. например сейчас у меня код llvm ассемблера преобразуется в ассемблерный файл для z80.
Хм.. не слышал про данный порт для gcc. Надо будет поискать. А вот на счет ABI уже задумывался. Я так понимаю ABI как такового нет и все компиляторы сейчас делают каждый по своему. Стоит ли делать совместимость ABI с другими компиляторами или нет вопрос спорный. Например в llvm можно легко реализовать передачу части параметров функции в регистрах очень легко, а не тупо все пихать в стек. Данной возможности пока не видел ни в каком компиляторе. Думаю это может дать не малый прирост к скорости.
Но совместимость ABI можно также сделать позже.
---------- Post added at 22:15 ---------- Previous post was at 22:10 ----------
Хм.. Как-то беглым взглядом смутили строки вида:
Но всё равно спасибо. Посмотрю его исходники и попробую связаться.Код:ld (SP+6), BC
Глупости, бэкенд может вообще не иметь ничего общего с существующими процессорами (подробнее см. http://llvm.org/docs/CodeGenerator.h...code-generator ).
В старых версиях кстати был бэкенд для PIC16 (8 бит), но позже был выкинут, если не ошибаюсь из за того что автор его забросил и перестал апдейтить для новых версий llvm. (см. http://llvm.org/viewvc/llvm-project/...pathrev=116189 )
Не говоря уже о том что есть бэкенды для генерации C-кода (кажется тоже заброшенный), и Javascript-кода (очень даже работающий и поддерживаемый: https://github.com/kripken/emscripten/wiki - демки, кстати, там советую посмотреть)
Последний раз редактировалось mastermind; 01.10.2012 в 22:37.
Я не про совместимость, на которую сейчас плевать, а про посмотреть, как работа с тем же стеком сделана.
С любовью к вам, Yandex.Direct
Размещение рекламы на форуме способствует его дальнейшему развитию
По-моему неважно как она сейчас сделана. Надо сначала сделать полноценный кодогенератор, а потом уж заниматься оптимизациями. Иначе легко погрязнуть в мелочах, не дойдя до конца.
Когда уже есть что-то работающее - тогда видны его недостатки и их можно исправлять. А теоретезировать на тему - "давайте так", "давайте этак" - можно месяцами. Концептологи этим и занимаются. Только выхлоп у них близкий к нулю
Аффтор! Не бросай lllvm. Дай нам кафйфный C для zx) Кстати, как появится что-то рабочее, если не жалко - делай проект с исходниками в открытом доступе. Поругают, конечно, знатно, зато и больше советов дадут дельных по нутру)
Да исходники и сейчас уже доступны. Ссылку вышел давал, вот еще раз если интересно - http://sourceforge.net/projects/llvm...urce=directory
На данный момент там правда только добавляются новые команды и что-то рабочее получить врят ли получится
Скачал) буду посмотреть. надо llvm изучить немного.
как собрать? какие ключи в ./configure ?
Эту тему просматривают: 1 (пользователей: 0 , гостей: 1)
Ваши права
Ответить с цитированием
