Solid C - компилятор Си для Спринтера

[Vasil Ivanov]

Сейчас начал по-тиху смотреть библиотечные функции SOLID C, для их
прикрутки под Estex. У меня нет достаточного опыта программления
на Си (С++), поэтому хочу узнать мнение общественности.

1.
В некоторых библиотечных функциях рабочие ячейки (db,dw) из
области данных (dseg) я перенес прямо в код (cseg), чтобы функции
стали чуть быстрее отрабатывать. Но встает вопрос о невозможности
прошивки в ПЗУ си-программ, т.е. использующих си-шную библиотеку.
В принципе, для Спринтера писать программы для ПЗУ не актуально
(а си-шная библиотека под него и адаптируется).
Если на Си надо писать программы под Спектрум или другой комп, то
просто берется соотв. си-шная библиотека той платформы и при сборке
программы указывается линкеру. И прошивай программу куда хочешь .
Что народ думает по поводу стандартной си-шной библы Спринтера,
в этом плане ?.


2.
Какое максимальное число регистрируемых функций определить для
функции atexit() ?. По стандарту Си (по-крайней мере в MS-DOS)
это 32 функции. В SOLID C макс. число 19.
Я бы вообще оставил не более 8-ми (буфер списка будет 16 байт).
Куда больше-то, только место под список расходовать . Т.е. я
имею ввиду, что весь этот список будет входить в выходной exe-шник.

p.s. Кто не понял - речь идет о числе тех функций, которые будут
выполнены (после успешной отработки основной программы) перед самым
выходом в операционную систему.


3.
Поскольку в Estex нет переопределения потоков устройств, то как
определиться с си-шными stdin, stdout, sdterr, stdaux, stdprn ?,
которые соответственно имеют дескрипторы 0, 1, 2, 3 и 4.
В Estex эти номера ( кроме 0-го ; ) назначаются файлам.

У SOLID C в "stdio.h" следующее их описание:

Code: Select all

#define stdin   (&_iob[0])          /* standart input stream  */
#define stdout  (&_iob[1])          /* standart output stream */
#define stderr  (&_iob[2])          /* standart perror stream */

Т.е. как эти std... сопоставить с клавиатурой/экраном/экраном/... ?.
У меня пока с этим непонятки.

UPDATE: Solid C (сентябрь 2004) можно скачать отсюда:
http://nedopc.org/nedopc/sprinter/download/solidc.zip
Работа с DLL в Solid C (ноябрь 2004):
http://nedopc.org/nedopc/sprinter/download/sc_dll.zip
http://nedopc.org/nedopc/sprinter/download/libman13.zip

[cr0acker]

По поводу 3, введи свои нараюотки, которые МБР применить в своей ОС, и они станут стандартом

[Shaos]

1. Я думаю никому и в страшном сне не присниться писать программы для ПЗУ на Си - поэтому ориентируйся на ОЗУ
2. 8 будет в самый раз, тем более мало кто эту фичу испоьзует
3. Видимо надо сымитировать их - т.е. связать с клавой и дисплеем

[Vasil Ivanov]

1. Я думаю никому и в страшном сне не присниться писать программы для ПЗУ на Си - поэтому ориентируйся на ОЗУ
2. 8 будет в самый раз, тем более мало кто эту фичу испоьзует
3. Видимо надо сымитировать их - т.е. связать с клавой и дисплеем

1. Ok, заметано, вопрос считаем закрытым .

2. Оставлю 8.

