не имеет char никакого отношения к памяти и байтам. Это тип данных в C. Размер его в битах/байтах НЕ ОПРЕДЕЛЁН. Он сам по себе единица измерения. Известно, что sizef(char) == 1, и что например sizeof(int) ≥ 1.

А вот это 4.2, в стандарте четко сказано, что char это тип размера минимально адресуемого машиной способного вместить в себя базовый набор символов. По сути одно из определений байта такое же.

Кстати, и sizeof(int) == 1.

typedef short int int16_t;

Как минимум из-за sizeof(int16_t) == 2.

откуда у тебя short больше int???

я надеялся отлаживать порт удобненько под gcc/линуксом

У tms нет эмулятора под Linux?

А вот это 4.2, в стандарте четко сказано

там сказано «исторически» и «во многих архитектурах».

Ну а если ты решил заняться демагогией, определи понятие «минимально адресуемая память»? Для x86 например.

откуда у тебя short больше int???

Смотри контекст: первое - на девайсе, второе - попытка эмуляции под привычным линуксом.

может ты просто не будешь юзать sizeof()? С ним по любому будут проблемы, ибо например sizeof(int) даже на x86 постоянно меняется.

У tms нет эмулятора под Linux?

После перехода TI Code Composer Studio на базу eclipse оно должно работать и под линуксом, но оно по-прежнему не свободно.

После перехода TI Code Composer Studio на базу eclipse оно должно работать и под линуксом

Вполне работает, кстати.

оно по-прежнему не свободно.

Отладка без эмулятора? Лучше и не думай об этом.

оно по-прежнему не свободно.

Отладка без эмулятора? Лучше и не думай об этом.

Хотел разбить отладку на два этапа: быстро и комфортно под нативным gcc/линуксом, а потом уже, когда всё вроде работает, немного помучиться со старой CCS 3.x, потому что новой нет в распоряжении.

может ты просто не будешь юзать sizeof()?

Но их уже юзают. Разве что продублировать их все фэйковыми для sizeof().

Но их уже юзают.

говнокод. Их можно юзать именно для случая например размера массива, или для непереносимых кусков(например для связи с асмом, когда ты точно знаешь, что это за архитектура).

Разве что продублировать их все фэйковыми для sizeof().

страдайте…

быстро и комфортно под нативным gcc/линуксом, а потом уже, когда всё вроде работает, немного помучиться со старой CCS 3.x

Не выйдет. Нужны регулярные проверки на эмуляторе.

Если ты намекаешь, что реально читается не байты, то я знаю это да. Но опять же память адресуется байтами. Адрес памяти в Си, ассемблере - это адрес байта.

Но опять же память адресуется байтами. Адрес памяти в Си, ассемблере - это адрес байта.

формально — да. Реально он всегда делится на 16 как минимум. (конечно не на всякой архитектуре на это можно рассчитывать). Можешь сам навыделять байтов, и посмотреть их адрес, если не веришь. Кстати, последние биты указателей можно в своих целях использовать, ибо для адресации они давно не нужны. Иногда так и делают (НЕПЕРЕНОСИМО, и вообще грязный хак!).

Ну это мы уже слишком углубляемся в частные реализации.

Что-то эти "сентенции" вызывают сомнения.

формально — да. Реально он всегда делится на 16 как минимум.

Кстати, последние биты указателей можно в своих целях использовать, ибо для адресации они давно не нужны.

Как адрессуеться конкретный байт в этом случае? И о каких архитектурах речь, в конце концов.

Что-то эти «сентенции» вызывают сомнения.

RTFM

FM на что?

ты же сомневался?

sizeof(int_8t)=2

Я подобный бред первый (и, надеюсь, последний) раз вижу! Кстати, не int_8t, а int8_t.

Достопочтеннейший сударь не в курсе, что тип int8_t специально создан для того, чтобы гарантировать, что он имеет ровно 8 бит?

Fu**ing Manual чего именно почитать? Какой платформы, в каком режиме работы, и в каком режиме адресации?

P.S. Возможно я и действительно немного отстал от жизни.

