Передавать значения в процедуру, можно через стек, а можно через переменные предназначенные для приёма передачи параметров в ту процедуру.
Proc1_P1: rb 1
Proc1_p2: rb 1
Proc1_Result rb 1
Proc1:
…......
ret

START:
mov [Proc1_P1], 34
mov [Proc1_P2], 64
call Proc1
xor eax,[Proc1_Result]
…..........
Какие достоинства и недостатки передачи параметров через переменные, вместо стека ?
Главное что интересует, - можно ли сказать что это более медленный (быстрый) способ передачи данных чем через стек ?

Передача параметров через стек — это на 100% универсальный способ. Недостаток: чтобы использовать полученные параметры во вложенных процедурах, придётся исполнить народный танец.
Использование глобальных переменных не поддерживает многопоточность и рекурсию.
Использование указателя на локальную структуру — гибридный способ, поддерживает многопоточность, у нас используется в файловых системах. Для полной рекурсии достаточно выделить новую структуру. На что похожа выборочная рекурсия, можно увидеть в ntfs.inc со строки 1116 http://websvn.kolibrios.org/filedetails ... 2Fntfs.inc
Скорость может упасть только при перемешивании с кодом большого количества отдельных глобальных переменных.

Всё время забываю спросить....
А нельзя ли настроить Fasm (Fasm Editor 2.0) таким образом чтобы можно было писать по несколько команд в одной строке ? Вот так вот:
reset1: mov dx,$0100 mov eax,pts
.m1: mov byte [eax],$ff inc eax dec dx jnz .m1
ret

Если КОС запускать в qemu.exe то dosbox в ней не заупскается. Должно ли так быть ?

[quote="ALEXS1983"]Всё время забываю спросить....
А нельзя ли настроить Fasm (Fasm Editor 2.0) таким образом чтобы можно было писать по несколько команд в одной строке ? Вот так вот:
reset1: mov dx,$0100 mov eax,pts
.m1: mov byte [eax],$ff inc eax dec dx jnz .m1
ret[/quote]

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

macro asm_inline [args*]
{
forward
args
}

; копирует массив байт из buffer1, в buffer2.
asm_inline <mov esi, buffer1>, <mov edi, buffer2>, <mov ecx, 22>, <cld>, <rep movsb>

После припроцессинга, макрос развернётся в следующую конструкцию...

; копирует массив байт из buffer1, в buffer2.
mov esi, buffer1
mov edi, buffer2
mov ecx, 22
cld
rep movsb

То ли лыжи не едут..... то ли фиг его знает :-) Нужна функция быстрого вывода графики на экран в КОС ! В Дельфи (винде) есть tbitmap ( Var gamecanvas: tbitmap;) в которою передаёшь точки которые нужно перечертить, вот так вот: gamecanvas.Canvas.Pixels[PutPixel_x,PutPixel_y]:=PutPixel_color; (эта передача пикселей без прорисовки их) далее перечерчиваешь tbitmap на форме процедурой:
MainForm.Canvas.StretchDraw(rect(0,0,MainForm.Width-0,MainForm.Height-30), gamecanvas)
которая заодно растягивает tbitmap на всю форму; ну или без растяжения, - вот так вот
MainForm.Canvas.Draw(0,0,gamecanvas); (еще быстрее прорисовывает чем StretchDraw)
Если игровое поле 255х255 при частоте вывода 50 раз в секунду, да и с кешированием
вывода точек, при котором фактически присваивается канвасу приблизительно от 50х50 до 70х70 точек, то это всё работает достаточно проворно, ЧЕГО В КОС НЕ НАБЛЮДАЕТСЯ, когда используешь Функция 1 - поставить точку в окне.
Скажите пожалуйста, есть ли достаточно проворные способы вывода графики в КОС не прибегая ко всяким опенгл и директам ?

ALEXS1983, попробуй порисовать в gs:[колво бит на пиксель * номер пикселя]. И где-то есть функция для получения параметров графики(эти самый кол-во бит на пиксель), там и про этот gs:[...] написано. Типа DirectDraw - прямой доступ к видеопамяти)

Сам по себе системный вызов это где-то 1000 тактов. Кошерный способ — функция 65. Быстро выводить случайные пиксели можно только через видеобуфер по адресу FE000000h, но это может рисовать поверх других окон.

"попробуй порисовать в gs:[колво бит на пиксель * номер пикселя]. И где-то есть функция для получения параметров графики(эти самый кол-во бит на пиксель), там и про этот gs:[...] написано. Типа DirectDraw - прямой доступ к видеопамяти)"

"Быстро выводить случайные пиксели можно только через видеобуфер по адресу FE000000h, но это может рисовать поверх других окон."

А МОЖНО ОБ ЭТОМ ПОПОДРОБНЕЙ ?!... И ХОТЯ БЫ С КУСОЧКОМ КОДА ПРИМЕРА КАК ЭТО ДЕЛАЕТСЯ!

ALEXS1983 wrote:"попробуй порисовать в gs:[колво бит на пиксель * номер пикселя]. И где-то есть функция для получения параметров графики(эти самый кол-во бит на пиксель), там и про этот gs:[...] написано. Типа DirectDraw - прямой доступ к видеопамяти)"

"Быстро выводить случайные пиксели можно только через видеобуфер по адресу FE000000h, но это может рисовать поверх других окон."

А МОЖНО ОБ ЭТОМ ПОПОДРОБНЕЙ ?!... И ХОТЯ БЫ С КУСОЧКОМ КОДА ПРИМЕРА КАК ЭТО ДЕЛАЕТСЯ!

Нельзя. Не слушай про запись через gs. Слушай Pathoswithin и используй функцию 65 либо функцию 7.

Прямой вывод в видеобуфер это только для полноэкранных приложений или рисования совсем уж случайных пикселей, вроде снега на экране, но такой эффект нужно отключать, если окно неактивно.

Pathoswithin, ну кинь код, - рассмотрю!
Вот еще есть вопрос, может быть конечно смешной и примитивный, но всё таки мне надо уточнить:
Быстродействие в КОС является таким же как в винде (на данной машине)?... ну конечно при условии использования исключительно арифметических команд асма, переходов, присваивания ячейкам памяти и прочее ?
Проще выражаясь, если написана процедура (на асме) с циклами обрабатывающая очень много данных массивов... плюсы... минусы.... ксоренье и пересылка данных между массивами.... имеющая множество вложенных вызовов (CALL) из процедуру в процедуру, без использования int и api и прочего.... короче, :-) если длительность выполнения такой процедуры в винде будет занимать 5 секунд, то на КОС, Я НАДЕЮСЬ, она тоже будет выполняться в пределах такого же времени?.... а не 40 сек ?... и даже не 10 сек? ТАК ОНО ?

Ну по адресу FE000000h начинается обычное растровое изображение экрана.
Функцией 61.2 получаешь количество бит на пиксель (например 32), считаешь количество байт на пиксель (делишь на 8), умножаешь на Х.
Функцией 61.3 получаешь длину строки, умножаешь на Y.
Всё складываешь.
Ложишь по адресу цвет пикселя.
Но зачем тебе выводить отдельные пиксели?

Скорость работы самого кода — одинаковая.

ALEXS1983 wrote:Pathoswithin, ну кинь код, - рассмотрю!
Вот еще есть вопрос, может быть конечно смешной и примитивный, но всё таки мне надо уточнить:
Быстродействие в КОС является таким же как в винде (на данной машине)?... ну конечно при условии использования исключительно арифметических команд асма, переходов, присваивания ячейкам памяти и прочее ?
Проще выражаясь, если написана процедура (на асме) с циклами обрабатывающая очень много данных массивов... плюсы... минусы.... ксоренье и пересылка данных между массивами.... имеющая множество вложенных вызовов (CALL) из процедуру в процедуру, без использования int и api и прочего.... короче, если длительность выполнения такой процедуры в винде будет занимать 5 секунд, то на КОС, Я НАДЕЮСЬ, она тоже будет выполняться в пределах такого же времени?.... а не 40 сек ?... и даже не 10 сек? ТАК ОНО ?

Если писать с глобальными переменными на каждую процедуру и прочими деоптимизациями - будет медленнее. Хотя вряд ли в 8 раз, конечно. Но Колибри тут ни при чём, такой код в винде будет тормозить ровно так же.