LLVM Backend для Z80

[EARL]

Подозреваю, что clang и llvm находятся в разных папках. Если это так, то советую сделать следующим образом.
1. Качаем llvm и кладем например в папку llvm-z80
2. Качаем clang и кладем в папку llvm-z80/tools/clang
3. Натравливаем cmake на llvm-z80
4. Запускаем сборку командой make и ждем.

Кстати собирать лучше не в папке где находятся исходники llvm/clang, а в отдельной.

[SfS]

Подозреваю, что clang и llvm находятся в разных папках. Если это так, то советую сделать следующим образом.
2. Качаем clang и кладем в папку llvm-z80/tools/clang

О!! ПЛЯ! я и не знал! ЩАЗ проверю

Кстати собирать лучше не в папке где находятся исходники llvm/clang, а в отдельной.

Это основная идея cmake. Каждый день на работе им пользуюсь.

---------- Post added at 21:36 ---------- Previous post was at 21:13 ----------

УРЯЯЯ! Собрался. Сейчас пытать его буду)

---------- Post added at 22:15 ---------- Previous post was at 21:36 ----------

В общем - даже C++ компилирует)
Но оптимизации пока что никакой.

[EARL]

Помимо оптимизации там пока еще имеются некоторые непонятности, как те или иные вещи реализовать. Например для временного хранения компилятор умеет перекладывать значения в регистр IY и загружать обратно посредством push/pop, но вот когда регистров становится недостаточно и возникает необходимость сохранять значения на стеке, то возникают оказии в виде попытки сгенерировать команду:

LD (IX+NN),HY/LY

Запретить сохранять на стек только регистр IY нельзя, т.к. аллокация регистров идет после генерации кода. Во всяком случае как это сделать я пока не понял, но уверен, что это реально. Можно просто запретить использовать IY для временного хранения значений, но тогда компилятор начнет чаще в стек лазить за значениями. В общем, ситуация не очень приятная. Это то, на чем сейчас все остановилось. В остальном количество команд, которые компилятор умеет генерировать уже почти хватает для всех видов конструкций, но код как ты заметил не самый оптимальный.

[SfS]

Это то, на чем сейчас все остановилось. В остальном количество команд, которые компилятор умеет генерировать уже почти хватает для всех видов конструкций, но код как ты заметил не самый оптимальный.

Да бог с ним, что "неоптимальный". Дело наживное. Главное, что это вообще сделано!

А z80-ассемблер ты не пытался прикрутить ещё?

[EARL]

Еще не делал. Однако это позволит делать inline подстановки на асме прямо в код Си. Можно даже дизассемблер туда пристроить

[EARL]

Ebuild случаем никто не готовил из llvm-z80 для Gentoo ?

Нет. Я думал сперва довести все же дело до более менее рабочего результата. Тогда и запилю.

[SfS]

Еще не делал. Однако это позволит делать inline подстановки на асме прямо в код Си. Можно даже дизассемблер туда пристроить

насколько я знаю есть binutils с поддержкой z80
сейчас буду искать

---------- Post added at 20:56 ---------- Previous post was at 19:55 ----------

В общем так.

1. Собрал binutils-2.22.tar.bz2
./configure --prefix=$PREFIX --target=z80-unknown-coff --disable-static --with-gnu-ld --with-gnu-as --enable-install-libbfd --disable-werror

(Опции нагло взяты из дебианоского скрипта)

2. Попытался откомпилировать программу на ассемблере, полученную clang'ом.

НИ ФИГА НЕ ВЫШЛО!

Причина: Неверно работает кодогенератор:

Исходный код.

int a;

int b;

int c;

int main(int argc, char* argv[]){
        c = a+b;
        return(0);
}

Полученный ассемблер (оптимизация -Os)

.file   "test.c"
        .text
        .globl  main
        .type   main,@function
main:
        push    ix
        push    de
        push    bc
        ld      ix, 0
        add     ix, sp
        ld      sp, ix
        ld      hl, b
        inc     hl
        ld      b, (hl)
        ld      a, (b)
        ld      c, a
        ld      hl, a
        inc     hl
        ld      d, (hl)
        ld      a, (a)
        ld      e, a
        ld      h, b
        ld      l, c
        add     hl, de
        ld      b, h
        ld      c, l
        ld      hl, c
        inc     hl
        ld      (hl), b
        ld      a, c
        ld      (c), a
        ld      hl, 0
        pop     bc
        pop     de
        pop     ix
        ret
.tmp0:
        .size   main, .tmp0-main

        .type   a,@object
        .comm   a,2,1
        .type   b,@object
        .comm   b,2,1
        .type   c,@object
        .comm   c,2,1

Обрати внимание на команды:

        ld      hl, b
...
        ld      hl, a
...
        ld      a, (a)

Без оптимизации картина та же.

Надо бы привести генерируемые команды к стандарту, пониемому бинутилсами.
тогда будем тестить дальше, уже на реале.

[Eltaron]

насколько я знаю есть binutils с поддержкой z80
сейчас буду искать

Их z80-coff очень ограниченная штука, кстати, в таблице релоцирования COFF нет некоторых ключевых фич. Я как-то пытался его прикрутить к sdcc, и споткнулся на том, что вот такое (взятие старшего и младшего байта адреса, который неизвестен на этапе компиляции)

      section .data
DATA
      defm "Hello, world"
      
      section .text
      LD H, DATA >> 8
      LD L, DATA & 0xFF

там в принципе невозможно. sdcc же такое генерит направо и налево, да и практически все прочие z80-ассемблеры понимают подобные по смыслу конструкции. Нужен ELF с его complex relocations.

[EARL]

Обрати внимание на команды:

        ld      hl, b
...
        ld      hl, a
...
        ld      a, (a)

Без оптимизации картина та же.

Надо бы привести генерируемые команды к стандарту, пониемому бинутилсами.
тогда будем тестить дальше, уже на реале.

Это все потому, что приводить к какому-то виду нужно как минимум рабочий вариант, а сейчас некоторые конструкции мой бэкенд еще не умеет строить. По этой причине генерацию листинга делал просто для более наглядной проверки получаемого результата и отладки.

В llvm есть свои инструменты подобные binutils. Думал в перспективе их использовать.

Альтернативы ему нет ?

Есть. Использовать DragonEgg+gcc для генерация llvm кода. Сам еще не пробовал. Очень интересно что получится

[SfS]

Их z80-coff очень ограниченная штука, кстати, в таблице релоцирования COFF нет некоторых ключевых фич. Я как-то пытался его прикрутить к sdcc, и споткнулся на том, что вот такое (взятие старшего и младшего байта адреса, который неизвестен на этапе компиляции)

      section .data
DATA
      defm "Hello, world"
      
      section .text
      LD H, DATA >> 8
      LD L, DATA & 0xFF

там в принципе невозможно. sdcc же такое генерит направо и налево, да и практически все прочие z80-ассемблеры понимают подобные по смыслу конструкции. Нужен ELF с его complex relocations.

будем дальше копать. В принципе асм можно любой прикрутить.

---------- Post added at 22:27 ---------- Previous post was at 22:24 ----------

Есть. Использовать DragonEgg+gcc для генерация llvm кода. Сам еще не пробовал. Очень интересно что получится

Я, конечно, наглею, давая советы - но может лучше сначала кодогенератор допилишь до того, чтобы он неоптимальный, но рабочий код давал со стандартными опкодами, а потом уж яйца дракона кушать будешь?