Изучает ли сдесь кто-нибудь язык Си?

Стандарт - понятие условное для языка, которому более 40 лет, и который несмотря на возраст, актуален.

код выделить все

static volatile unsigned char GPIO @ 0x05;

...

static volatile bit GPIO0 @ (unsigned)&GPIO*8+0;
static volatile bit GPIO1 @ (unsigned)&GPIO*8+1;
static volatile bit GPIO2 @ (unsigned)&GPIO*8+2;
static volatile bit GPIO3 @ (unsigned)&GPIO*8+3;


Да, для того и существуют компиляторы языков высокого уровня под разные платформы. Но это вовсе не означает нарушение чистоты языка. Это всего-лишь среда разработки, в рамках которых программист может писать на чистом СИ, а компилятор генерирует машинный код. Как именно он это делает? Что-то доступно для изучения (благодаря использованию расширений стандарта), что-то совсем скрыто (в .exe-файлах компилятора). Я предпочитаю сам писать все библиотеки, чтобы сделать то что мне надо максимально понятным, эффективным, и избежать подключения ненужных функций.

Сергей1734:

Korben_Dallas:

Что скрывается за макросами `GPIO` и т.п.? "Чистый Си"? Нет, конечно. За ним скрывается платфторменно-зависимый хак - приведение целочисленного значения (адреса регистра) к указательному типу. А это уже семантически выходит за пределы "чистого Си".

Это стандартная директива компилятора СИ - #define, а не какой не "хак".

Что за чушь вы несете? О `#define` тут никто не говорит. Речь идет именно о макроподстановке, которая скрывается за этим `#define`. Которая на "чистом Си" написана быть никак не может.

Сергей1734:

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

Во первых, препроцессор. Во-вторых, вы, я вижу, просто не врубаетесь, о чем идет речь.

Сергей1734:

Korben_Dallas:

А далее идут библиотечные вызовы типа `lcd_init`, т.е. то, о чем и говорилось выше. Т.е. для общения с устройством вы используете HAL, который внутри, разумеется, рано или поздно выйдет за пределы "чистого Си".

Здесь Вы строите лишь предположения без оснований.

Нет, здесь я констатирую жесткие факты, с очевидными на то основаниями.

Сергей1734:

Реальность же такова: библиотечные вызовы - это просто подпрограммы на том же чистом СИ, которые просто оформлены отдельно (для облегчения читабельности исходника).

Нет, конечно. Все эти подпрограммы написаны с использованием абсолютно тех же самых "хаков", которые скрывались за вашими первыми `#define`.

Сергей1734:

P.S. Korben_Dallas, Вы тролль?

Нет. Я один из авторов языка Си. На вашем зачаточном уровне знания языка language-lawyer моего уровня действительно может показаться вам "троллем". Это нормально. Но по мере того как вы будете продвигаться в своем развитии (если будете) вам постепенно все будет становиться яснее.

Сергей1734:

код выделить все

static volatile unsigned char GPIO @ 0x05;
...

static volatile bit GPIO0 @ (unsigned)&GPIO*8+0;
static volatile bit GPIO1 @ (unsigned)&GPIO*8+1;
static volatile bit GPIO2 @ (unsigned)&GPIO*8+2;
static volatile bit GPIO3 @ (unsigned)&GPIO*8+3;


Вот это все - уже разухабистый выход за пределы языка С. Ничего подобного в С нет.

gooblin:

Korben_Dallas, там объявление переменной по абсолютному адресу, используя директивы языка, не входящие в стандарт.

//==============================================================================
// GPIO Bits

extern __at(0x0005) __sfr GPIO;

О чем и речь.

Сергей1734:

Стандарт - понятие условное для языка, которому более 40 лет, и который несмотря на возраст, актуален.

Нет, конечно. Актуальность языков С и С++ обуславливается именно и только стандартизацией этих языков и тем фактом, что стандартизация этих языков является в большой степени независимой от конкретных проприетарных владельцев.

И никакой "условности" тут нет. (Что за чушь?) Есть жесткая обязательность: программирование на С и С++ всегда делается по стандартам этих языков, отклонение от которых, разумеется, допускается только при наличии обоснованной необходимости (как в вашем примере). Зубрить стандарт наизусть вас никто не заставляет, но работать с документом вы должны уметь свободно. Без этого вас не только никто и близко не подпустит к программированию на С, но даже упоминать названия этих языков в разговоре вы не будете.

Отдельно стоит заметить, что вы сначала рассказывали нам про "чистый Си". Термин "чистый Си" означает именно и только строго стандартный С. А тут, я смотрю, после разглагольствований о "чистом Си" ни с того ни и сего пошло вдруг верчение пятой точкой на тему "условности стандарта"