3. Если ничего путного с имитацией не придумаю, то по-видимости
для Estex придется эти стандартные "std.." убрать и в Си они будут
уже не доступны ;(. Эта "фитча" будет обращать на себя внимание
только при портации си-сорцев с других платформ, не более того.
Думаю, ситуацию здесь спасет только прикрутка "std.." в самой ОС-и,
а в Си ничего путного не получится.
P.S. Эта проблема относится только для DSS, а не к самому SOLID C.


P.S.S. Вчера немного поправил твой LIBMAN для DLL-ек. Теперь он нормально работает с библами, у которых таблица перемещений
идет сразу за "своим" кодом (т.е. в начале рел-таблицы не требуется
4 нулевых байта (32 бита, для прохода dll-заголовка)). Этот формат обозвал как "L1". Его будет (уже выдает) выдавать линкер от SOLID C.
LIBMAN теперь версии 1.3. Надеюсь ты не против? .
Все это пойдет в пакете SOLID C. Как только прикручу i/o функции,
работу с памятью и доки по пакету, так выпущу SOLID C в мир .
p.s. Но по работе с памятью будут еще вопросы.

[Shaos]

P.S.S. Вчера немного поправил твой LIBMAN для DLL-ек. Теперь он нормально работает с библами, у которых таблица перемещений
идет сразу за "своим" кодом (т.е. в начале рел-таблицы не требуется
4 нулевых байта (32 бита, для прохода dll-заголовка)). Этот формат обозвал как "L1". Его будет (уже выдает) выдавать линкер от SOLID C.
LIBMAN теперь версии 1.3. Надеюсь ты не против?

Подробности изменений хочу - с кусками кода и т.д.
Ты уверен, что ничего не съехало?

[Vasil Ivanov]

P.S.S. Вчера немного поправил твой LIBMAN для DLL-ек. Теперь он нормально работает с библами, у которых таблица перемещений
идет сразу за "своим" кодом (т.е. в начале рел-таблицы не требуется
4 нулевых байта (32 бита, для прохода dll-заголовка)). Этот формат обозвал как "L1". Его будет (уже выдает) выдавать линкер от SOLID C.
LIBMAN теперь версии 1.3. Надеюсь ты не против?

Подробности изменений хочу - с кусками кода и т.д.
Ты уверен, что ничего не съехало?

Нет проблем. Я тебе сейчас архивчик брошу, в нем все будет.
Архив брошу тебе на e-mail: shaos@mail.ru
P.S. Фактически все изменения LIBMAN-а - это прибавка 32 байт (размер
заголовка) к началу корректируемого кода, для формата L1. Вот и все.
Да еще малька соптимизил код менеджера - сейчас он на 48 байт короче оригинала.
Грузил им твою тестовую библиотечку (упакованную, не упакованную),
созданную mk_dll.exe и эту же библиотеку, скомпиленную моим линкером. Все грузилось без проблем.

[cr0acker]

Вася сделал это! Правда я ничего скомпилировать им не могу:( Линкер виснет:(
Всем качать!:

Solid C

UPDATE: 26 ноября 2005 года Shaos перенаправил линк на nedopc.org

[CHRV]

Вася сделал это!

Крутейшей респект Васе!
Это вам не игрушки у КодеМастерсов тырить
Скачено, посмотрю как нить на досуге!

[Vasil Ivanov]

Вася сделал это!

Крутейшей респект Васе!
Это вам не игрушки у КодеМастерсов тырить
Скачено, посмотрю как нить на досуге!

Пасиба мужики на добром слове !

Если будут глюки, плиз описывайте что собираете и какую командную
строку пишите. Т.е. чтобы я мог повторить ситуацию у себя.

P.S. На счет линкера - может собирать файлы максимум 64 кило весом.

[Vasil Ivanov]

Вася сделал это! Правда я ничего скомпилировать им не могу:( Линкер виснет:(
Всем качать!

Володя, бросил тебе сейчас по-фиксенный линкер. Так что забирайте
с Нюка. Теперь его версия v0.02b. Глюк был в процедуре вызова
рестарта DOS-а (неверное положение стека). Самое интересное, что
на электронном диске (тестил на нем линкер) все работало нормально.

[Shaos]

Напомни какие файлы надо переводить на английский в первую очередь?

[Vasil Ivanov]

Напомни какие файлы надо переводить на английский в первую очередь?

readme.rus - первое, что надо перевести. Здесь особенности
пакета, портированного на Спринтер.

bugs.! - он совсем маленький

cc.rus - дока по си-компилятору.

devel-1.rus - некоторая инфа по сборке проги из нескольких
исходников.

devel-2.rus - создание своих библиотек (irl-формата),
для юзания с линкером ld.exe.

ld.rus - дока линкера.

ol.rus - дока библиотекаря.

whatsnew.rus - история версий программ пакета.

Очень не помешала бы дока по си-функциям (clib.rus) данного
пакета, потому, что в некоторых функциях встречаются отличия
от стандартных (PC-шных), например функции перемещения
указателя в файле. Но она объемистая.
Да я фактически все доки и перечислил . По .rel/.irl
форматам и по асму, уже есть англицкий вариант.
Вобщем все доки, кроме cc.rus и clib.rus ты переведешь за
час, а может и быстрей .

[Shaos]

readme.rus - первое, что надо перевести. Здесь особенности пакета, портированного на Спринтер.

Черновичок перевода:
viewtopic.php?t=7580

Поместил в английском форуме про спринтер, так что по русски там не выражаться!

Очень не помешала бы дока по си-функциям (clib.rus) данного
пакета, потому, что в некоторых функциях встречаются отличия
от стандартных (PC-шных), например функции перемещения
указателя в файле. Но она объемистая.

Предлагаю вместо этого осветить только отличные функции,
т.к. си есть си - кто знает, тот в курсе

Да я фактически все доки и перечислил . По .rel/.irl
форматам и по асму, уже есть англицкий вариант.
Вобщем все доки, кроме cc.rus и clib.rus ты переведешь за
час, а может и быстрей .

.irl по английски не нашел

за час не получится - за час даже просто прочитать не получится, не то что написать

[Shaos]

Кое что непонятно:

Code: Select all

#include <stdio.h>

char buffer[4]="AAA";
//char buffer[4]={'A','A','A','A'};

void main()
{
    printf("0x%02X\n", *buffer);		// (1) не правильно!
    printf("0x%02X\n", (char *) *buffer);	// (2) правильно
}

Если массив buffer представляет собой char-элементы, то при обращении к нему,
как показано в строке (1), компилятор сгенерирует не тот код, что нам нужно.
При этом, никакой ошибки выдано не будет. Для того, чтобы компилятор сгенери-
ровал правильный код, к отдельному элементу char-массива нужно обращаться так,
как это сделано в строке (2), принудительно указав компилятору через cast-
операцию то, что нам нужно.
При обращении к массиву, состоящему из int-элементов, вышеописанных проблем
не возникает, компилятор генерирует правильный код.
Для более наглядного представления, о чем идет речь, можно просмотреть asm-
листинг, генерируемый компилятором для приведенного выше примера. Для строки
(1) компилятор не сгенерирует код "ld b,0".

Как я понимаю вместо
printf("0x%02X\n", (char *) *buffer);
надо писать
printf("0x%02X\n", (char) *buffer);
иначе ерунда какая-то получается

[Shaos]

Еще неувязочка:

Code: Select all

   7. Имеется отличие от стандартного языка Си по эффективным пределам имен
членов структур и объединений (struct & union). В стандартном Си одно и то же
имя члена может появляться в двух различных структурах только в случае, когда
они оба одного типа и имеют одинаковое смещение в обеих структурах. Компилятор
SOLID C воспринимает имя члена так, как принято в Паскале или в Аде. Таким об-
разом, одно и то же имя члена может появляться в разных структурах и будет
правильно обработано компилятором SOLID C.
В качестве примера рассмотрим следующее описание:

struct node {
        char *word;
        int count;
        struct node *next;
} pool[1000], *p;

struct noad {
        int atr;
        struct noad *next;
} table[10], *q;

   В стандартном языке Си данная запись является неправильной, потому, что имя
члена "next" появляется в двух структурах - "node" и "noad", где их типы и сме-
щения не согласованы. Однако в среде компилятора SOLID C эти записи являются
правильными.
   Следует обратить внимание на следующую запись

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