Куды все пропали?
Вид для печати
Куды все пропали?
Автор? Ты жив?
Автор жив, проект спит. Надеюсь это временно, т.к. самому он интересен. В данный момент работаю над другими проектами, т.к. с llvm:
1. Не нашел больше людей, кто мог бы помочь с разработкой, а для одного все таки долго/сложно его развивать.
2. LLVM активно развивается и нужно успевать следить за всеми новыми возможностями, на что не хватает времени.
Зашел глянуть на 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.
(склонировал он, правда, как-то некорректно, github не показывает связь с проектом EARL'a)Цитата:
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.
---------- Post added at 12:52 ---------- Previous post was at 12:49 ----------
Упомянутый у него CPU0 - некий китайский процессор (выдуманный что ли для этой книги подобно MIX Asm Дональда Кнута?), процесс создания LLVM-бэкенда для которого подробнейшим образом описан здесь: http://jonathan2251.github.io/lbd/ (онлайн + epub и pdf книжки) - выглядит как отличное руководство по созданию бэкендов. (пусть и на ужасно ломаном англ. языке)
Да, я уже видел этот репозиторий на github'е и книжку про CPU0. Есть там некоторые интересные моменты.
Помимо всего, я недавно отписывался на одном из иностранных форумах, где тоже интересовались моим проектом (http://www.cemetech.net/forum/viewto...=226619#226619). Сейчас у меня снова появился интерес к проекту, но завал на работе не позволяет заняться им.:(
(перевод гуглом с французского, немного подправленный):
Отсюда (фрагмент сообщения от 3 марта 2016 г.): https://tiplanet.org/forum/viewtopic...18038&p=197788Цитата:
jacobly, крупный контрибьютор в CEmu, начал переделывать бэкэнд Z80 + eZ80 для LLVM, с нуля. Сейчас этот бэкенд начинает генерировать код для простых случаев, он опубликовал свою работу, чтобы другие могли внести свой вклад и улучшить, в духе обмена нашего сообщества, на данный момент есть еще много работы, но это важный шаг, и это наша коллективная ответственность содействовать тем, кто имеет навыки и время, а также воспользоваться, когда он будет работать хорошо.
Репозиторий проекта: https://github.com/jacobly0/llvm-z80
Источник информации: IRC (на EFNet, канал # eZ80-DEV)
Хорошая новость. Буду следить за этим проектом. Жаль сейчас времени свободного почти нет, но если появится, попробую помочь ему.
Стандарт языка Си гарантирует, что char <= short <= int <= long.Цитата:
Сообщение от EARL
В вашем случае char = 1 байт, short = int = 2 байта, long на ваше усмотрение - 2-4 байта.
склоняюсь к long=4 байта, а long long = 8 байт. Чтобы не выкоблучиваться, если надо больше 16 бит.
На спеке это редко надо, но надо.
Тогда для этого хватит двух байт :)Цитата:
Сообщение от SfS
Тот, кому такое нужно, сможет сделать это на массиве байт. Когда мне нужно хранить набор бит/состояний, то я использую массив uint32_t (и это работает на любых современных архитектурах), но с тем же успехом (и без потери производительности) можно использовать и массив uint8_t.Цитата:
Сообщение от SfS