Board.KolibriOS.org

Официальный форум KolibriOS
Текущее время: Пн дек 11, 2017 6:17 pm

Часовой пояс: UTC+03:00




Начать новую тему  Ответить на тему  [ 44 сообщения ]  На страницу Пред. 1 2 3 След.
Автор Сообщение
СообщениеДобавлено: Сб окт 06, 2007 4:01 pm 
Mario79 писал(а):
Ты хочешь доказать, что эмуляция приложений Колибри для твоего ядра будет быстрей, чем работа приложения в самой Колибри с использованием программного прерывания?


Вряд-ли эмуляция будет быстрей. Всё-ж таки эмуляция. Тем более что при эмуляции всё равно будет использоваться Int, да плюс overhead на его обработку.

Mario79 писал(а):
Тогда что ты возразишь насчет использования FAST CALL, которое уже реализовано для Колибри?
Чего-то я не верю, что микроядро обеспечит более быструю работу приложений...


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

Однако, я верю в то, что быстродействие зависит прежде всего от алгоритма, затем от реализации и уже затем от языка программирования. Приведу гипотетический пример, когда программа на Бейсике может оказаться быстрее программы на ассемблере:

Допустим нам необходимо найти строку в массиве из нескольких миллионов записей. Программа на ассемблере при этом честно сравнивает каждую строку, программа на Бейсике использует алгоритм хеширования. Не факт, что в этом споре победит ассемблер. :)


Вернуться к началу
   
СообщениеДобавлено: Сб окт 06, 2007 4:40 pm 
alman
Цитата:
Допустим нам необходимо найти строку в массиве из нескольких миллионов записей. Программа на ассемблере при этом честно сравнивает каждую строку, программа на Бейсике использует алгоритм хеширования. Не факт, что в этом споре победит ассемблер.

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


Вернуться к началу
   
СообщениеДобавлено: Сб окт 06, 2007 4:51 pm 
Не в сети
Аватара пользователя

Зарегистрирован: Чт мар 01, 2007 4:16 pm
Сообщения: 426
Mario79, перечитай два последних поста.
> Однако, я верю в то, что быстродействие зависит прежде всего от алгоритма, затем от реализации и уже затем от языка программирования.

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

..bw


Вернуться к началу
СообщениеДобавлено: Сб окт 06, 2007 5:29 pm 
Не в сети
Аватара пользователя

Зарегистрирован: Чт май 19, 2005 4:43 pm
Сообщения: 896
Mario79 всё правильно сказал.

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

Запомните раз и навсегда - оптимально написанная программа на ассемблере ВСЕГДА быстрее своих аналогов на языках высокого уровня(ЯВУ). А теперь подумайте, почему компиляторы ЯВУ неумеют думать также оптимально, как человек ассемблерщик.....

_________________
KolibriOS-перспективная ос!
Kolibri is best operation system in the world!


Вернуться к началу
СообщениеДобавлено: Сб окт 06, 2007 5:49 pm 
bw
Я не оспаривал ту строку, которую ты привел. Я оспаривал сам пример как несоответствующий утверждению, что Бейсик может быть быстрей Ассемблера.
Так как утверждалось о преимуществе языка при разных алгоритмах - а это уже неравноправное сравнение!


Вернуться к началу
   
СообщениеДобавлено: Сб окт 06, 2007 7:35 pm 
Ребята, я не говорил что Бейсик быстрее Ассемблера. Я сказал что в теории, я подчёркиваю - в теории, программа на Бейсике может быть быстрее программы на Ассемблере.

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


Вернуться к началу
   
СообщениеДобавлено: Вс окт 07, 2007 11:01 am 
на любом языке можно состряпать ТАКОЙ способ решения задачи, что умножение 2х2 будет идти годами....
Кроме того, есть понятие "качество кода", когда один и тотже алгорим, на одном и том же языке но написанный разными людьми дает разные временные показатели (кто-то чуть умнее, кто-то чуть хитрее, а кто-то уже делал и вылизывал это...)


Вернуться к началу
   