Fu**ing Manual чего именно почитать? Какой платформы, в каком режиме работы, и в каком режиме адресации?

Macintosh на m68000 (именно m68000, не более поздних). Это единственная известная мне платформа, в которой можно было использовать часть битов адреса для своих нужд (правда, старшие).

Раз уж автор «тезисов» «про деление на 16 как минимум» и «лишние биты в указателе» не хочет делиться списком литературы подтверждающей,

пойду почитаю про динозавров, 68000. :)

Fu**ing Manual чего именно почитать? Какой платформы, в каком режиме работы, и в каком режиме адресации?

т.е. ты признаёшься в том, что тебя в гугле забанили, и что найти самостоятельно по интересующей тебя теме ты не можешь?

ну да ладно, я сегодня добрый(точнее мой гугл), вот тебе даже по-русски нагуглилось: http://habrahabr.ru/post/149012/

От себя добавлю, что оно может для хабры и гейос новость, но на самом деле, это очень древняя идиома, известная ещё с i8086.

Это единственная известная мне платформа, в которой можно было использовать часть битов адреса для своих нужд (правда, старшие).

я разве где-то говорил, что биты можно использовать без их фильтрации?

тип int8_t специально создан для того, чтобы гарантировать, что он имеет ровно 8 бит?

херню несешь. «не менее 8 бит» - так правильно. на указанной архитектуре он, скорей всего, тоже 16-битный, по крайней мере, на tms с2000 так.

но, кстати, переносимости это таки помогает. в коде, обрабатывающем, скажем, приходящие октеты, можно объявить их uint8_t и не париться. ну, будут они занимать не 8 бит, а 16 каждый - какая разница. просто надо об этом не забывать и кодить аккуратно.

херню несешь

Это ты херню несешь: sizeof(char) может быть и 2, но sizeof(int8_t) гарантированно == 1!

Для того stdint со всеми этими макросами и сделан!

т.е. ты признаёшься в том, что тебя в гугле забанили, и что найти самостоятельно по интересующей тебя теме ты не можешь?

На вопрос «Какой платформы, в каком режиме работы, и в каком режиме адресации?» ответить не смог - незачет!

ну да ладно, я сегодня добрый(точнее мой гугл), вот тебе даже по-русски нагуглилось: http://habrahabr.ru/post/149012/

Приведенный перевод статьи плох. Переводчик, видимо, даже и не понимал толком зачем нужен align, что такое ras и cas. Далее в статье таки отмечено, что это не касаеться указателей типа char*,о которых данный топик, а относиться к указателям на «объект». Затем, в статье же, ведеться речь _только_ о динамическом выделении памяти malloc-ом, что вообщем-то не эффективно для указателей, ибо есть регистры и стек. То, что каждый новый вызов malloc(1) не будет возвращать значение указателя больше на единицу, это уж совсем очевидно, там связанный список. Почитай комменты человека под ником ramntry: http://habrahabr.ru/post/149012/#comment_5034755

Может что-то для себя прояснишь. Еще попробуй gcc -S

От себя добавлю, что оно может для хабры и гейос новость, но на самом деле, это очень древняя идиома, известная ещё с i8086.

Если б я не написал over 9000 строк на ассемблере 8086 начиная с 91-го года, я б, пожалуй, просто не обратил бы даже внимания на твои «афоризмы» :-)

херню несешь. «не менее 8 бит» - так правильно. на указанной архитектуре он, скорей всего, тоже 16-битный, по крайней мере, на tms с2000 так.

он 8и битный если это в принципе возможно. А вот на tms с2000 AFAIK как раз нет таких октетов.

но, кстати, переносимости это таки помогает.

угу. Костыль, ибо иначе никак.

Это ты херню несешь: sizeof(char) может быть и 2, но sizeof(int8_t) гарантированно == 1!

Стандарт считает иначе.

На вопрос «Какой платформы, в каком режиме работы, и в каком режиме адресации?» ответить не смог - незачет!

ну радуйся. Засчитай себе ещё одну победу демагога.

