Как стандартно в Си узнать размер char-а, А соответственно и функции sizeof() Опции

[GetSmart]

А напишу-ка я здесь. Прикинусь начинающим.

Столкнулся работая с TMS320 с тем, что у него тип char имеет 2 байта. И (кто бы мог подумать) sizeof() выдаёт размеры переменных тоже в 16 битных словах.
Вопрос: как стандартными методами преобразовать этот размер в байтовый размер, то бишь метод должен одинаково работать на всех платформах, и там где sizeof() байтовый.

[ReAl]

Вопрос: как стандартными методами преобразовать этот размер в байтовый размер, то бишь метод должен одинаково работать на всех платформах, и там где sizeof() байтовый.

Код

#include <limits.h>

#define CHAR_BYTES  (CHAR_BIT / 8)

Тьху, позор, срочно исправил на более приличный вариант

Ну если запараноиться на всякие 9-ти битовые char, то, конечно, посложнее надефайнить придётся, а так - размер в битах (и куча другого полезного) лежит в этом самом limits.h

int true_size = SIZE_OF_CHAR * sizeof(char);

хотя смотрится это не вот уж...

Код

#define BYTESOF(a)  (CHAR_BYTES * sizeof(a))

[aaarrr]

Код

#define BYTESOF(a)  (CHAR_BYTES * sizeof(a))

Справедливости ради надо заметить, что так лажа выйдет на платформе с 16-битным char и "честным" sizeof(), возвращающим размер в байтах.

[GetSmart]

Справедливости ради надо заметить, что так лажа выйдет на платформе с 16-битным char и "честным" sizeof(), возвращающим размер в байтах.

Мне тут SM подсказывает, что sizeof() по стандарту должен выдавать размер как раз в char-ах. Вопрос: так ли это на самом деле?

[dxp]

Мне тут SM подсказывает, что sizeof() по стандарту должен выдавать размер как раз в char-ах. Вопрос: так ли это на самом деле?

Насколько помню, sizeof возвращает размер в минимально адресуемых единицах на данной платформе. И "байтом" обычно эту минимально адресуемую ячейку памяти и называют, другими словами, на этом TMS'е байт как раз 16 бит. Поэтому sizeof выдает правильный результат. А char может иметь любой размер при условии, что он больше 8 бит. Т.е. может иметь хоть 16, хоть 24, хоть 32. При том, что размер байта на этой же платформе может быть и 8 бит. В общем, это отдано на откуп реализации. Но чаще всего char делают размером с байт (по здравому смыслу), т.к. платформы с минимально адресуемой ячейкой менее 8 бит являются экзотикой (равно как и спец фичи типа битовых процессоров MCS-51).

[SM]

другими словами, на этом TMS'е байт как раз 16 бит.

На этом TMS-е есть адресации "low_byte(addr)" и "high_byte(addr)" для команд load/store. Так что байт там как у всех. Как есть и битовые операции типа MCS-51. А вот лень у разработчиков компилятора - явно присутствует в изобилии, для char-а могли бы эти адресации использовать, хотя они и выходят за рамки концепции всей системы команд, являясь ее как бы дополнением.

[dxp]

На этом TMS-е есть адресации "low_byte(addr)" и "high_byte(addr)" для команд load/store. Так что байт там как у всех.

А по скорости/накладным они такие же, как и для словной адресации? Или это некое расширение, реализуемое за счет эмуляции (типа, слово считывается целиком, в АЛУ модифицируется нужный байт и потом складываются в память)?

Тогда несостыковка получается, т.к. явно указывается, что sizeof(char)=1. То есть если у системы восьмибитный байт, то char тоже обязан быть восьмибитным.

Да, насчет sizeof(char) был неправ (давно было, забывать начал ). В плюсах тоже так же: sizeof(char), sizeof(signed char) and sizeof(unsigned char) are 1;

[SM]

А по скорости/накладным они такие же, как и для словной адресации? Или это некое расширение, реализуемое за счет эмуляции (типа, слово считывается целиком, в АЛУ модифицируется нужный байт и потом складываются в память)?

Да, по скорости и накладным тоже самое, но только в том случае, если заранее известно, какой байт нужен - low или high. К АЛУ это отношения не имеет, так как при обращениях оно управляет сигналами "byte enable (BE[1:0])" шины, или DQM-ами, если это SDRAM. Но адрес-то при этом все равно словесный, а выбор байта осуществляется при помощи указания конкретной команды ассемблера. Т.е. если организовывать полностью произвольный доступ к любому байту - то нужно иметь словесный адрес, бит выбора байта и условное выполнение той или другой команды. Плюс ко всему, если слово памяти может быть аргументом любой арифметики и можно сказать любой операции вообще, то байт из памяти только или load, или store.

[defunct]

Т.е. если организовывать полностью произвольный доступ к любому байту - то нужно иметь словесный адрес, бит выбора байта и условное выполнение той или другой команды. Плюс ко всему, если слово памяти может быть аргументом любой арифметики и можно сказать любой операции вообще, то байт из памяти только или load, или store.

Очередное дерьмецо от TI... Годное только для обработки звука.
Непонятно только зачем там USB.

[GetSmart]

В общем очередное дерьмецо от TI... Годное только для обработки звука.

Щас SM Вас порвёт

На самом деле, раз адресация в проце на 90% только пословная, то TI сделали правильно. Там только DMA имеет байтовый адрес.

Асмописатели на TMS наверное очень довольны такой архитектурой, в отличие от сишников. SM как раз один из них.

Сообщение отредактировал GetSmart - Aug 21 2009, 16:59

[defunct]

Щас SM Вас порвёт

Ну от этого Вам будет не легче передать фрейм нечетной длины. :P

А TI изделия (без учета приобретений на стороне - BB, Luminary и т.п.) всегда считал и продолжаю считать неадекватными, за редким исключением.
Почти каждый их DSP / MK - это "шедевр" полученный в результате больной фантазии индусов.

[GetSmart]

Ну от этого Вам будет не легче передать фрейм нечетной длины. :P

Проблема не в невозможности, а в неудобстве/некрасивости сишной реализации.