Как компьютер различает число и символ?

На основе таблицы ASCII, когда мы сохраняем в памяти ‘TAB’ и десятичную дробь 9, они оба сохраняются как «1001». Как компьютер узнает, что это «TAB» или десятичная цифра 9?


Компьютер не «знает», какой тип конкретного адреса в памяти, это знание запекается в инструкции вашей программы.

Когда вы пишете программу и она видит вашу переменную, компилятор создает ассемблерный код, который где-то записывает этот фрагмент данных, а где-то еще есть другой код, который читает адрес памяти и интерпретирует его как символ . Информация о том, что это символ, не сохраняется в памяти. Местоположение этого адреса памяти — единственное, что связывает эти две операции вместе.

Когда это местоположение читается, сборка не говорит «посмотрите, какой тип данных там», а просто говорит «загрузить это место памяти и рассматривать его как символ». Если, например, что-то перезаписало этот адрес памяти чем-то другим, кроме char, ЦП все равно загрузит эту память как char, и в результате могут произойти всевозможные странные вещи.

Например, в следующей программе:

  #include  int main () {int x;  х = 9;  char * y;  у = & х;  printf (""% s  ""% d  " n", y, x);  printf ("% p  n% p", y, & x);  return 0;}  

Вы получите следующий результат:

  "" "9" 0x7ffd401ce68c 0x7ffd401ce68c  

Итак, мы видим, что одно и то же место в памяти обрабатывается как char и как int. Значение в памяти не знает и не заботится о том, как оно используется.


Позвольте мне использовать почтенный VAX в качестве примера. Предположим, вы определили 8 байтов памяти в каком-то месте:

  location: .ASCII/ABCDEFGH/ 

Инструкция

  MOVC3 location, 8, some_other_location  

обрабатывает память как символы.

Инструкция

  Местоположение ADDL2, R0  

обрабатывает ту же самую память как целочисленное значение

Инструкция

  Расположение MULD2, R8  

обрабатывает ту же самую память как значение с плавающей запятой.

Инструкция :

  Местоположение jmp  

обрабатывает ту же память, что и код (но, вероятно, вырвет).

Память есть память. Как это интерпретируется, зависит от инструкции, действующей в памяти. Компьютер не знает, что хранится в каком-либо месте. Это решать программисту.


Позвольте мне использовать почтенный VAX в качестве примера. Предположим, вы определили 8 байтов памяти в каком-то месте:

  location:. ASCII/ABCDEFGH/ 

Инструкция

  MOVC3 location, 8, some_other_location  

обрабатывает память как символы.

Инструкция

  Местоположение ADDL2, R0  

обрабатывает ту же самую память как целочисленное значение

Инструкция

  MULD2 location, R8  

обрабатывает ту же самую память как значение с плавающей запятой.

Инструкция:

  jmp location  

обрабатывает ту же память, что и код (но, вероятно, вырвет).

Память есть память. Как это интерпретируется, зависит от инструкции, действующей в памяти. Компьютер не знает, что хранится в каком-либо месте. Это решать программисту.


Нет разницы между текстовыми данными или любыми другими типами data как таковые, поэтому компьютер не может различить символ ASCII или простое число в памяти.

Однако процесс при воздействии на эти данные различное содержимое памяти обрабатывается по-разному и приходит с «знанием» типа данных, встроенных в его последовательность команд. Для вызова printf (), например, требуется, чтобы аргумент был строкой символов (строка символов с завершающим нулем). Итак, у вас есть это, знания в процессе, а не данные.

Это может привести к проблемам, потому что программист должен убедиться, что правильные типы аргументов (данных) передаются определенной функции (процессу). — К счастью, компиляторы (и другие помощники, используемые во время разработки во время компиляции или до того, как, например, с помощью статического анализа) также «знают», как вещи должны быть напечатаны (в случае строго типизированных языков), так что ошибочная программа обычно не компилировать. — Но в любом случае, например, в C, вы можете обрабатывать любое содержимое памяти как данные любого типа (например, путем преобразования типов), с некоторыми ограничениями даже как исполняемый код.

