Які платформи мають щось інше, ніж 8-бітний графік?

Час від часу хтось із SO зазначає, що char(також "байт") не обов'язково 8 біт .

Здається, що 8-бітний charмайже універсальний. Я б подумав, що для основних платформ необхідно мати 8-розрядний, charщоб забезпечити його життєздатність на ринку.

Зараз і історично, які платформи використовують a, charщо не є 8 бітами, і чому вони відрізняються від "нормальних" 8 біт?

Коли ви пишете код і думаєте про підтримку крос-платформ (наприклад, для бібліотек загального користування), яке врахування варто приділити платформам, які не є 8-бітними char?

Раніше я стикався з деякими ЦАП аналогових пристроїв, для яких char16 біт. DSP - це трохи нішева архітектура. (Знову ж таки, під час ручного кодування асемблер легко обіграв те, що могли зробити наявні компілятори C, тому я не мав особливого досвіду роботи з C на цій платформі.)

charтакож є 16 бітним на DSP Texas Instruments C54x, який з'явився, наприклад, в OMAP2. Є інші DSP з 16 і 32 біт char. Я думаю, що я навіть чув про 24-розрядний DSP, але не можу пригадати що, тому, можливо, я уявив це.

Інша думка полягає в тому, що POSIX мандати CHAR_BIT == 8. Тож якщо ви використовуєте POSIX, ви можете це припустити. Якщо хтось пізніше повинен перенести ваш код до майже реалізованої POSIX, у вас просто так є функції, які ви використовуєте, але іншого розміру char, це їхня невдача.

Взагалі, однак, я думаю, що майже завжди простіше вирішити проблему, ніж думати над цим. Просто введіть CHAR_BIT. Якщо ви хочете ввести точний 8-бітний тип, використовуйте int8_t. Ваш код шумно не зможе скомпілюватись у реалізаціях, які не забезпечують його, замість того, щоб тихо використовувати розмір, який ви не очікували. Принаймні, якби я потрапив у випадок, коли у мене були вагомі підстави припустити це, то я б це запевнив.

Коли ви пишете код і думаєте про підтримку крос-платформ (наприклад, для бібліотек загального користування), яку саме увагу варто приділити платформам, які не мають 8-бітових знаків?

Справа не стільки в тому, що "варто врахувати" щось, як це грає за правилами. Наприклад, у C ++ стандарт каже, що всі байти матимуть "принаймні" 8 біт. Якщо ваш код передбачає, що в байтах рівно 8 біт, ви порушуєте стандарт.

Зараз це може здатися дурним - " звичайно, всі байти мають 8 біт!" Але багато дуже розумних людей покладалися на припущення, які не були гарантіями, і тоді все зламалось. Історія рясніє такими прикладами.

Наприклад, більшість розробників на початку 90-х припускали, що певна затримка синхронізованого процесора з фіксованою кількістю циклів потребуватиме фіксованого часу, оскільки більшість споживчих процесорів були приблизно однаковою за потужністю. На жаль, комп’ютери стали дуже швидкими. Це породило підйом ящиків за допомогою кнопок "Turbo" - мета яких, за іронією долі, полягала в тому, щоб уповільнити роботу комп'ютера, щоб ігри, що використовують техніку затримки часу, могли грати з розумною швидкістю.

Один коментатор запитав, де в стандарті йдеться про те, що char повинен мати принаймні 8 біт. Це в розділі 5.2.4.2.1 . Цей розділ визначає CHAR_BITкількість бітів у найменшій адресованій сутності та має значення за замовчуванням 8. Тут також зазначено:

Значення, визначені їх реалізацією, повинні бути рівними або більшими за величиною (абсолютне значення) показаним, з однаковим знаком.

Отже, будь-яке число, рівне 8 або більше, підходить для заміни реалізацією в CHAR_BIT.

Машини з 36-бітовою архітектурою мають 9-бітні байти. За даними Вікіпедії, машини з 36-бітовою архітектурою включають:

• Корпорація цифрового обладнання PDP-6/10
• IBM 701/704/709/7090/7094
• UNIVAC 1103 / 1103A / 1105/1100/2200,

Кілька з яких мені відомо:

• DEC PDP-10: змінна, але найчастіше 7-бітні символи упаковані 5 на 36-бітове слово, або ж 9-бітні символи, 4 на слово
• Основні рамки керування даними (CDC-6400, 6500, 6600, 7600, Cyber ​​170, Cyber ​​176 тощо) 6-бітні символи, упаковані 10 на 60-бітове слово.
• Основні рамки Unisys: 9 біт / байт
• Windows CE: просто не підтримує тип `char` - натомість потрібен 16-розрядний wchar_t