Приведенный перевод статьи плох.

меня это мало волнует. В гугле полно других материалов на эту тему. Суть в том, что это распространённая идиома на практически всех современных архитектурах. Хотя и непереносимая. Зато часто позволяет сэкономить МНОГО памяти. Полезна как низкоуровневая оптимизация для хорошо построенного и уже работающего приложения. Я, кстати, сам не знал, что на гейос это тоже юзается. Как-то не вдавался.

Далее в статье таки отмечено, что это не касаеться указателей типа char*,о которых данный топик, а относиться к указателям на «объект».

правильно указал, ибо у него char 8и битный, и потому указатель на него может быть нечётным. Это всё поломает. Всё идёт из предположения, что указатель всегда чётный, потому младший бит не используется. Но место занимает.

Затем, в статье же, ведеться речь _только_ о динамическом выделении памяти malloc-ом, что вообщем-то не эффективно для указателей, ибо есть регистры и стек.

потому-что malloc у него гарантированно обнуляет 4 младших бита указателя. В отличие от стека, который теоретически может быть и нечётным, ну или во всяком случае не делится на 4 и более. По этой-же причине, такие указатели используются только для больших объектов. Я тебе больше скажу, malloc часто сама использует эти биты для внутренних нужд. Многие аллокаторы например именно там хранят признак того, что блок свободный/используемый. Также и другие биты тоже часто используются.

То, что каждый новый вызов malloc(1) не будет возвращать значение указателя больше на единицу, это уж совсем очевидно, там связанный список.

что, в гейос в 21ом веке до сих пор как в CP/M аллокатор? Клёво, стильно, молодёжно.

Почитай комменты человека под ником ramntry: http://habrahabr.ru/post/149012/#comment_5034755

что там не так? Я здесь, на ЛОРе, изначально говорил про выровненную память, и как следствие «выравненные указатели» (в терминах хабролюдей). И о том, что минимальная часть памяти, которую _действительно_ можно адресовать намного больше октета/байта.

Впрочем вот, тоже самое, что я тебе разъясняю, но иными словами:

«Свободные биты» в указателях используются не только для хранения RTTI. В некоторых простых аллокаторах (или менеджерах, если так удобнее) динамической памяти используется следующий подход: в любой момент времени система имеет указатель на начало динамической области памяти процесса. По этому адресу хранится модифицированный указатель на следующую границу между аллокациями, она, в свою очередь, на следующую и т.д. То есть, динамическая память оказывается прошитой в однонаправленный связный список, а информация о том, свободен элемент этого списка как аллокация или занят хранится в младшем бите указателей (в чем и состоит «модификация»). Реальные реализации malloc и new С/С++, аллокаторов Java/Objective-C значительно сложнее.

В некоторых реализациях сборщиков мусора также используется последний бит указателя. Пусть была аллоцирована память. Указатель на нее в младшем бите хранит ноль. Если владение указателем было потеряно (например, переменная вышла из блока (за scope) или в нее выполнено присваивание), а в младшем бите по-прежнему ноль, можно считать, что других ссылок на объект за время его жизни сделано не было и память освобождается сразу, без вызова основного сборщика мусора. Если же напротив, была создана ссылка (например, с помощью присваивания указателя другому или передачи указателя во внешний код или подпроцедуру), то младший бит указателей, как копии, так и источника, устанавливается в единицу и там «залипает». Теперь при уничтожении указателя память не освобождается и это может быть сделано теперь только основным сборщиком по другим алгоритмам. Если есть возможность выделить не только бит, но, скажем, 4 бита, как это обсуждалось в статье, то появляется возможность инкрементально управлять памятью, отведенной под все объекты, число ссылок на которые никогда не пересекало отметки в 15 штук, не отводя под счетчик ссылок в самих объектах памяти.

И да, читай внимательно: связанный список тут просто для примера.

Может что-то для себя прояснишь.

я же говорю: это ТЕБЕ что-то непонятно. Я про эту хрень много лет в курсе. Странно лишь только то, что ты сам нагуглить ничего не можешь. Разве это сложно?

