Язык Си. Парсер для подсветки Си-кода, глобальные переменные

[ozheredov]

(TheRuinedMap)

TheRuinedMap

"The Ruined Map (燃え尽きた地図 Moetsukita chizu) is a novel written by the Japanese writer Kōbō Abe in 1967.
The Ruined Map is the story of an unnamed detective, hired by a beautiful, alcoholic woman, to find clues related to the disappearance of her husband. In the process, the detective is given a map (a ruined one), supposedly to help him, but which turns out in the end to be more like a metaphor of the guidelines one should have in life. The impossibility of finding relevant clues to help him solve the mystery leads the main character to an existential crisis, which builds slowly from the inside and finally puts him in the position of identifying himself with the man he was supposed to find."

Это из Википедии. Интересно, что таким потрясающим спецам как Вы заходят именно такие вещи. Почитаю обязательно. Ну и позвольте выразить восхищение Вашим скиллом.

[oleg_2]

TheRuinedMap в сообщении #1577408 писал(а):

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

Для локальных переменных ответ на этот вопрос очевиден и естественен, ибо объявления локальных переменных естественным образом "вплетены" в код функции. Выполняй инициализацию по мере достижения объявлений переменных - и всё. А константная это инициализация или какая-то нетривиальная - значения не имеет. Просто выполняй и все.

А с глобальными переменными как быть? Объявления переменных на уровне файла не "вплетены" ни в какой код. Когда выполнять их инициализацию, если эта инициализация нетривиальна? Язык С решает эту проблему радикально: никогда. Инициализация глобальных переменных (и вообще статических переменных) должна быть константной и тривиальной. То есть, выражаясь условно (и с определенной натяжкой), одна должна делаться "еще на стадии компиляции".

"Язык С решает эту проблему радикально: никогда", - вроде бы понятно (о нетривиальной инициализации глобальных).
Я не знаю устройства компьютера и ассемблер, но интуитивно кажется, что в большой памяти компьютера программе должно быть отведено какое-то место, хотя бы в виде одной опорной точки (физического адреса), от которой уже и плясать, чтобы определить при запуске программы, где стек и где куча. Например, адрес опорной точки $A$, куча от $(A+200)$ до $(A+1000)$, стек от $(A+1000)$ до $(A+2000)$. И как я понимаю, такое распределение должно быть сделано при запуске программы, где найдётся свободное место в памяти.

И тогда ещё такой вопрос, фрагмент кода:

Используется синтаксис C

#define FB   9  /*кодовая длина быстрого декодирования (max 15)*/
#define FS  (1 << FB) /*число элементов массива быстрого декодирования*/

Здесь есть вычисление для инициализации макроса (1 << FB). У меня это работает, но соответствует ли это формально правилам языка Си?

[TheRuinedMap]

oleg_2 в сообщении #1577494 писал(а):

интуитивно кажется, что в большой памяти компьютера программе должно быть отведено какое-то место, хотя бы в виде одной опорной точки (физического адреса), от которой уже и плясать, чтобы определить при запуске программы, где стек и где куча. Например, адрес опорной точки $A$, куча от $(A+200)$ до $(A+1000)$, стек от $(A+1000)$ до $(A+2000)$. И как я понимаю, такое распределение должно быть сделано при запуске программы, где найдётся свободное место в памяти.

Нет и да.

Нет, потому что в современных полномасштабных платформах (Windows, Linux и т.п.) программы запускаются в виртуальной памяти. То есть на старте программы получают персональное, полностью свободное, чистое как лист бумаги адресное пространство целиком в свое эксклюзивное распоряжение. Поэтому программе не нужно "пихаться локтями" с другими программами и искать некую свободную опорную точку A. Так как виртуальное адресное пространство изначально полностью свободно и полностью принадлежит программе, она может заранее выбрать любую опорную точку - еще на стадии компиляции.

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

oleg_2 в сообщении #1577494 писал(а):

И тогда ещё такой вопрос, фрагмент кода:

Используется синтаксис C

#define FB   9  /*кодовая длина быстрого декодирования (max 15)*/
#define FS  (1 << FB) /*число элементов массива быстрого декодирования*/

Здесь есть вычисление для инициализации макроса (1 << FB). У меня это работает, но соответствует ли это формально правилам языка Си?

Это все соответствует правилам языка Си. Но никакого "вычисления для инициализации макроса" тут нет. Макрос - это просто примитивная текстовая подстановка. Никаких "вычислений" определение макроса само по себе не вызывает.

