А не мог бы кто поподробнее рассказать как работает передача параметров в программу (те которые _params в macros.inc)? передаётся строка символов включая пробелы или передаётся ссылка на массив строк или как то иначе? Если где-то есть подробное описание прошу извинить меня и дать ссылку .

Alexus wrote:А не мог бы кто поподробнее рассказать как работает передача параметров в программу (те которые _params в macros.inc)?

Параметры передаются как одна ASCIIZ-строка длиной не более 256 (не считая завершающего нуля). Описано это в документации на функцию запуска программы 70.7.

Alexus wrote:KCC v.0.02
Недостатки(крупные навскидку):
1. Нет libc
2. Нет обёрток API ядра
3. Нет удобной обработки переданных параметров

На самом деле libc существует хотя она далеко не полная (например нет assert), и реализована кривоато. Там-же и обертки для ядра, вплоть до поднятия окон и т.п. Все это "барахло" лежит в SVN вместе с ОС.

Основная лажа klibc - __stdcall (pascal) т.е. параметры сначала передаются в стек, а потом уже ручками в регистры после чего вызывается прерывание - "системный вызов". Это полный ПЭ, потому что нужен-то cdecl и __fascall согласно ISO C99.

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

Момент третий, G++ голый т.е. libstdc++ (в мс это crt) отсутствует т.е. фактически на С++ писать программы по KOS не реально.

Собственно процесс пошел наконец-то. Предлагаю создать полный пакет binutils и получить рабочий gcc наконец.

diamond wrote:

Alexus wrote:А не мог бы кто поподробнее рассказать как работает передача параметров в программу (те которые _params в macros.inc)?

Параметры передаются как одна ASCIIZ-строка длиной не более 256 (не считая завершающего нуля). Описано это в документации на функцию запуска программы 70.7.

А можно в некотором новом релизе ядра выделить байта 4 на строку?

SHREDER wrote: А можно в некотором новом релизе ядра выделить байта 4 на строку?

Этот как? Подробнее можно описать?

SHREDER wrote:т.е. фактически на С++ писать программы по KOS не реально.

Таким образом, порта dosbox не существует.

SHREDER wrote:Второй момент линковка. Ld вообще-то может собирать не только elf но и все что угодно. Только для этого ему нужно подсунуть специальный скрипт, указывающий формат бинарника . Такого скрипта в общем доступе нет

Есть. Собственно, заглавный пост этой темы - ссылка на статью, в которой такой скрипт упомянут.

Mario wrote:Подробнее можно описать?

Угу, я тоже не понял.

SHREDER wrote:

Alexus wrote:KCC v.0.02
Недостатки(крупные навскидку):
1. Нет libc
2. Нет обёрток API ядра
3. Нет удобной обработки переданных параметров

На самом деле libc существует хотя она далеко не полная (например нет assert), и реализована кривоато. Там-же и обертки для ядра, вплоть до поднятия окон и т.п. Все это "барахло" лежит в SVN вместе с ОС.

Основная лажа klibc - __stdcall (pascal) т.е. параметры сначала передаются в стек, а потом уже ручками в регистры после чего вызывается прерывание - "системный вызов". Это полный ПЭ, потому что нужен-то cdecl и __fascall согласно ISO C99.

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

Момент третий, G++ голый т.е. libstdc++ (в мс это crt) отсутствует т.е. фактически на С++ писать программы по KOS не реально.

Собственно процесс пошел наконец-то. Предлагаю создать полный пакет binutils и получить рабочий gcc наконец.

Мне кажется или это было не про kcc? =) у меня libc точно нет, тк пока бессмысленно её писать по нескольким причинам:
1) нет механизма передачи параметров через argv[ ], argc (сейчас именно этим и занимаюсь)
2) нет механизма создания динамических библиотек и их подключения (3й пункт для выпуска 0.03)

Я делаю это всё в 1ую очередь для себя тк хочу иметь свой привычный инструмент, сейчас я медленно нарабатываю базу заодно изучая как работает gcc\g++ , синтаксисы Intel и AT&T. К версии 0.4 - 0.5 наработав базу определённую уже буду пытаться писать libc( заодно разберусь что да как там и как работает =) ) и приводить в соответствие флаги.

Возможно меня по ошибке процитировали, но я решил высказать по поводу этого недоразумения , и да если и есть наработки libc мне они не особо подходят тк они в Intel синтаксисе, а мне нужно в AT&T , хотя как пример на них можно смотреть.

P.S. если я чего не понял, прошу извинить

Скрипт для LD под Mingw32. Собираем с ключами -static -nostdlib --stack сколько_стека_в_байтах

extern char __cmdline[]; и extern char __pgmname[]; дают доступ к командной строке и полному пути.
и примерный crt0.c

argv[ ], argc? Как это мешает libc в упор не пойму. И вообще кто сказал что
int main(int argc,const char **argv) единственно возможная декларация main?

