k155la3 26 21 июня, 2020 Опубликовано 21 июня, 2020 · Жалоба 1 hour ago, Мухожук said: . . .. Компилятор использовал битовые маски и сдвиги для представления такого Cишного "байта". И также у них был вариант не противоречя стандарту реализовать 12- и 18- разрядные "байты", так как 36 кратно данным величинам. Во времена PDP-10 была не очень оптимальная элементная база (процессор делался "наразвес" на чипах небольшой степени интеграции), и чтобы не добавлять аппаратно какую-либо функцию, она встраивалась в виде "костыля" в компилятор. И критичным и дорогим, IMHO, были - объем ОЗУ и изменения в структуре-конфигурации процессора и его микрокода. Соответственно, как промежуточные решения, изменения вносились как функции компилятора. При нынешних объемах встроенных ОЗУ и флеш, возможности подключения внешних (произвольного размера) накопителей, упаковывать нестандартные "байты" оптимально, в имеющуюся структуру памяти смысла особого не имеет. А где имеет (в редких случаях) - это делается на прикладном уровне, уже программистом, а не компилятором. Шас символьный тип не только 8 бит, но и 16 (unicode) Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
yes 5 21 июня, 2020 Опубликовано 21 июня, 2020 · Жалоба 16 hours ago, k155la3 said: За всю свою жизнь не удалось встретить байта, с разрядностью, отличной от 8. Разве что 9-битный USART или какая-то экзотика вроде старших братьев i4004. TMS320C55xx популярнейшее DSP от ТИ - char 16 бит upd предположу, что uint8_t и т.п. там тоже нет - не умеет железо в байтах адресовать upd2 не заметил выше про ТИ, ну тогда всякие ПИК-и с их программной памятью с 12, 14 и т.п. бит шириной. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Arlleex 131 21 июня, 2020 Опубликовано 21 июня, 2020 · Жалоба 4 часа назад, jcxz сказал: Это не байт, байт всегда == 8 бит. Поэтому в мануалах оперируют термином "слово" или "символ" для UART. Если быть совсем точным, то байт это не всегда 8 бит. Октет всегда 8 бит. Байт вещь произвольная, теоретически зависит от архитектуры. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Baser 5 21 июня, 2020 Опубликовано 21 июня, 2020 · Жалоба 2 часа назад, yes сказал: upd2 не заметил выше про ТИ, ну тогда всякие ПИК-и с их программной памятью с 12, 14 и т.п. бит шириной. Тут замечу, что нельзя валить в кучу ширину программной памяти и ширину данных. В ПИКах с их DSP-шной архитектурой ширина программной памяти действительно разная, напр. 24-х битная. Но данные все равно стандартные 8-и битные. И внутреннее ОЗУ 8-и битное, и при упаковке данных в программную память данные тоже 8-и битные. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
AlexandrY 3 21 июня, 2020 Опубликовано 21 июня, 2020 · Жалоба 11 hours ago, Мухожук said: Документ ANSI/ISO C90, в нем многократно встречается термин "abstract machine". Может я не правильно его понимаю... Абстрактность машины здесь означает произвольность ее выбора теми кто делает компилятор. Это не значит что существует модель этой машины. Иначе она была бы приведена в стандарте. Посмотрите определение термина - https://en.wikipedia.org/wiki/Abstract_machine За то C и ругают, что у него нет модели среды исполнения. Из-за чего его либы сильно неюзабельны. Единственно что C предполагает - это RAM, CPU, регистры и абстрактный IO. Я бы это моделью машины не назвал. Ну да, абстракция, но капец какая абстрактная абстракция. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
yes 5 22 июня, 2020 Опубликовано 22 июня, 2020 · Жалоба когда С писали еще не придумали такого. тогда это называлось 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 22 июня, 2020 Опубликовано 22 июня, 2020 (изменено) · Жалоба 15 hours ago, AlexandrY said: Абстрактность машины здесь означает произвольность ее выбора теми кто делает компилятор. Это не значит что существует модель этой машины. Иначе она была бы приведена в стандарте. То есть получается, что в стандарте С нет как такового строго детерминированного описания модели абстрактной машины (но такие машины заданы в других языках программирования). Она описана грубыми штрихами, и в силу этого у разработчиков компиляторов C большая свобода трактовать ее по своему, но не выходя за минимальные требования стандарта, и из-за этого видимо такое обилие implementation и undefined behaviour? Изменено 22 июня, 2020 пользователем Мухожук Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться