[k155la3 26]

1 hour ago, Мухожук said:

 . . .. Компилятор использовал битовые маски и сдвиги для представления такого Cишного "байта". И также у них был вариант не противоречя стандарту реализовать 12- и 18- разрядные "байты", так как 36 кратно данным величинам.

Во времена PDP-10 была не очень оптимальная элементная база (процессор делался "наразвес" на чипах небольшой степени интеграции), и чтобы не добавлять аппаратно какую-либо функцию, она встраивалась в виде "костыля" в компилятор.

И критичным и дорогим, IMHO, были - объем ОЗУ и изменения в структуре-конфигурации процессора и его микрокода.

Соответственно, как промежуточные решения, изменения вносились как функции компилятора.

При нынешних объемах встроенных ОЗУ и флеш, возможности подключения внешних (произвольного размера) накопителей, упаковывать нестандартные "байты" оптимально, в имеющуюся структуру памяти смысла особого не имеет. А где имеет (в редких случаях) - это делается на прикладном уровне, уже программистом, а не компилятором.

Шас символьный тип не только 8 бит, но и 16 (unicode) 

[yes 5]

16 hours ago, k155la3 said:

За всю свою жизнь не удалось встретить байта, с разрядностью, отличной от 8. Разве что 9-битный USART или какая-то экзотика вроде старших братьев i4004. 

TMS320C55xx популярнейшее DSP от ТИ - char 16 бит

 

upd предположу, что uint8_t и т.п. там тоже нет - не умеет железо в байтах адресовать

upd2 не заметил выше про ТИ, ну тогда всякие ПИК-и с их программной памятью с 12, 14 и т.п. бит шириной.

[Arlleex 131]

4 часа назад, jcxz сказал:

Это не байт, байт всегда == 8 бит. Поэтому в мануалах оперируют термином "слово" или "символ" для UART.

Если быть совсем точным, то байт это не всегда 8 бит. Октет всегда 8 бит. Байт вещь произвольная, теоретически зависит от архитектуры.

[Baser 5]

2 часа назад, yes сказал:

upd2 не заметил выше про ТИ, ну тогда всякие ПИК-и с их программной памятью с 12, 14 и т.п. бит шириной.

Тут замечу, что нельзя валить в кучу ширину программной памяти и ширину данных. В ПИКах с их DSP-шной архитектурой ширина программной памяти действительно разная, напр. 24-х битная. Но данные все равно стандартные 8-и битные. И внутреннее ОЗУ 8-и битное, и при упаковке данных в программную память данные тоже 8-и битные.

[AlexandrY 2]

11 hours ago, Мухожук said:

Документ ANSI/ISO C90, в нем многократно встречается термин "abstract machine". Может я не правильно его понимаю...

 

Абстрактность машины здесь означает произвольность ее выбора теми кто делает компилятор. 
Это не значит что существует  модель этой машины.
Иначе она была бы приведена в стандарте.
Посмотрите определение термина - https://en.wikipedia.org/wiki/Abstract_machine 
За то C и ругают, что у него нет модели среды исполнения. Из-за чего его либы сильно неюзабельны. 
Единственно что C предполагает - это RAM, CPU, регистры и абстрактный IO. Я бы это моделью машины не назвал. 
Ну да, абстракция, но капец какая абстрактная абстракция.  

[yes 5]

когда С писали еще не придумали такого.

тогда это называлось ABI application binary interface https://en.wikipedia.org/wiki/Application_binary_interface

то есть туда входило взаимодействие С с железом (иногда и с операционкой), не только данные, но и стэк фрэйм, процедура вызовов и т.п. (см вики)

также много за пределами С - например модель памяти - типа сохраняется ли порядок записи, или вообще хоть что-то https://en.wikipedia.org/wiki/Memory_ordering

также всякие обработчики эксепшинов, выравнивание и пр.

----------

нынче все ABI унылы и однообразны, а в те времена было много прикольного - народ с железом экспериментировал. из сохранившегося - SPARC - если есть свободное время рекомендую почитать для прочистки воображения :) начать можно с аппаратного стека и underflow / overflow исключений. (google: sparc abi - есть документ хороший)

----------

а сейчас наверно удобно прикрутить какую-то идею С абстрактной машины к тому, что наделали раньше.

я бы смотрел на LLVM -  это как бы машина заточеная как раз под С и под С/С++ компиляторы.  то есть написать бэкенд для трансляции кода этой машины в любой разумный ассемблер не сложно, и с С/С++ фронтэнд для трансляции в эту машину уже есть (gcc собственно)

======

upd: то есть вопрос с абстрактизацией модели во времена писания С решался в стиле "вам ехать или шашечки?". то есть под каждое железо хотелось иметь язык "среднего уровня", а не ковыряться с ассемблером

 

 

 

[Мухожук 0]

15 hours ago, AlexandrY said:

Абстрактность машины здесь означает произвольность ее выбора теми кто делает компилятор. 
Это не значит что существует  модель этой машины.
Иначе она была бы приведена в стандарте.
 

То есть получается, что в стандарте С нет как такового строго детерминированного описания модели абстрактной машины (но такие машины заданы в других языках программирования). Она описана грубыми штрихами, и в силу этого у разработчиков компиляторов C большая свобода трактовать ее по своему, но не выходя за минимальные требования стандарта, и из-за этого видимо такое обилие implementation и undefined behaviour?

Изменено 22 июня, 2020 пользователем Мухожук