Board.KolibriOS.org

Official KolibriOS board
It is currently Thu Sep 19, 2019 2:21 pm

All times are UTC+03:00




Post new topic  Reply to topic  [ 44 posts ]  Go to page Previous 1 2 3 Next
Author Message
PostPosted: Sat Oct 06, 2007 4:01 pm 
Mario79 wrote:
Ты хочешь доказать, что эмуляция приложений Колибри для твоего ядра будет быстрей, чем работа приложения в самой Колибри с использованием программного прерывания?


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

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


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

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

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


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

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


Top
   
PostPosted: Sat Oct 06, 2007 4:51 pm 
Offline
User avatar

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

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

..bw


Top
   
PostPosted: Sat Oct 06, 2007 5:29 pm 
Offline
User avatar

Joined: Thu May 19, 2005 4:43 pm
Posts: 896
Mario79 всё правильно сказал.

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

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

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


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


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

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


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


Top
   
PostPosted: Sun Oct 07, 2007 11:22 am 
HORROR
Quote:
на любом языке можно состряпать ТАКОЙ способ решения задачи, что умножение 2х2 будет идти годами....

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


Top
   
PostPosted: Sun Oct 07, 2007 12:27 pm 
Вот и я о том же


Top
   
PostPosted: Sun Oct 07, 2007 7:36 pm 
Чего-то я туплю. Скачал сырцы FASM 1.67.23. Собрал его для Хамелеона. Проверяю - падает.
Смотрю, где падает - в libc функции fputc. Ага, значит параметры функции передали неправильные.
Смотрю код fasm/libc/system.inc -

Quote:
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 посмотреть.)

Quote:
int fputc(inc c, FILE * stream);


То есть должен передаваться не файловый дескриптор 1 (stdout), а указатель на структуру типа FILE.

Ну, думаю, ошибка у меня. Делаю под Linux в точности как сказано в документации:
Quote:
gcc fasm.o -o fasm

И запускаю полученный файл уже под Linux, который при запуске странным образом падает и под Линуксом.

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

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


Top
   
PostPosted: Sun Oct 07, 2007 8:16 pm 
Offline
Site Founder
User avatar

Joined: Sun Aug 08, 2004 8:55 am
Posts: 689
man stdio
Code:
     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


Top
   
PostPosted: Sun Oct 07, 2007 8:48 pm 
fputc по стандарту принимает в качетсве аргумента указатель на структуру данных типа FILE.

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

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


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

Code:
#include <stdio.h>
int main()
{
  fputc( '@', stdout );
  return 0;
}


В случае fasm, используется первый вариант.
Если не верите, загляните в /usr/include/stdio.h и посмотрите как определена структура FILE.

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

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


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


Top
   
PostPosted: Mon Oct 08, 2007 1:12 pm 
Вылечилось просто. Пришось заменить строку
Quote:
mov [con_handle], 1

на
Quote:
mov ebx, stdout
mov eax,[ebx]
mov [con_handle], eax

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

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


Top
   
PostPosted: Mon Oct 08, 2007 7:49 pm 
Offline
Kernel Developer
User avatar

Joined: Mon Nov 28, 2005 8:00 pm
Posts: 1601
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 - очень известная система, у которой в том числе и на этом форуме есть сторонники! (Кстати, там для эмуляции Колибри даже ядро модифицировать не надо.)

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


Top
   
PostPosted: Mon Oct 08, 2007 8:20 pm 
Offline

Joined: Wed Feb 21, 2007 3:03 pm
Posts: 188
diamond wrote:
(Кстати, там для эмуляции Колибри даже ядро модифицировать не надо.)


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


Top
   
Display posts from previous:  Sort by  
Post new topic  Reply to topic  [ 44 posts ]  Go to page Previous 1 2 3 Next

All times are UTC+03:00


Who is online

Users browsing this forum: No registered users and 1 guest


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Limited