LLVM Backend для Z80

[Sergey]

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

Я, конечно, не программер. Но, по-моему, из приведённого выражения следует только то, что int не может быть больше long, а short - не больше int. Т.е. int может быть 4 байта, а long 2 байта - НЕТ.

[SfS]

Массив байт - для арифметики как-то не очень.

[Barmaley_m]

Современные каноны программирования на C, особенно для встраиваемых систем, отказываются от традиционных типов int, short и long, и рекомендуют использовать только заданные точно типы: int8_t, int16_t, int32_t, int64_t и их беззнаковые аналоги. Так что нет смысла здесь копья ломать. Пишите так, чтобы программа не зависела от ширины int, short и long на конкретной платформе.

Собственно, откуда взялась эта идущая родом из истоков языка C неточная спецификация на ширину целых чисел? В те времена считалось, что пусть программист укажет, что желает работать с таким целым типом, который наиболее удобно представим на целевой платформе. Компилятор же решит, какая у этого типа будет ширина. Но на практике оказалось, что программисты пишут программы исходя не из наихудшего случая (т.е., к примеру, не допускать, чтобы переменные int выходили за диапазон -32768...32767, так как на некоторых компьютерах int могут иметь ширину 16 бит), а из той ширины типов, которая принята на платформе, под которой работает программист. И в конце концов вместо улучшения портируемости программ произошло ее ухудшение.

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

Ситуация усугублялась несовместимостью библиотек и причудами компиляторов. В начале 2000х я пытался писать программы на C и C++ исходя из "наихудшего случая - 16 бит на int". Там, где были нужны 32-битовые переменные - использовал long. Но однажды мне пришлось компилировать свои программы на другой платформе, а там был принят стандарт: long = 64 бита. В результате съехали все размеры структур, и программа не смогла работать с двоичными файлами, с которыми она должна была работать. Так что даже программирование под "наихудший случай" не позволяет избегать проблем с портируемостью кода на С; более того, в данном конкретном случае мои усилия оказались даже вредными. Использовал бы int - все работало бы нормально.

Так что теперь я перешел на типы фиксированной длины, разве что, кроме случаев, когда какая-нибудь библиотека или API требует старого традиционного типа. Чего и остальным советую.

[mastermind]

Записываю сюда чтобы не забылось:
В последней версии Rust (1.11) добавлена поддержка 16-битных указателей: https://github.com/rust-lang/rust/bl...110-2016-08-18

rustc support 16-bit pointer sizes. No targets use this yet, but it works toward AVR support.

(имеет отношение к теме; rust - "низкоуровневый" язык использующий LLVM для компиляции)

[OrionExt]

Не взлетит. Только на одн... Держится. Без мотивации

[Error404]

Записываю сюда чтобы не забылось:
В последней версии Rust (1.11) добавлена поддержка 16-битных указателей: https://github.com/rust-lang/rust/bl...110-2016-08-18

(имеет отношение к теме; rust - "низкоуровневый" язык использующий LLVM для компиляции)

Вот тут пишут, что есть работоспособная реализация LLVM для Z80, поддерживается в том числе и 32bit int. Статья с примерами компиляции (используют clang):
С-систаксис: https://olduino.wordpress.com/2014/1...f-inspiration/
С++: https://olduino.wordpress.com/2015/0...llvm-compiler/

Это кто то из наших таки добил гадину? И вообще, пробовал ли кто-то с помощью этого варианта LLVM собрать что-то приличное?

[Advertiser]

[shurik-ua]

Судя по нику топикстартера - по ссылке это как раз его наработки. Просто здесь движуха отсутствует напрочь.

[Error404]

Судя по нику топикстартера - по ссылке это как раз его наработки. Просто здесь движуха отсутствует напрочь.

Выглядит похоже. Хоть бы автор отписался что да как, съэкономил нам время на исследования методом проб и ошибок.

[Shadow Maker]

У EARL последний коммит в 2013 году, о чем вы говорите.

- - - Добавлено - - -

А так вообще вот чувак более живой, пилит что-то: https://github.com/jacobly0/llvm-z80

[EARL]

Вот тут пишут, что есть работоспособная реализация LLVM для Z80, поддерживается в том числе и 32bit int. Статья с примерами компиляции (используют clang):
С-систаксис: https://olduino.wordpress.com/2014/1...f-inspiration/
С++: https://olduino.wordpress.com/2015/0...llvm-compiler/

Это кто то из наших таки добил гадину? И вообще, пробовал ли кто-то с помощью этого варианта LLVM собрать что-то приличное?

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

А так вообще вот чувак более живой, пилит что-то: https://github.com/jacobly0/llvm-z80

Да, у этого человека в настоящий момент идет понемногу движуха, но я не пробовал тестировать его код.