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

[vak]

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

Comments

[vak]

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

[spamsink.livejournal.com]

Неужели 48?

:)

[vak]

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

Re: :)

[spamsink.livejournal.com]

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

Re: :)

[dvv.livejournal.com]

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

Re: :)

[spamsink.livejournal.com]

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

Re: :)

[dvv.livejournal.com]

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

Re: :)

[spamsink.livejournal.com]

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

Re: :)

[dvv.livejournal.com]

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

Re: :)

[spamsink.livejournal.com]

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

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

Re: :)

[dvv.livejournal.com]

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

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

[vak]

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

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

[dvv.livejournal.com]

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

[vak]

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

[dvv.livejournal.com]

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

[vak]

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

[dvv.livejournal.com]

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

Хреново

[vak]

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

Re: Хреново

[dvv.livejournal.com]

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

[vak]

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

[dvv.livejournal.com]

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

[vak]

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


[dvv.livejournal.com]

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

[vak]

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

[dvv.livejournal.com]

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

Re: Хреново

[spamsink.livejournal.com]

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

[vak]

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

[spamsink.livejournal.com]

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

[dvv.livejournal.com]

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