Обращение к разработчикам KolibriOS

No comments
  • alman
    Допустим нам необходимо найти строку в массиве из нескольких миллионов записей. Программа на ассемблере при этом честно сравнивает каждую строку, программа на Бейсике использует алгоритм хеширования. Не факт, что в этом споре победит ассемблер.
    А вот не надо ля-ля! Это уже соревнование алгоритмов, а не языков программирования! На ассемблере тоже можно реализовать хеширование, конечно, это потребует дополнительных человеко-часов или использования готовой библиотеки.
  • Mario79, перечитай два последних поста.
    > Однако, я верю в то, что быстродействие зависит прежде всего от алгоритма, затем от реализации и уже затем от языка программирования.

    p.s. alman, отличное описание проблемы, побольше бы таких ;-), а то самому лень, да и некогда разбираться.

    ..bw
  • Mario79 всё правильно сказал.

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

    Запомните раз и навсегда - оптимально написанная программа на ассемблере ВСЕГДА быстрее своих аналогов на языках высокого уровня(ЯВУ). А теперь подумайте, почему компиляторы ЯВУ неумеют думать также оптимально, как человек ассемблерщик.....
    KolibriOS-перспективная ос!
    Kolibri is best operation system in the world!
  • bw
    Я не оспаривал ту строку, которую ты привел. Я оспаривал сам пример как несоответствующий утверждению, что Бейсик может быть быстрей Ассемблера.
    Так как утверждалось о преимуществе языка при разных алгоритмах - а это уже неравноправное сравнение!
  • Ребята, я не говорил что Бейсик быстрее Ассемблера. Я сказал что в теории, я подчёркиваю - в теории, программа на Бейсике может быть быстрее программы на Ассемблере.

    Впрочем, не будем спорить - жизнь так коротка, чтобы проводить её в спорах.
  • на любом языке можно состряпать ТАКОЙ способ решения задачи, что умножение 2х2 будет идти годами....
    Кроме того, есть понятие "качество кода", когда один и тотже алгорим, на одном и том же языке но написанный разными людьми дает разные временные показатели (кто-то чуть умнее, кто-то чуть хитрее, а кто-то уже делал и вылизывал это...)
  • HORROR
    на любом языке можно состряпать ТАКОЙ способ решения задачи, что умножение 2х2 будет идти годами....
    Я слышал однажды от одних знакомых, что 2+2 через интегралы решается средним почерком на 2 страницы текста аж...
  • Вот и я о том же
  • Чего-то я туплю. Скачал сырцы FASM 1.67.23. Собрал его для Хамелеона. Проверяю - падает.
    Смотрю, где падает - в libc функции fputc. Ага, значит параметры функции передали неправильные.
    Смотрю код fasm/libc/system.inc -
    display_string:
    lodsb
    or al,al
    jz string_displayed
    mov dl,al
    call display_character
    jmp display_string
    string_displayed:
    ret
    display_character:
    movzx edx,dl
    ccall fputc,edx,[con_handle]
    ret
    Ага, в [con_handle] лежит единица. Ну да, понимаю, файловый дескриптор для stdout.
    Но не тут-то было. Делаем man fputc. (Можно и в MSDN посмотреть.)
    int fputc(inc c, FILE * stream);
    То есть должен передаваться не файловый дескриптор 1 (stdout), а указатель на структуру типа FILE.

    Ну, думаю, ошибка у меня. Делаю под Linux в точности как сказано в документации:
    gcc fasm.o -o fasm
    И запускаю полученный файл уже под Linux, который при запуске странным образом падает и под Линуксом.

    Может кто знает как исправить? Можно, конечно, заменить fputc на putc, но на большинстве POSIX систем putc реализован как макрос putc(c, stdout). Соответственно, fasm не соберётся.

    В принципе, можно заменить неправильный вызов fputc(c, 1) на правильный write(1, &c, 1), но интересно, как много таких мест в исходном коде fasm?
  • man stdio

    Code: Select all

         A file with associated buffering is  called  a  stream  (see
         intro(3))  and is declared to be a pointer to a defined type
         FILE. The fopen(3C)  function  creates  certain  descriptive
         data  for  a  stream  and returns a pointer to designate the
         stream in all  further  transactions.  Normally,  there  are
         three  open  streams  with constant pointers declared in the
         <stdio.h> header  and  associated  with  the  standard  open
         files:
    
         stdin standard input file
    
         stdout
               standard output file
    
         stderr
               standard error file
    
         The following symbolic values in <unistd.h> define the  file
         descriptors  that  will  be  associated  with the C-language
         stdin, stdout and stderr when the application is started:
    
         STDIN_FILENO     Standard input value    0     stdin
         STDOUT_FILENO    Standard output value   1     stdout
         STDERR_FILENO    Standard error value    2     stderr
    in code we trust
  • fputc по стандарту принимает в качетсве аргумента указатель на структуру данных типа FILE.

    Попробуйте запустить такой код:

    Code: Select all

    #include <stdio.h>
    int main()
    {
      fputc( '@', STDOUT_FILENO );
      return 0;
    }
    Он не скомпилится C++ компилятором, а если компилировать классическим C, то программа соберётся, но при запуске упадёт.
    А вот такая программа работать будет:

    Code: Select all

    #include <stdio.h>
    int main()
    {
      fputc( '@', stdout );
      return 0;
    }
    В случае fasm, используется первый вариант.
    Если не верите, загляните в /usr/include/stdio.h и посмотрите как определена структура FILE.

    Делов в том, что stdin, stdout и stderr создаются при инициализации библиотеки stdio. Причём, делается это довольно тупо. В стандарте POSIX первые три дескриптора у любого процесса указывают на стандартные устройства ввода, вывода и вывод ошибок.
    Выглядит это приблизительно так:
    #include <stdio.h>

    FILE * stdin;
    FILE * stdout;
    FILE * stderr;

    int initialize_stdio_library()
    {
    stdin = calloc( sizeof(FILE), 1 );
    stdout = calloc( sizeof(FILE), 1 );
    stderr = calloc( sizeof(FILE), 1 );
    stdin->file_descriptor = STDIN_FILENO;
    stdout->file_descriptor = STDOUT_FILENO;
    stderr->file_descriptor = STDERR_FILENO;
    /* и так дале */
    }
    Как говорится, почувствуйте разницу.
  • Вылечилось просто. Пришось заменить строку
    mov [con_handle], 1
    на
    mov ebx, stdout
    mov eax,[ebx]
    mov [con_handle], eax
    и, соответственно, добавить
    extrn stdout

    На удивление, всё остальное заработало сразу.
  • diamond wrote:Есть встречное предложение - использовать CRT на асме для программ Колибри (dosbox, скажем) (конечно, если оно в итоге заметно меньше, чем CRT на Си). Переработку menuetlibc при условии наличия большей части Си-библиотеки я могу обеспечить сам. Как было справедливо замечено, шансы на долгую память у кода и разработчика повышаются при использовании в двух ОСях.
    Похоже, меня проигнорировали...
    alman wrote:Коллеги, вчера реализовал поддержку исполняемых файлов формата MENUET/KOLIBRI в Xameleon.
    В результате мне удалось запустить распакованую программу TEST (прогу взял с диска Koilbri). Это значит, что программы, собранные FASM, могут запускаться на Xameleon.

    В результате, получил #General Protection fault на первом вызове Int 0x40. Впрочем, это совершенно нормальное поведение.
    В принципе, можно пойти двумя путями:
    1. Реализовать поддержку системных вызовов Kolibri в Xameleon.
    2. Написать DevKit на FASM, с поддержкой системных вызовов Xameleon.

    Можно использовать и оба пути.
    Это было завуалированное предложение написать эмулятор (или что-нибудь подобное) Колибри под Xameleon к разработчикам с этого форума? На данный момент нет даже эмулятора под Linux, а Linux - очень известная система, у которой в том числе и на этом форуме есть сторонники! (Кстати, там для эмуляции Колибри даже ядро модифицировать не надо.)
    Ушёл к умным, знающим и культурным людям.
  • diamond wrote:(Кстати, там для эмуляции Колибри даже ядро модифицировать не надо.)
    Вот тут подробней....что тогда для этого нужно?
    Насколько я помню там столкнулись с какой-то проблемой
  • Who is online

    Users browsing this forum: No registered users and 6 guests