Если б я не написал over 9000 строк на ассемблере 8086 начиная с 91-го года, я б, пожалуй, просто не обратил бы даже внимания на твои «афоризмы»

я рад за твои Over9000 строк. Только я не понимаю, разве стыдно чего-то не знать? Я вот сам многого не знаю, что в этом страшного?

И да, в начале 90х эта идиома была мало известна, как не странно. ИМХО причина в том, что в те годы было очень дорого по времени выполнять фильтрацию указателей. Потому обычно было выгоднее сделать таки побыстрее, ибо не было настолько большого количества указателей, как оно сейчас. А вот с середины нулевых такие вещи стали нормой. А ты про это не узнал, ибо наверняка перешёл на какой-нить пхп/C#/Java. Я угадал? ☺

я разве где-то говорил, что биты можно использовать без их фильтрации?

А разве ты где-то говорил, что нужно их фильтровать? С фильтрацией этот трюк и тривиален, и хорошо переносим.

А разве ты где-то говорил, что нужно их фильтровать?

а разве это не очевидно?

С фильтрацией этот трюк и тривиален

да, тривиален. Отмотай выше, я его привёл совсем не для доказательства своей крутизны, а просто как пример того, что _обычно_ к отдельным байтам никто не адресуется, и во многих случаях это вообще невозможно, разве что сначала прочитать, а потом отфильтровать ненужные байты. И потому «байт» нельзя определять как «минимальный атом адресации». С тем же успехом можно и бит так определить.

и хорошо переносим.

а вот это — довольно спорно.

А разве ты где-то говорил, что нужно их фильтровать?

а разве это не очевидно?

Нет, см. пример с Macintosh. Еще некоторые внешние устройства игнорируеют младшие биты адреса.

хорошо переносим.

а вот это — довольно спорно.

Придумай архитектуру, на которой он не сработает.

Нет, см. пример с Macintosh. Еще некоторые внешние устройства игнорируеют младшие биты адреса.

ну извини. Про внешние устройства речи не было(это вообще-то IO, а не RAM), а про 68000 — сам говоришь, что там не младшие биты можно юзать.

Придумай архитектуру, на которой он не сработает.

зачем придумывать? x86, если ты зачем-то юзаешь и чётные, и нечётные указатели. Этого никто пока не запретил.

Про внешние устройства речи не было(это вообще-то IO, а не RAM), а про 68000 — сам говоришь, что там не младшие биты можно юзать.

IO или RAM - неважно, игнорируются биты на шине адреса, и они могут быть как старшими, так и младшими.

x86, если ты зачем-то юзаешь и чётные, и нечётные указатели

В таком случае и маскирование не поможет.

IO или RAM - неважно, игнорируются биты на шине адреса, и они могут быть как старшими, так и младшими.

важно, потому-что для IO всегда была задействована только часть линий. Что именно игнорировать — не важно. Очевидно, что шина адреса IO всегда дыры имеет.

В таком случае и маскирование не поможет.

ну дык о чём я и говорю. Далось тебе это маскирование, для меня оно самоочевидно.

Не надо так нервничать, просто прочитать тред, где уже уточнено, что это был псевдокод с опиской.

тип int8_t специально создан для того, чтобы гарантировать, что он имеет ровно 8 бит?

«не менее 8 бит» - так правильно. на указанной архитектуре он, скорей всего, тоже 16-битный, по крайней мере, на tms с2000 так.

По-моему, там в stdint.h для C5000 он вообще не определён. Но чтобы не править повсюду код с int8_t на int16_t планирую его определить как int16_t.

Ты бы лучше тег "демагогия" добавил.

Да я бы его и отредактировал, но нет кнопки. А тем временем у меня потихоньку идёт портирование.

IO или RAM - неважно, игнорируются биты на шине адреса, и они могут быть как старшими, так и младшими.

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

Всегда? Ты бредишь.

Далось тебе это маскирование, для меня оно самоочевидно.

Оно только для тебя и очевидно.

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

Всегда? Ты бредишь.