Немає такого поняття, як повністю портативний код. :-)

Так, можуть бути різні розміри байтів / знаків. Так, для платформ із вкрай незвичайними значеннями CHAR_BITта і може бути реалізація C / C ++ UCHAR_MAX. Так, іноді можна написати код, який не залежить від розміру char.

Однак майже будь-який реальний код не є самостійним. Наприклад, ви можете писати код, який надсилає двійкові повідомлення в мережу (протокол не важливий). Ви можете визначити структури, які містять необхідні поля. Чим вам доведеться це серіалізувати. Просто бінарне копіювання структури у вихідний буфер не є портативним: як правило, ви не знаєте ні байтового порядку для платформи, ні членів структури вирівнювання, тому структура просто зберігає дані, але не описує спосіб серіалізації даних. .

Гаразд. Ви можете виконувати перетворення порядку байтів і переміщувати елементи структури (наприклад, uint32_tабо подібні), використовуючи memcpyв буфер. Чому memcpy? Тому що існує дуже багато платформ, на яких неможливо записати 32-бітну (16-бітну, 64-бітну - немає різниці), коли цільова адреса не вирівняна належним чином.

Отже, ви вже багато зробили для досягнення портативності.

І ось остаточне питання. У нас буфер. Дані з нього надсилаються до мережі TCP / IP. Така мережа передбачає 8-бітні байти. Питання: якого типу буфера повинен бути? Якщо ваші символи 9-бітні? Якщо вони 16-бітні? 24? Можливо, кожен char відповідає одному 8-бітовому байту, надісланому в мережу, і використовується лише 8 біт? А може кілька байтів мережі упаковані в 24/16/9-бітні символи? Це питання, і важко повірити, що є одна відповідь, яка підходить для всіх випадків. Багато речей залежить від реалізації сокета для цільової платформи.

Отже, про що я говорю. Зазвичай код може бути досить легко переносимим певною мірою . Це дуже важливо, якщо ви очікуєте використання коду на різних платформах. Однак покращення портативності поза цим показником - це справа, яка вимагає великих зусиль і часто дає мало зусиль , оскільки реальний код майже завжди залежить від іншого коду (реалізація сокета в прикладі вище). Я впевнений, що приблизно 90% кодової здатності працювати на платформах, окрім 8-бітових байтів, майже марно, оскільки вона використовує середовище, пов'язане з 8-бітовим. Просто перевірте розмір байтів і виконайте затвердження часу компіляції. Вам майже напевно доведеться багато переписати для надзвичайно незвичної платформи.

Але якщо ваш код сильно "автономний" - чому б і ні? Ви можете записати його таким чином, що дозволяє різні розміри байтів.

Виявляється, ви все ще можете придбати IM6100 (тобто PDP-8 на чіпі) зі складу. Це 12-бітна архітектура.

Багато мікросхем DSP мають 16- або 32-бітні char. TI звичайно робить такі фішки, наприклад .

Наприклад, мови програмування C і C ++ визначають байт як "адресується одиниця даних, достатньо велика, щоб вмістити будь-якого члена основного набору символів середовища виконання" (п. 3.6 стандарту C). Оскільки інтегральний тип даних C char повинен містити щонайменше 8 біт (п. 5.2.4.2.1), байт у C може принаймні вміщати 256 різних значень. Різні реалізації C і C ++ визначають байт як 8, 9, 16, 32 або 36 біт

Цитується з http://en.wikipedia.org/wiki/Byte#History

Хоча не впевнений в інших мовах.

http://en.wikipedia.org/wiki/IBM_7030_Stretch#Data_Formats

Визначає байт на цій машині, який має змінну довжину

Сім'я DEC PDP-8 мала 12-бітове слово, хоча ви зазвичай використовували 8-бітний ASCII для виводу (в основному для телетайпу). Однак був також 6-бітний код символів, який дозволив кодувати 2 символи в одному 12-бітному слові.

Для одного символи Unicode довші, ніж 8-бітні. Як згадував хтось раніше, специфікація C визначає типи даних за їх мінімальними розмірами. Використовуйте sizeofта значення, limits.hякщо ви хочете допитати свої типи даних та дізнатись, який саме розмір вони мають для вашої конфігурації та архітектури.

З цієї причини я намагаюся дотримуватися типів даних, наприклад, uint16_tколи мені потрібен тип даних певної довжини бітів.

Редагувати: Вибачте, я спочатку неправильно прочитав ваше запитання.

Специфікація C говорить, що charоб'єкт "досить великий, щоб зберігати будь-який член набору символів виконання". limits.hперелічує мінімальний розмір 8 біт, але визначення залишає максимальний розмір charвідкритим.

Таким чином, a charє щонайменше до тих пір, поки найбільший символ із набору виконання вашої архітектури (як правило, округлюється до найближчої 8-бітної межі). Якщо у вашій архітектурі є довші опкоди, ваш charрозмір може бути довшим.

Історично опкод платформи x86 був одним байтом, тому charспочатку було 8-бітним значенням. Поточні платформи x86 підтримують опкоди довші, ніж один байт, але цей charвміст зберігається у довжині 8 біт, оскільки саме цим обумовлені програмісти (та великі обсяги існуючого коду x86).

Розмірковуючи про підтримку багатоплатформ, скористайтеся типами, визначеними в stdint.h. Якщо ви використовуєте (наприклад) в uint16_t, то ви можете бути впевнені , що це значення без знака 16-розрядне значення , на якій архітектурі, будь то 16-бітове значення відповідає char, short, intабо що - то інше. Більшість важкої роботи вже зроблено людьми, які написали ваш компілятор / стандартні бібліотеки.

Якщо вам потрібно знати точний розмір, charтому що ви виконуєте апаратні маніпуляції низького рівня, які вимагають цього, я зазвичай використовую тип даних, який є досить великим, щоб вмістити charна всіх підтримуваних платформах (як правило, достатньо 16 біт) і запустити значення через convert_to_machine_charрутину, коли мені потрібно точне представлення машини. Таким чином, специфічний для платформи код обмежений функцією інтерфейсу і більшу частину часу я можу використовувати звичайний uint16_t.

Яке врахування варто приділити платформам, які не мають 8-бітових знаків?

магічні числа виникають, наприклад, при зміщенні;

більшість із них можна обробити досить просто, використовуючи CHAR_BIT і, наприклад, UCHAR_MAX замість 8 та 255 (або подібних).

сподіваємось, ваша реалізація визначає це :)

це "загальні" питання .....

Інше непряме питання - це те, що у вас є:

struct xyz {
   uchar baz;
   uchar blah;
   uchar buzz; 
}

це може «брати» лише (найкращий випадок) 24 біти на одній платформі, але може брати, наприклад, 72 біти в іншому місці .....

якщо кожен учар містив "бітові прапори", а кожен учар мав лише 2 "значущі" біти або прапори, якими ви користуєтесь в даний час, і ви лише організували їх у 3 схеми для "ясності", то це може бути відносно "більш марнотратним", наприклад, на платформа з 24-бітними uchars .....

ніщо бітфілд не може вирішити, але у них є інші речі, на які слід стежити ...

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

можливо, не справжній приклад, але такі речі, як це "покусали" мене при перенесенні / програванні з деяким кодом .....

лише той факт, що якщо учар втричі більший, ніж очікується, "100 таких" очікується, 100 таких структур можуть витратити багато пам'яті на деяких платформах ... там, де "нормально", це не велика справа .... .

тому все ще можна "зламати" або в цьому випадку "витратити багато пам'яті дуже швидко" через припущення, що uchar "не дуже марнотратний" на одній платформі, відносно наявної оперативної пам'яті, ніж на іншій платформі ... ..

проблема може бути більш помітною, наприклад, для int або інших типів, наприклад, у вас є якась структура, якій потрібно 15 біт, тому ви вставляєте її в int, але на іншій платформі int становить 48 біт або що завгодно .... .

"нормально", ви можете розбити його на 2 рівні, але, наприклад, з 24-бітним учаром вам знадобиться лише один .....

тож перерахунок може бути кращим "загальним" рішенням ....

залежить від того, як ви отримуєте доступ до цих бітів :)

тож, можуть виникнути "недоліки дизайну", які затримують голову .... навіть якщо код все ще може працювати / працювати нормально, незалежно від розміру учара чи уті ...

є такі речі, на які слід дивитися, хоча у вашому коді немає жодних "магічних чисел" ...

сподіваюся, що це має сенс :)

ints раніше було 16 біт (pdp11 тощо). Перейти до 32-бітної архітектури було важко. Люди стають кращими: навряд чи хтось припускає, що вказівник більше не поміститься (ви не так?). Або файлові зсуви, або часові позначки, або ...

8-бітові символи вже є дещо анахронізмом. Нам вже потрібно 32 біти, щоб вмістити всі набори символів у світі.