Jump to content

    
Sign in to follow this  
Мухожук

Абстрактная машина С и ее модель памяти

Recommended Posts

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

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

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

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

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

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

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

Share this post


Link to post
Share on other sites
16 hours ago, k155la3 said:

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

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

 

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

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

Share this post


Link to post
Share on other sites
4 часа назад, jcxz сказал:

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

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

Share this post


Link to post
Share on other sites
2 часа назад, yes сказал:

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

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

Share this post


Link to post
Share on other sites
11 hours ago, Мухожук said:

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

ANSI.jpg

 

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

Share this post


Link to post
Share on other sites

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

тогда это называлось 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: то есть вопрос с абстрактизацией модели во времена писания С решался в стиле "вам ехать или шашечки?". то есть под каждое железо хотелось иметь язык "среднего уровня", а не ковыряться с ассемблером

 

 

 

Share this post


Link to post
Share on other sites
15 hours ago, AlexandrY said:

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

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

Edited by Мухожук

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Sign in to follow this