Зачем в 1000й раз выдумывать самокат, пользуйте стандарт - в stdint.h есть определения int8_t, uint8_t, int16_t, uint16_t, int32_t, uint32_t - и не будут возникать проблемы при переносе на разные архитектуры когда "писатель" в одном случае использует int как 32-битный, потом оказывается на другом контроллере/компиляторе что это 16-бит, возникают непонятные ошибки в вычислениях, переполнения, и тратится куча времени на поиск ошибок, переопределение типов и т.д...
Непонятно только почему многие не понимают что char,int,long давно пора перестать использовать ?

Сообщение отредактировал umup - Feb 4 2007, 12:22

И там-же еще int_least8_t .... uint_least32_t, int_fast8_t ..... uint_32fast_t
Как-бы проблем с 1999 года вообще нет - ну просто на все случаи жизни
Только глазами о такую хрень спотыкаешься и набирать с души воротит.

А потому, что на самом деле и с ними de-facto проблем НЕТ, кроме обсасываемой здесь одной единственной - int на 8bit платформе. Ну и еще того, что char может быть по умолчанию, как знаковым, так и нет (но это слава богу обычно компиляторам можно в командной строке указать)

Посему все эти intXX_t полностью соответствуют в привычным, коротким и читаемым
char ( uchar, BYTE ) short( ushort, WORD ) long ( ulong, DWORD )
Ну а int ( uint ) в большинстве случаев прекрасно справляется с обязанностями всяких int_least8_t .... int_least32_t, int_fast8_t ..... int_fast32_t.
Главное действительно перестать использовать его где попало и как попало .

и что, все эти uchar, BYTE, WORD, DWORD, u8, i16, UI32 определены для каждого компилятора во всех библиотеках ? На практике чаще всего встречается что каждый в своих библиотеках определяет типы как попало, это мешает чтению больше чем int8_t, uint8_t. И написать uint8_t быстрее чем unsigned char.

"все эти" лично у меня идут в отдельном header и максимум, что ВДРУГ может потребоваться посмотреть header и если ВДРУГ для какого-то экзотичного компилятора потребуется - подправить.
А вот правильный header c вышеупомянутыми типами может и не быть в составе "каждого компилятора"
.

Дело исключительно привычки. К счастью язык достаточно живой и позволяет несколько облегчить жизнь не только абстрактному программисту, но и себе любимому
Посему у меня там разных своих типов вместо безликих 8-16-32 битных много определено и унионов, и структур - для удобства чтения и недопущения ошибок. Так-что несколько uxxx со товарищами погоду не делают. Надеюсь Вы не будете возражать против своих типов и не будете требовать сводить все
к безликим 8-15-32-64 с целью "не мешать чтению".

То, где однозначно напрашиваюется использование типов из C99, это конечно публикация кусков текстов относящихся к более-менее абстрактным областям программирования - иначе говоря "книжки", исходники уровня clib, ......

Ну вот и я решил влиться в ряды армоводов. Купил плату от olimex'a, скачал с сайта пример - моргание светодиодов на плате. Решил залить по usb. Я так понимаю через samba можно загружать только файлы с расширением .bin ??? Вопрос, как получить в IARe bin ?

Сообщение отредактировал fredo - Oct 24 2007, 19:00

Options-Linker-Output Format-other-raw-binary

zltigo, Вы однако, уже определитесь...

ставил так, не помогло, с светодиодами ничего не происходило. Хотя готовый бинарник с сайта работает

А Flash Release выбрана конфигурация ? Подазабыл, может в Атмеле еще какие-то телодвижения нужны, все более по LPC копаюсь

Там еще выше было:


Где протворечие, хоть какое-то, Вам увидеть удалось?
int эффективный тип хорошо работающий не на 8-bit платформах, на коих приходится для эффективности явно указывать везде, где можно явно 8-bit типы. Использование явных 8-bit типов на ARM платформах крайне не желательно. Для x86 - безразлично, если конечно они не в пакованных невыровненных структурах. Если ориентироваться на портирование на 8-bit, то тогда правильным является ... least8_t
Вторая приведенная Вами цитата из темы портирования AVR исходника.
Вопросы?

На 8 бит платформах (например AVR которым Вы не пользуетесь из-за большой нелюбви к
Atmel) int 16 бит.
На MSP430(которым вы пользуетесь, судя по Вашим постам) int тоже 16 бит

Дык как обстоит дело с портированием на 16бит платформы ?
и в частности на MSP430 ? нужно использовать least8_t, или все-таки как-то по другому ?

Не надо передергивать - я не пользуюсь AVR, поскольку для контроллеров ценовой категории от нескольких баксов применение AVR может быть обусловленно только каким-то специфическим свойством, типа высокой нагрузочной способностью по выходам. По той-же самой причине я уже не пользуюсь 51 контроллерами в том числе и "любимого" NXP. Совершенно ничего личного
По причине почти полного отказа от 8-bit польза от ...least8_t для меня сильно снижена.

По причине очень больших наработок и привычек именно к 16-bit я в своих исходниках рассчитываю на int размерностью не более 16-bit. Для 32-bit (как и 64-bit) всегда использую явные указания. В таком применении проблемы портирования 16<->32 нет. На 8-bit c 16/32 бит лично я портирую мало, исходники ввиду использования мелких восьмибитовиков невелики и тогда уже их по необходимости правлю под универсальные типы.

для примера mega8 от 5 баксов
Ну и кто из нас передергивает ?
Тока не нужно расказывать про контроллер светодиодов, ладно ?
Эээ... ну тогда поясните мне какие проблемы могут возникнуть при портировании с/на
8 бит архитектуру если int у Вас всегда не больше 16 бит ?

Чего-то Вам глаза застилает . Повторяю медленно и печально - в ценовой категории контроллеров стоимостью порядка 5 баксов и выше применение AVR8 становится нецелесообразным.

Не буду - я их не делаю, но совершенно уверен, что их пока еще дешевле делать на даже не самом дешевом 8-bit, нежели на самом дешевом ARM. Какие проблемы?

В собственно тупом портировании - никаких, а вот с эффективностью проблемы. На восьмибитовике какой-нибудь банальный счетчик цикла без всякой на то надобности будет прокручиваться в двух регистрах или в двух ячейках памяти, или занимать регистровую пару.... Попробуйте в обсуждаемом ранее AES алгоритме поменять byte на int - вопросы отпадут. Попробуйте откомпилировать с замененными на int под ARM - положительный эффект подскажет ответ на обратный вопрос.
При портировании int на 32-bit - ну ровным счетом никаких проблем, о чем и писал уже несколько раз.

очень жаль, что Alex_inventor так прореагировал, мне его пример понравился и я с радостью бы посмотрел подобные, максимально упрощенные, полностью самописные и комментированные.

теперь о примерах к книжке:
купил, попытался запустить, напоролся на теже грабли, понял что книжка lpc2000 является простым переводом книжки insiders guide и примеры в них одинаковые, скачал примеры к оригиналу и они-то как раз скомпилились нормально ( http://rapidshare.de/files/39331428/lpc210...amples.zip.html ).