gooblin:

Korben_Dallas:

Нет. Я один из авторов языка Си.

Вы наверно хотели сказать что входите в состав рабочей группы по стандартизации языка?

Именно так. Входил в течение доброго десятка лет, но не в данный момент, правда. Мой нынешний работодатель не спонсирует.

gooblin:

А то я тоже буду гордо говорить что я автор POSIX.

Подчеркну: не "автор", а "один из авторов". А так - говорите

gooblin:

Korben_Dallas:

Мой нынешний работодатель не спонсирует.

А предыдущий спонсировал? Включая авиабилеты туда/обратно, командировочные и проживание в гостинице?
Простите за любопытство, просто интересно.

Под спонсированием я имею в виду не спонсирование меня, а спонсирование самой рабочей группы/ANSI.

Что же касается меня, то я в Калифорнии живу. В "удаленном" собрании участвовал только один раз и то по оказии, а в остальных случаях - только локально.

Сергей1734:

Изначально СИ создавался для портирования операционной системы UNIX (написанной на ассемблере) с ЭВМ PDP-7 на другие ЭВМ.

Тот язык, который создавался изначально "для портирования операционной системы UNIX", можно увидеть в "C Reference Manual" Дениса Ритчи вот здесь - https://www.bell-labs.com/usr/dmr/www/cman.pdf. Тот язык был действительно был неким "портабельным ассемблером" и сильно отличался даже от K&R С и в области синтаксиса, и в области семантики. Это был сильно другой язык. Его хвосты до сих пор торчат в старых Unix-овских хедерах.

Сергей1734:

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

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

В этом нет ничего плохого.

Сергей1734:

Ибо на нём типичный СИ-программист не пишет.

Это утверждение примерно эквивалентно утверждению "типичный СИ-программист толком языка не знает, и посему даже и не ведает, что творит". Это может быть справедливо только для студентов.

Сергей1734:

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

Во-первых, никто тут ни за что не переживает. Я просто обратил внимание на странное утверждение об управлении микроконтроллером на "чистом Си".
Во-вторых, боюсь, что утверждения о "давновыполненности" миссии Си малость преувеличены ))

Сергей1734:

Директивы компилятора имеют отношение к языку СИ примерно такое же[...]

Я не понял, что именно вы хотели сказать. Но на всякий случай спрошу: что именно вы имеете в виду под "директивами компилятора"?

Ну таки да, директивы обычно начинаются с символа # и служат для управления компиляцией.
Но конструкции со знаком @ разве не делают тоже самое? Компилятор видит @, и даёт возможность разместить переменную по физическому адресу. Разве это имеет прямое отношение к языку? Ведь алгоритм программы не меняется в зависимости от привязки имени переменной к конкретному оборудованию.

Сергей1734, алгоритм не меняется, однако меняется переносимось программы (возможность быть скомпилированной без изменений и выполненной с тем же результатом) на другое железо (архитектуру процессора) или другой компилятор или другую операционную систему. Но в вашем случае это не важно - для embedded так все делают, расширяя синтаксис языка под конкретное железо. Это нормально, переносимось для embedded программ не имеет значения и в расчет не берется. Поскольку вероятность того что в другом микропроцессоре по адресу 0x5 будет находится регистр GPIO, с таким же назначением всех его бит, равна нулю.

Для прикладных программ, написанных на C, переносимость важна. Я например, если надо написать на C какую-то утилиту командной строки, стараюсь написать ее так, чтобы не использовать кучу #ifdef-ов для различных платформ. Т.е. мой исходный код будет одинаково компилироваться и работать например и под Windows и по Linux без изменений. Конечно если для моей программы достаточно только стандартной библиотеки яыка C.

Сергей1734, оригинальный исходный код far manager завязан на WinAPI - системные вызовы Windows. В Линуксе их нет, там используются другие системные функции. На обоих операционках эти системные вызовы не входят в стандартную библиотеку языка C - поэтому при портировании win на lin надо было перепахать весь код.

А почему 10 лет портировали? По мне так две причины:
1. С самого начала, когда FAR писали под винду, разработчики не предусмотрели портирование на другие платформы. Обычно весь платформозависимый код прячется за набором процедур, являющимся "прослойкой" между системными вызовами операционной системы и остальной частью программы (ее основным функционалом). И тогда при портировании на новую платформу требуется переписать (добавить) только прослойку для новой операционнной системы. Когда Фар писали под винду - этого никто не сделал. Разработчики же сами написали по вашей ссылке - был разработан платформо-независимый API - это и есть прослойка про которую я говорил.
2. Вторая причина - писали фанаты Фара в свободное от зарабатывания денег время. А свободного от работы времени не так много. Если бы писали за бабки - то было бы очень быстро.