С уважением,
Gris / Red Triangle.
_____________________________________
ZX-EVO/TS-Labs config/NGS/HDD/SD-card
Amiga A1200/Blizzard 1230@50/32/60GB
Amiga A1200/Apollo 1260@66/32/60GB
UnAmiga (C5) AGA GM7123 VideoDAC
Массив байт - для арифметики как-то не очень.
Современные каноны программирования на 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 требует старого традиционного типа. Чего и остальным советую.
Записываю сюда чтобы не забылось:
В последней версии Rust (1.11) добавлена поддержка 16-битных указателей: https://github.com/rust-lang/rust/bl...110-2016-08-18
(имеет отношение к теме; rust - "низкоуровневый" язык использующий LLVM для компиляции)rustc support 16-bit pointer sizes. No targets use this yet, but it works toward AVR support.
Не взлетит. Только на одн... Держится. Без мотивации
Электроника КР-02, MSX YIS-503IIR, Орион-128, Ленинград-2, Pentagon-128k, MSX2 YIS-503IIIR, MSX-EXT, ...
Вот тут пишут, что есть работоспособная реализация LLVM для Z80, поддерживается в том числе и 32bit int. Статья с примерами компиляции (используют clang):
С-систаксис: https://olduino.wordpress.com/2014/1...f-inspiration/
С++: https://olduino.wordpress.com/2015/0...llvm-compiler/
Это кто то из наших таки добил гадину? И вообще, пробовал ли кто-то с помощью этого варианта LLVM собрать что-то приличное?
Лучше сделать и жалеть, чем не сделать и жалеть.
Некоторые из моих поделок тут: https://github.com/serge-404
С любовью к вам, Yandex.Direct
Размещение рекламы на форуме способствует его дальнейшему развитию
Судя по нику топикстартера - по ссылке это как раз его наработки. Просто здесь движуха отсутствует напрочь.
Лучше сделать и жалеть, чем не сделать и жалеть.
Некоторые из моих поделок тут: https://github.com/serge-404
У EARL последний коммит в 2013 году, о чем вы говорите.
- - - Добавлено - - -
А так вообще вот чувак более живой, пилит что-то: https://github.com/jacobly0/llvm-z80
Свирепый агрессивно-депрессивный мордовец!
Не уверен - не напрягай!
Не сдавайся. Дыши?
Virtual TR-DOS
Я так и не доделал все до конца в связи с отсутствием времени и некоторыми проблемами в понимании как реализовать нужные мне вещи в LLVM. Примеры по ссылкам выдают как раз тот код, который и у меня был, т.е. вряд ли там кто-то что-то еще допиливал. Могу заверить, что некоторые конструкции просто не скомпилируются и поэтому проект неработоспособный.
Да, у этого человека в настоящий момент идет понемногу движуха, но я не пробовал тестировать его код.
Последний раз редактировалось EARL; 23.03.2017 в 19:04.
ZX Evolution 4096 Rev.C + NeoGS 4096 Rev.C + PAL Coder Rev.C + FDD 3.5/HDD/CDROM
Reverse U8
Эту тему просматривают: 1 (пользователей: 0 , гостей: 1)