СообщениеДобавлено: Вс окт 07, 2007 11:22 am 
HORROR
Цитата:
на любом языке можно состряпать ТАКОЙ способ решения задачи, что умножение 2х2 будет идти годами....

Я слышал однажды от одних знакомых, что 2+2 через интегралы решается средним почерком на 2 страницы текста аж...


Вернуться к началу
   
СообщениеДобавлено: Вс окт 07, 2007 12:27 pm 
Вот и я о том же


Вернуться к началу
   
СообщениеДобавлено: Вс окт 07, 2007 7:36 pm 
Чего-то я туплю. Скачал сырцы 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?


Вернуться к началу
   
СообщениеДобавлено: Вс окт 07, 2007 8:16 pm 
Не в сети
Site Founder
Аватара пользователя

Зарегистрирован: Вс авг 08, 2004 8:55 am
Сообщения: 689
man stdio
Код:
     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


Вернуться к началу
СообщениеДобавлено: Вс окт 07, 2007 8:48 pm 
fputc по стандарту принимает в качетсве аргумента указатель на структуру данных типа FILE.

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

Код:
#include <stdio.h>
int main()
{
  fputc( '@', STDOUT_FILENO );
  return 0;
}


Он не скомпилится C++ компилятором, а если компилировать классическим C, то программа соберётся, но при запуске упадёт.
А вот такая программа работать будет:

Код:
#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;
/* и так дале */
}


Как говорится, почувствуйте разницу.


Вернуться к началу
   
СообщениеДобавлено: Пн окт 08, 2007 1:12 pm 
Вылечилось просто. Пришось заменить строку
Цитата:
mov [con_handle], 1

на
Цитата:
mov ebx, stdout
mov eax,[ebx]
mov [con_handle], eax

и, соответственно, добавить
extrn stdout

На удивление, всё остальное заработало сразу.


Вернуться к началу
   
СообщениеДобавлено: Пн окт 08, 2007 7:49 pm 
Не в сети
Kernel Developer
Аватара пользователя

Зарегистрирован: Пн ноя 28, 2005 8:00 pm
Сообщения: 1601
diamond писал(а):
Есть встречное предложение - использовать CRT на асме для программ Колибри (dosbox, скажем) (конечно, если оно в итоге заметно меньше, чем CRT на Си). Переработку menuetlibc при условии наличия большей части Си-библиотеки я могу обеспечить сам. Как было справедливо замечено, шансы на долгую память у кода и разработчика повышаются при использовании в двух ОСях.

Похоже, меня проигнорировали...
alman писал(а):
Коллеги, вчера реализовал поддержку исполняемых файлов формата MENUET/KOLIBRI в Xameleon.
В результате мне удалось запустить распакованую программу TEST (прогу взял с диска Koilbri). Это значит, что программы, собранные FASM, могут запускаться на Xameleon.

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

Можно использовать и оба пути.

Это было завуалированное предложение написать эмулятор (или что-нибудь подобное) Колибри под Xameleon к разработчикам с этого форума? На данный момент нет даже эмулятора под Linux, а Linux - очень известная система, у которой в том числе и на этом форуме есть сторонники! (Кстати, там для эмуляции Колибри даже ядро модифицировать не надо.)

_________________
Ушёл к умным, знающим и культурным людям.


Вернуться к началу
СообщениеДобавлено: Пн окт 08, 2007 8:20 pm 
Не в сети

Зарегистрирован: Ср фев 21, 2007 3:03 pm
Сообщения: 188
diamond писал(а):
(Кстати, там для эмуляции Колибри даже ядро модифицировать не надо.)


Вот тут подробней....что тогда для этого нужно?
Насколько я помню там столкнулись с какой-то проблемой


Вернуться к началу
Показать сообщения за:  Поле сортировки  
Начать новую тему  Ответить на тему  [ 44 сообщения ]  На страницу Пред. 1 2 3 След.

Часовой пояс: UTC+03:00


Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и 1 гость


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Найти:
Перейти:  
cron
Создано на основе phpBB® Forum Software © phpBB Limited
Русская поддержка phpBB