ну с i8080. Раньше не застал.

Ну раз пока тебя тут некто не слил и не вернул в ту лужу, из которой ты вылез - пришел я.

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

Указатель из маллок кратен 16байтам больше из-за его фсподобной природы и free(), а не из-за мистического выравнивания. Поэтому к архитектуре это не имеет никакого отношения.

Навыделяй байтов в ведре или в каком-то рантайме, где слаб-подобный алокатор - удивишься.

Биты у указателя можно использовать, ибо я не знаю того, что умеет указтели больше 48бит - это не сикрет, да и дело даже не в этом - это всё относительно твоего рантайма.

Всё это переносимо и вообще не хак, просто скиллбейзед.

меня это мало волнует. В гугле полно других материалов на эту тему. Суть в том, что это распространённая идиома на практически всех современных архитектурах. Хотя и непереносимая. Зато часто позволяет сэкономить МНОГО памяти. Полезна как низкоуровневая оптимизация для хорошо построенного и уже работающего приложения. Я, кстати, сам не знал, что на гейос это тоже юзается. Как-то не вдавался.

Нет, никкакой архитектуре это не относится. В гугле нет про это инфы. Она переносима.

Не позволяет экономить память, она лишь транжирит её.

Нет, у работающего проложения НИКОГДА НЕ БУДЕТ маллок-подобного аллокатор - запомни это раз и на всегда. Это будет первое, что будет выпилено.

Что там юзается? Там может что угодно юзатся - это особенности сишного рантайма, повторяй эту фразу до просветления.

Та статья, переводчик которой анскиллед, как и тот, кто её писал. К реальному миру не имеет отношения.

я же говорю: это ТЕБЕ что-то непонятно. Я про эту хрень много лет в курсе. Странно лишь только то, что ты сам нагуглить ничего не можешь. Разве это сложно?

Нет, ты даже не удасужился понять от чего и почему так происходит.

я рад за твои Over9000 строк. Только я не понимаю, разве стыдно чего-то не знать? Я вот сам многого не знаю, что в этом страшного?

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

И да, в начале 90х эта идиома была мало известна, как не странно. ИМХО причина в том, что в те годы было очень дорого по времени выполнять фильтрацию указателей. Потому обычно было выгоднее сделать таки побыстрее, ибо не было настолько большого количества указателей, как оно сейчас. А вот с середины нулевых такие вещи стали нормой. А ты про это не узнал, ибо наверняка перешёл на какой-нить пхп/C#/Java. Я угадал? ☺

Про что? Что ты несёшь. Это ПОПЫТКА КАК-ТО ИСПОЛЬЗОВАТЬ ОВЕРХЕД АЛЛОКАТОРА, естественно когда у тебя нет оверхеда аллокатора - ты не можешь юзать этот оверхед в целях уменьшения побочного действия этого оверхеда.

Да, когда у тебя указатель кратен какой-то степени двойки, то естественно начальные биты бесполезны и их можно юзать, только вот зачем? Зачем нужна лишная иструкция на каждое разименование, когда у тебя указателей в программе максимум сотни штук, а разЪименовываешь ты их десятки тысяч раз. Что тебе дадут эти 20-30байт? Ничего. Профита нет - головы на плечах тоже.

Ну раз пока тебя тут некто не слил и не вернул в ту лужу, из которой ты вылез - пришел я.

я аж обосрался.

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

а что у тебя выдал этот код:

#include <stdlib.h>
#include <stdio.h>

int main()
{
	int *a = malloc(10);
	printf("%p\n", a);
	return 0;
}

Указатель из маллок кратен 16байтам больше из-за его фсподобной природы и free(), а не из-за мистического выравнивания. Поэтому к архитектуре это не имеет никакого отношения.

мало кого волнуют догадки школьника, факт остаётся фактом, указатель кратен 16.

Навыделяй байтов в ведре или в каком-то рантайме, где слаб-подобный алокатор - удивишься.

удивлюсь. Если ты код покажешь. А пока ты просто слился.