Текст FS в программе будет трансформироваться в текст (1 << FB), а затем в текст (1 << 9). На этом роль макросов закончена. А уж какую роль это финальное (1 << 9) будет играть в окружающем контексте - "вычисление" это будет или что-то другое - зависит от окружающего контекста.

[oleg_2]

TheRuinedMap в сообщении #1577501 писал(а):

Это все соответствует правилам языка Си. Но никакого "вычисления для инициализации макроса" тут нет. Макрос - это просто примитивная текстовая подстановка.

Да, точно. Мог бы я и сам догадаться, но спросить-то надёжнее.

TheRuinedMap в сообщении #1577501 писал(а):

Нет, потому что в современных полномасштабных платформах (Windows, Linux и т.п.) программы запускаются в виртуальной памяти. То получают персональное полностью свободное, чистое как лист бумаги адресное пространство в свое распоряжение.

А значит ли это, что доступная программе память физически начинается с нуля? Там же шины, и на шинах, при обращении к памяти, напряжения должны быть на каждом проводе шины. Вот если бы были такие микросхемы с регистром, встраиваемые в разрыв шины, такие, что в регистр микросхемы менеджер процессора заносит значение адреса опорной точки программы, и микросхема суммирует адрес, выставленный программой, с опорным адресом в регистре. Чтобы как-то согласовать виртуальную и физическую память.

[zykov]

oleg_2 в сообщении #1577513 писал(а):

А значит ли это, что доступная программе память физически начинается с нуля?

Почитайте википедию про виртуальную память.
Про физическую память вам там вообще заботиться не надо. Механизм виртуальной памяти реализован аппаратно в процессоре. Процессор сам всё и делает, преобразует как надо виртуальные адреса в физические на лету, невидимо для вас.

[oleg_2]

zykov в сообщении #1577535 писал(а):

Почитайте википедию про виртуальную память.

Прочитал, вот цитата из википедии:

Цитата:

Виртуальный адрес при сегментной организации памяти может быть представлен парой (g, s), где g — номер сегмента, а s — смещение в сегменте. Физический адрес получается путём сложения начального физического адреса сегмента, найденного в таблице сегментов по номеру g, и смещения s.

Вот я примерно так и представлял, что не всё ОЗУ, а только сегмент или много сегментов выделяется процессу. Иначе что получается, ОЗУ большое, чего всё ОЗУ гонять туда-сюда, на диск и обратно в ОЗУ. Сегментами гонять по мере надобности.

zykov в сообщении #1577535 писал(а):

Механизм виртуальной памяти реализован аппаратно в процессоре.

Я выше написал про микросхему, преобразующую виртуальные адреса в физические. Так и получается, моя мысленная микросхема встроена в процессор, только посложнее.

Вот я смотрю у себя "Системный монитор",
Память 2,2 ГиБ из 3,7 ГиБ
Подкачка 102,1 МиБ из 3,9 ГиБ
Я так понимаю, что моё ОЗУ 3,7 ГиБ, а вот что такое 3,9 ГиБ я не знаю. Может на диске столько места выделено для подкачки. И зачем подкачка, если и так не всё ОЗУ задействовано?

-- 17.01.2023, 13:43 --

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

[warlock66613]

oleg_2 в сообщении #1577542 писал(а):

Вот я примерно так и представлял, что не всё ОЗУ, а только сегмент или много сегментов выделяется процессу.

Реально во всех основных операционных системах в норме все сегменты имеют нулевое смещение и размер, равный размеру адресного пространства ($2^{64}$ байт на 64-разрядных системах). Но это не значит что процессу выделяется всё ОЗУ. Виртуальная память вообще не имеет прямой связи с ОЗУ. Для процесса всё выглядит как будто он единолично запущен на машине с максимально возможным размером ОЗУ, но реально только некоторые части это пространства виртуальных адресов соответствуют каким-то участкам физической памяти в ОЗУ.

oleg_2 в сообщении #1577542 писал(а):

Сегментами гонять по мере надобности.

Сброс памяти на диск и подкачка обратно осуществляется постранично и страничная организация памяти никак не связана с сегментами. Сегменты в современном мире не используются.

[oleg_2]

warlock66613 в сообщении #1577545 писал(а):

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

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

warlock66613 в сообщении #1577545 писал(а):

Сегменты в современном мире не используются.

Понял. Я ведь ничего этого не знал, слыхал только, что когда ОЗУ не хватает, то подкачка с диска используется.