LLVM Backend для Z80

[SfS]

Куды все пропали?

[Advertiser]

[SfS]

Автор? Ты жив?

[EARL]

Автор жив, проект спит. Надеюсь это временно, т.к. самому он интересен. В данный момент работаю над другими проектами, т.к. с llvm:
1. Не нашел больше людей, кто мог бы помочь с разработкой, а для одного все таки долго/сложно его развивать.
2. LLVM активно развивается и нужно успевать следить за всеми новыми возможностями, на что не хватает времени.

[mastermind]

Зашел глянуть на github происходит ли что-нибудь с проектом.
Месяц назад некто Seth Traverse (https://github.com/WinMac32) склонировал проект EARL'а и добавил пару коммитов.
См. https://github.com/WinMac32/llvm-z80/commits/z80

Initial implementation of inline asm …
WinMac32 authored on Nov 2

Based heavily (almost completely) off of the "CPU0" implementation
with modifications to make it output correct z80 operands

Next step is testing to see what CPU0-specific features need to be
changed, or removed, so that it works in all use cases.

We now output "correct" z80 syntax. …
WinMac32 authored on Nov 6

Also temp fix on some C programs not compiling...

It seems LLVM sometimes wants to put HL onto the stack, but it first
moves it to IY (seriously wtf) and then tries to move IY to memory
indirectly using the IX register. Originally (and correctly, I
suppose), it would crash here.
However, I'm temporarily allowing it for testing. This isn't an
instruction, and it should't even be using IY for stuff like that
in the first place. LLVM needs to be stopped from getting to this
point.

(склонировал он, правда, как-то некорректно, github не показывает связь с проектом EARL'a)

---------- Post added at 12:52 ---------- Previous post was at 12:49 ----------

Упомянутый у него CPU0 - некий китайский процессор (выдуманный что ли для этой книги подобно MIX Asm Дональда Кнута?), процесс создания LLVM-бэкенда для которого подробнейшим образом описан здесь: http://jonathan2251.github.io/lbd/ (онлайн + epub и pdf книжки) - выглядит как отличное руководство по созданию бэкендов. (пусть и на ужасно ломаном англ. языке)

[EARL]

Да, я уже видел этот репозиторий на github'е и книжку про CPU0. Есть там некоторые интересные моменты.
Помимо всего, я недавно отписывался на одном из иностранных форумах, где тоже интересовались моим проектом (http://www.cemetech.net/forum/viewto...=226619#226619). Сейчас у меня снова появился интерес к проекту, но завал на работе не позволяет заняться им.

[mastermind]

(перевод гуглом с французского, немного подправленный):

jacobly, крупный контрибьютор в CEmu, начал переделывать бэкэнд Z80 + eZ80 для LLVM, с нуля. Сейчас этот бэкенд начинает генерировать код для простых случаев, он опубликовал свою работу, чтобы другие могли внести свой ​​вклад и улучшить, в духе обмена нашего сообщества, на данный момент есть еще много работы, но это важный шаг, и это наша коллективная ответственность содействовать тем, кто имеет навыки и время, а также воспользоваться, когда он будет работать хорошо.

Репозиторий проекта: https://github.com/jacobly0/llvm-z80
Источник информации: IRC (на EFNet, канал # eZ80-DEV)

Отсюда (фрагмент сообщения от 3 марта 2016 г.): https://tiplanet.org/forum/viewtopic...18038&p=197788

[EARL]

Хорошая новость. Буду следить за этим проектом. Жаль сейчас времени свободного почти нет, но если появится, попробую помочь ему.

[andreyu]

Т.к. Z80 8-битный процессор, то int должен иметь размер 1 байт или я не прав?

Стандарт языка Си гарантирует, что char <= short <= int <= long.
В вашем случае char = 1 байт, short = int = 2 байта, long на ваше усмотрение - 2-4 байта.

[SfS]

склоняюсь к long=4 байта, а long long = 8 байт. Чтобы не выкоблучиваться, если надо больше 16 бит.
На спеке это редко надо, но надо.

[andreyu]

склоняюсь к long=4 байта, а long long = 8 байт. Чтобы не выкоблучиваться, если надо больше 16 бит.

Тогда для этого хватит двух байт

На спеке это редко надо, но надо.

Тот, кому такое нужно, сможет сделать это на массиве байт. Когда мне нужно хранить набор бит/состояний, то я использую массив uint32_t (и это работает на любых современных архитектурах), но с тем же успехом (и без потери производительности) можно использовать и массив uint8_t.