Биты у указателя можно использовать, ибо я не знаю того, что умеет указтели больше 48бит - это не сикрет, да и дело даже не в этом - это всё относительно твоего рантайма.

ну спасибо, деточка, что ты мне разрешил. Я тебя не забуду.

Всё это переносимо и вообще не хак, просто скиллбейзед.

хм… «Анскильная балоболка» типа меня, таки обладает «скиллбейзед»? Продолжаем делить на ноль? Я же ламо, и этого не мог знать по определению, ведь ты, светочь, мне об этом не сказал.

Он слишком анскиллед и даже не понимает смысла своего выхлопа, а его познание уровня детсада лишь придают ему драматизма.

Нет, никкакой архитектуре это не относится. В гугле нет про это инфы. Она переносима.

т.е. мне нужно поискать за тебя?

Не позволяет экономить память, она лишь транжирит её.

позволяя хранить что-то плюс указатель там, где ты хранишь только указатель?

Нет, у работающего проложения НИКОГДА НЕ БУДЕТ маллок-подобного аллокатор - запомни это раз и на всегда. Это будет первое, что будет выпилено.

а мужики-то не знали, и продолжали юзать malloc(3)…

Что там юзается? Там может что угодно юзатся - это особенности сишного рантайма, повторяй эту фразу до просветления.

у меня нет иного рантайма. А у тебя?

Та статья, переводчик которой анскиллед, как и тот, кто её писал. К реальному миру не имеет отношения.

где тот глобус, в котором автор статей и цитат — ТЫ?

Про что? Что ты несёшь. Это ПОПЫТКА КАК-ТО ИСПОЛЬЗОВАТЬ ОВЕРХЕД АЛЛОКАТОРА, естественно когда у тебя нет оверхеда аллокатора - ты не можешь юзать этот оверхед в целях уменьшения побочного действия этого оверхеда.

учись читать. Я серьёзно. Ты ещё не научился складывать слова в предложения.

Да, когда у тебя указатель кратен какой-то степени двойки, то естественно начальные биты бесполезны и их можно юзать, только вот зачем? Зачем нужна лишная иструкция на каждое разименование, когда у тебя указателей в программе максимум сотни штук, а разЪименовываешь ты их десятки тысяч раз. Что тебе дадут эти 20-30байт? Ничего. Профита нет - головы на плечах тоже.

Т.е. по твоему Стив Жоппс == дурачёк, если столько лет платил идиотам, разработчикам каки? Чтож ты ему раньше-то глаза не открыл?? Сейчас-то уже поздно, эта хрень даже в линухе используется…

Вы тут все демагогию разводите? Пошли лучше в "клуб-2" поболтаем!

ну радуйся. Засчитай себе ещё одну победу демагога.

Ну... тут очень спорный вопрос, кто в этой дискуссии главный демагог.

В гугле полно других материалов на эту тему. Суть в том, что это распространённая идиома на практически всех современных архитектурах.

Когда мы говорим «архитектура», в данном контексте, то подразумеваем «железо», верно? Так вот, здесь, не я превый и не я последний, кто тебе пытается втолковать про архитектуру, а ты отвечаешь про аллокаторы, которые BTW,могут быть реализованы совершенно по-разному на одной и той же архитектуре в зависимости от среды выполнения.

Т.е. тебе про Кузьму, а ты про Ярёму.

что, в гейос в 21ом веке до сих пор как в CP/M аллокатор?

Не знаю какой там у них аллокатор. Связанный список привел по той же причине, что и ramntry с хабра.

что там не так?

Вот это с хабра:

Ясно, что элементарной единицей адресации в памяти является байт-октет

Ты с этим неистово споришь.

И да, в начале 90х эта идиома была мало известна, как не странно.

В начале 90-х? На ассемблере? под DOS-ом? :-) Cам себе аллокатор.

А ты про это не узнал, ибо наверняка перешёл на какой-нить пхп/C#/Java. Я угадал? ☺

Не не угадал. Из всего вышеперечисленного я очень поверхностно знаком только с явой. Си, иногда пару строк asm-а, и не x86.