Массив байт - для арифметики как-то не очень.
Массив байт - для арифметики как-то не очень.
С любовью к вам, Yandex.Direct
Размещение рекламы на форуме способствует его дальнейшему развитию
Современные каноны программирования на 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.
Вот тут пишут, что есть работоспособная реализация LLVM для Z80, поддерживается в том числе и 32bit int. Статья с примерами компиляции (используют clang):Сообщение от mastermind
С-систаксис: https://olduino.wordpress.com/2014/1...f-inspiration/
С++: https://olduino.wordpress.com/2015/0...llvm-compiler/
Это кто то из наших таки добил гадину? И вообще, пробовал ли кто-то с помощью этого варианта LLVM собрать что-то приличное?
Лучше сделать и жалеть, чем не сделать и жалеть.
Некоторые из моих поделок тут: https://github.com/serge-404
Я так и не доделал все до конца в связи с отсутствием времени и некоторыми проблемами в понимании как реализовать нужные мне вещи в 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
Судя по данной ветке тамошнего форума:
https://tiplanet.org/forum/viewtopic...18038&p=197788
используя реализацию от jacobly, на CLang получилось собирать достаточно сложные проекты. Я правда не понял там таргет Z80 или ez80?
Последний коммит 26 Oct 2017.
Хотелось бы мнения от интересующихся.
Лучше сделать и жалеть, чем не сделать и жалеть.
Некоторые из моих поделок тут: https://github.com/serge-404
Вот тут упоминаются два таргета, z80 и ez80.
https://github.com/jacobly0/llvm-z80...TargetInfo.cpp
На форуме третье сообщение снизу с полными инструкциями для сборки от печки. Проще попробовать?
Больше игр нет
Не взлетит. Только на одн... Держится. Без мотивации
Электроника КР-02, MSX YIS-503IIR, Орион-128, Ленинград-2, Pentagon-128k, MSX2 YIS-503IIIR, MSX-EXT, ...
Судя по нику топикстартера - по ссылке это как раз его наработки. Просто здесь движуха отсутствует напрочь.
Выглядит похоже. Хоть бы автор отписался что да как, съэкономил нам время на исследования методом проб и ошибок.
Лучше сделать и жалеть, чем не сделать и жалеть.
Некоторые из моих поделок тут: https://github.com/serge-404
Эту тему просматривают: 1 (пользователей: 0 , гостей: 1)
Ваши права
Ответить с цитированием