Ну а с синтаксисом ассемблера "на вкус и цвет" как говорится. По моему глубочайшему ИМХО intel намного более прост. Если охота посмотреть на libc под GAS то смотри суда http://sourceforge.net/projects/menuetlibc/

Serge wrote:Скрипт для LD под Mingw32. Собираем с ключами -static -nostdlib --stack сколько_стека_в_байтах

extern char __cmdline[]; и extern char __pgmname[]; дают доступ к командной строке и полному пути.

Code: Select all

ENTRY(___crt_startup)
SECTIONS
{
    .text 0x000000:
    {
        LONG(0x554e454D);
        LONG(0x32305445);
        LONG(1);
        LONG(___crt_startup);
        LONG(___iend);
        LONG(___memsize);
        LONG(___stacktop);
        LONG(___cmdline);
        LONG(___pgmname);     	/*  application path    */
        LONG(0)                            /*  tls info		       */

        *(.init)
        *(.text)
        *(SORT(.text$*))
        *(.rdata)
        *(SORT(.rdata$*))
        *(.glue_7t)
        *(.glue_7)
        ___CTOR_LIST__ = .; __CTOR_LIST__ = .;
			LONG (-1); *(SORT(.ctors.*)); *(.ctors); *(.ctor); LONG (0);
        ___DTOR_LIST__ = .; __DTOR_LIST__ = .;
			LONG (-1); *(SORT(.dtors.*)); *(.dtors); *(.dtor);  LONG (0);
    }

    .CRT ALIGN(16) :
    {
        ___crt_xc_start__ = . ;
        *(SORT(.CRT$XC*))  /* C initialization */
        ___crt_xc_end__ = . ;
        ___crt_xi_start__ = . ;
        *(SORT(.CRT$XI*))  /* C++ initialization */
        ___crt_xi_end__ = . ;
        ___crt_xl_start__ = . ;
        *(SORT(.CRT$XL*))  /* TLS callbacks */
      /* ___crt_xl_end__ is defined in the TLS Directory support code */
        ___crt_xp_start__ = . ;
        *(SORT(.CRT$XP*))  /* Pre-termination */
        ___crt_xp_end__ = . ;
        ___crt_xt_start__ = . ;
        *(SORT(.CRT$XT*))  /* Termination */
        ___crt_xt_end__ = . ;
    }

  .data ALIGN(16) :
  {
     *(.data)
      . = ALIGN(16);	
     ___iend = . ;
   }

  .bss ALIGN(4096):
   {
      *(.bss)
      *(COMMON)
      . = ALIGN(16);
      ___cmdline = .;
      . = . + 256;
      ___pgmname = .;
      . = . + 1024 + __size_of_stack_reserve__ ; /* --stack RESERVE */
      ___stacktop = .;
   }
   ___memsize = . ;
}

и примерный crt0.c

Code: Select all

void   _exit(int __status) __attribute__((noreturn));

extern char __cmdline[];
extern char __pgmname[]

void  __attribute__((noreturn))
__crt_startup (void)
{
    char *argv[2];
    int  argc;

    __asm__ __volatile__(
    "int $0x40"
    :"=eax"(nRet)
    :"a"(68),"b"(11));

    argv[0] = __pgmname;

    if( __cmdline[0] != 0)
    {
        argc = 2;
        argv[1] = __cmdline;
    } else argc = 1;

    _exit( main (argc, argv, NULL));
};

void _exit(int __status)
{
    while(1){
        __asm__ __volatile__(
        "int $0x40"
        ::"a"(-1));
    };
}

Пасиб, хотя и поздновато немного.

SHREDER wrote:argv[ ], argc? Как это мешает libc в упор не пойму. И вообще кто сказал что
int main(int argc,const char **argv) единственно возможная декларация main?

Ну а с синтаксисом ассемблера "на вкус и цвет" как говорится. По моему глубочайшему ИМХО intel намного более прост. Если охота посмотреть на libc под GAS то смотри суда http://sourceforge.net/projects/menuetlibc/

Это объявление является классическим, поэтому ориентируюсь я на него.
Ассемблер у меня не на вкус и цвет, а по той причине что встроенный(inline) ассемблер в gcc\g++ имеет AT&T синтаксис...

Обновилась menuetlibc по адресу http://diamond.kolibrios.org/menuetlibc.7z. В новой версии: разные багфиксы; в рамках интеграции с другими изменениями (судя по changelog'у, их автором был vectoroc) главная функция приложения переименована из app_main в main; некоторые примитивные вещи из stl (типа std::vector<std::string> с минимальной функциональностью, достаточной для компиляции dosbox'а); улучшена совместимость с gcc4, с 64-битными системами, кроме того, заголовочные файлы нормально понимает VC.
P.S. Для ярых любителей linux сообщаю, что версия тестировалась, помимо mingw и cygwin, на паре разных линухов, один был 32-битным, другой 64-битным.

diamond wrote:заголовочные файлы нормально понимает VC.

Если интеграция с VC возможна, не поясните как?

staper
А в чём проблема? VC нормально понимает библиотеки, сгенерированные gcc.