Необычный процессор

[vak]

Загадка: на каком из процессоров sizeof(int) == sizeof(char)?
Вполне современная архитектура, массово выпускается одной из известных западных фирм.

Comments

[pnv82.livejournal.com]

Если я правильно понял это еще и от компилятора может зависеть?
http://alenacpp.blogspot.com/2009/03/sizeofa.html

[spamsink.livejournal.com]

И BITSPERBYTE, поди, 32?

[vak]

Почти угадал. :)

[vak]

Может зависеть. Подразумевается компилятор, рекомендуемый производителем.

[vak]

Нет, не так. Хотя, возможно, автомобильные контроллеры на этих чипах тоже делают, я не в курсе.

[spamsink.livejournal.com]

Неужели 48?

:)

[vak]

Наоборот, 16 битов на байт. А 48 было в Small-C, который я как-то ради хохмы портонул на БЭСМ-6.

Re: :)

[spamsink.livejournal.com]

16 - это правильно. На процессорах с 16 бит/байт юникод поддержать - как два байта переслать. Базовая страница - 1 байт, все остальное - 2 байта. Красота!

[dvv.livejournal.com]

Восьмибитный int не бывает, C требует, чтобы диапазон значений был не хуже, чем:

— minimum value for an object of type -(2¹⁵ - 1)
— maximum value for an object of type 2¹⁵ - 1
— maximum value for an object of type 2¹⁶ - 1

Re: :)

[dvv.livejournal.com]

Полный Unicode — 32 бита. К примеру, в нормальных браузерах после двоеточия должен быть глиф из репертуара, который в 16 бит в натуральном виде не лезет: 𝄢

Re: :)

[spamsink.livejournal.com]

Ну да, ну и что (http://www.unicode.org/glossary/#surrogate_code_point)?

Re: :)

[spamsink.livejournal.com]

Кстати, http://www.fileformat.info/info/unicode/char/1d122/index.htm

Зачем мне MUSICAL SYMBOL F CLEF?

Re: :)

[dvv.livejournal.com]

С таким подходом и UTF-8 хватает. Восьмибитного.

Re: :)

[dvv.livejournal.com]

С таким подходом и KOI8-R хватает. Восьмибитного.

Re: :)

[spamsink.livejournal.com]

До двух считать проще, чем до 4. А верхние страницы я бы вообще отменил, чтобы всякое говно (http://www.unicode.org/%7Escherer/emoji4unicode/snapshot/utc.html#e-4F4) в стандарт не попадало.

Так может, это фишка?

[vak]

Нафиг нужна пооктетная адресация? Может, так действительно удобнее было бы? Кто бы взялся перенести GCC на такую архитектуру.

Re: внатуре ?

[dvv.livejournal.com]

Тут моих формул нету, тут есть формулы из стандарта языка, раздел 5.2.4.2.1. А про int8_t ни я, ни хозяин журнала слова, вроде как, не сказали.

Re: Так может, это фишка?

[dvv.livejournal.com]

В смысле? Насколько я помню (ох, давно это было), в gcc нету „пооктетной” адресации. Есть char, и есть универсальный пойнтер гранулярности char.

Re: :)

[dvv.livejournal.com]

До одного считать ещё проще. Особенно если в этот один байт уписывать только чистый ASCII, без всякого говна. По–хорошему вообще нужно телеграфным кодом ограничиться. Типа разрядов на 6 максимум.

что-то из DSP.

[zhengxi.livejournal.com]

Analog Devices ?

[vak]

Горячо, горячо! :)

[flhack.livejournal.com]

tms320c54 за современный сойдет?

[dz.livejournal.com]

купил ты меня. хоть я и знаю, что бывают архитектуры с длинным char, не сообразил. :)

PS: даёшь 32-битные символы. хватит экономить.

[vak]

Точняк. :)
Это TMS320C5x и TMS320C2x.

Хреново

[vak]

На таком процессоре невозможно реализовать POSIX. Например read (fildes, data, sizeof(data)). Функция должна выдать указанное количество байтов. А значит, нечётное количество октетов прочитать не получится.

[vak]

В GCC есть внутреннее понятие "unit", по размеру в точности равное char. Но почему-то BITS_PER_UNIT всегда равно 8, других вариантов я не нашёл. Любопытно было бы посмотреть на GCC с 16-битным юнитом.

[vak]

Сам удивляюсь. Казалось, странные размеры байтов канули вместе с мэйнфреймами. Ан нет, байт всё еще не синоним октета. И даже GCC параметризован в этом месте, и можно было бы его приспособить.

[dvv.livejournal.com]

Таки заставил меня залезть в тексты :-) Ну так там ничего не мешает сделать BITS_PER_UNIT 16 (или 32). Будет такой вот толстый байт.

Re: Хреново

[dvv.livejournal.com]

А разве POSIX где–то оперирует термином „октет”?

[vak]

Позикс не оперирует, но COM-порты ведь как-то работать должны? И прочие символьные устройства. Случается иногда передавать нечётное количество октетов, никуда не денешься.

[dvv.livejournal.com]

Ну а какие проблемы? Один октет прекрасно влезает в один широкий байт. Какие проблемы с нечётным количеством широких байтов?

[vak]

Я слышал, что в Новосибирске в начале 90-х Юра Лобанов тащил GCC на Эльбрус-Б, и даже вполне успешно. Других попыток переноса GCC на словные машины я не знаю. Не думаю, что удастся обойтись простой заменой значения одного макроса.

[dvv.livejournal.com]

Дык какие проблемы:

> cat 00.c
#include <wchar.h>
#include <stdio.h>

int
main()
{
        printf("%d\n", (int)sizeof(wchar_t));
}
> gcc 00.c
> ./a.out
4
> 

Только так и работаем :-)

[vak]

Чтобы read() заполнял только младшие биты? А как же тогда пересылать бинарные значения? Типа
int i;
read (fildes, &i, sizeof(i));


[dvv.livejournal.com]

Естественно. В GCC ничего не делается „простой заменой одного макроса” :-)

[dvv.livejournal.com]

Так мы о read() или о COM—портах? Если первое, то естественно, read() должен читать полные (широкие!) байты, а если второе, это дело драйвера утрясать представление данных между устройством и всей остальной системой.

Re: Хреново

[spamsink.livejournal.com]

Не вижу проблемы. read/write могут читать-писать по одному октету на байт (write - возвращать ошибку, если в записываемом байте попался не октет), а для упакованного чтения-записи могут быть отдельные системные вызовы.

[vak]

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

[spamsink.livejournal.com]

Ну хорошо, не отдельные, а переключать режимы с помощью ioctl. По умолчанию работают только четные количества октетов (вот такой block device с блоком в 2 байта), а если очень хочется, то можно переключить в распакованный режим.

[vak]

Получается два режима read/write: упакованный и неупакованный. Причём упакованный работает только с чётным количеством октетов. Криво как-то смотрится.

[dvv.livejournal.com]

Нету в POSIXе двух режимов :-)

[dvv.livejournal.com]

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