Во время выполнения нет (почти) ничего, что мешает программе интерпретировать данные в произвольной области памяти как текст ASCII или простые числа, это просто вопрос представления.

Однако существуют соглашения о том, как программа структурирована и хранит текст в виде статических строк, известных во время компиляции, то есть обычного текста. Обычно они помещаются в сегмент .data или .rodata программы (обычно не в сегмент .text). Вы можете сканировать двоичную программу, используя такие строки:

  $ strings/usr/bin/strings  

Или, если вы хотите узнать больше о сегментах .data/.rodata, objdump binutils может пригодиться:

  $ objdump -h/usr/bin/strings $ objdump --full  -contents --section. rodata/usr/bin/strings  

То же самое можно сделать с помощью шестнадцатеричного редактора:

  $ xxd  $ xxd/usr/bin/strings  

В конце концов, каждая программа должна знать , как обращаться со своей памятью, и как интерпретировать отдельные биты двоичных данных в нем. Программа обычно выполняется внутри операционной системы, которая определяет другие типы ограничений на то, какие области памяти доступны и как, и программа может взаимодействовать с другими процессами вне или внутри коробки (разрешения доступа, системные API, требующие определенный тип данных, например текстовые или двоичные данные). Но опять же, в этом случае знания также заключаются в процессах, а не в самих данных. Аппаратное обеспечение (т.е. процессор и память (RAM, FLASH …)) не обрабатывает текстовые данные принципиально иначе, чем другие типы данных.


Нет никакой разницы между текстовыми данными или любыми другими типами данных как таковых, поэтому компьютер не может отличить символ ASCII от простого число в памяти.

Однако процесс , действующий на эти данные, обрабатывает различное содержимое памяти по-разному и приходит с «знанием» типа данных, запеченных в последовательность его инструкций. Для вызова printf (), например, требуется, чтобы аргумент был строкой символов (строка символов с завершающим нулем). Итак, у вас есть это, знания в процессе, а не данные.

Это может привести к проблемам, потому что программист должен убедиться, что правильные типы аргументов (данных) передаются определенной функции (процессу). — К счастью, компиляторы (и другие помощники, используемые во время разработки во время компиляции или до того, как, например, с помощью статического анализа) также «знают», как вещи должны быть напечатаны (в случае строго типизированных языков), так что ошибочная программа обычно не компилировать. — Но в любом случае, например, в C, вы можете обрабатывать любое содержимое памяти как данные любого типа (например, путем преобразования типов), с некоторыми ограничениями даже как исполняемый код.

Во время выполнения нет (почти) ничего, что мешает программе интерпретировать данные в произвольной области памяти как текст ASCII или простые числа, это просто вопрос представления.

Однако существуют соглашения о том, как программа структурирована и хранит текст в виде статических строк, известных во время компиляции, то есть обычного текста. Обычно они помещаются в сегмент .data или .rodata программы (обычно не в сегмент .text). Вы можете сканировать двоичную программу, используя такие строки:

  $ strings/usr/bin/strings  

Или, если вы хотите узнать больше о сегментах .data/.rodata, objdump binutils может пригодиться:

  $ objdump -h/usr/bin/strings $ objdump --full  -contents --section. rodata/usr/bin/strings  

То же самое можно сделать с помощью шестнадцатеричного редактора:

  $ xxd  $ xxd/usr/bin/strings  

В конце концов, каждая программа должна знать , как обращаться со своей памятью, и как интерпретировать отдельные биты двоичных данных в нем. Программа обычно выполняется внутри операционной системы, которая определяет другие типы ограничений на то, какие области памяти доступны и как, и программа может взаимодействовать с другими процессами вне или внутри коробки (разрешения доступа, системные API, требующие определенный тип данных, например текстовые или двоичные данные). Но опять же, в этом случае знания также заключаются в процессах, а не в самих данных. Оборудование (т.е. процессор и память (RAM, FLASH …)) не обрабатывает текстовые данные принципиально иначе, чем другие типы данных.

Оцените статью
techsly.ru
Добавить комментарий