Clarion Assembler

Гость

Здравствуйте

Подскажите, кто знает...
Нужно вставить кусочек ассемблерного кода в нужное место.
Примерно так:

proc  procedure
  code
.......
<-- вот сюда ассемблерную вставку
......

Это возможно? Если да, то как?
Если так нельзя, то как можно ВООБЩЕ вставить асс.код?
Примерчик, если можно.

p.s.
Кажется когда-то и где-то был пример как это делается, но у меня пример утерен напрочь

Сергей - chusha@mail333.com ; chusha@hotbox.ru

(Добавление)

1. для нафига?
2. инлайнового асма в кларе нет, что ж теперь делать... но можно подключить .a модуль как external source. на кларосайтах есть примеры md5 на асме. или спросить у Струменского/Ставича/Руденко/еще-кого-нить, пусть подробнее расскажут.

Кажется когда-то и где-то был пример как это делается, но у меня пример утерен напрочь

поделись секретом - зачем такое может понадобиться кроме как для истинно хакерских целей?

--
Best regards,
Maxim Yemelyanov,
Enigma Soft Company
phone: (057) 7177977
WEB: http://enigmasoft.com.ua
e-mail: clalist@enigmasoft.com.ua
ICQ: 12253836

Написал: ClaList(2)

Гость

на кларосайтах есть примеры md5 на асме. или спросить у Струменского/Ставича/Руденко/еще-кого-нить, пусть подробнее расскажут.

Я и спрашиваю...

поделись секретом - зачем такое может понадобиться кроме как для истинно хакерских целей?

Скоростей запредельных хочу :/

Сергей

Я и спрашиваю...

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

Скоростей запредельных хочу :/

Гм. А конкретнее? Кларин компилер довольно-таки классный, хоть и не умеет инлайнить функции и прочие мелочи...

--
Best regards,
Maxim Yemelyanov,
Enigma Soft Company
phone: (057) 7177977
WEB: http://enigmasoft.com.ua
e-mail: clalist@enigmasoft.com.ua
ICQ: 12253836

Да всё банально!
У меня в графике все расчёты ведутся с использованием REAL-типа.
Всё было прекрасно до тех пор, пока не стал тестировать на больших объёмах. И тут выяснилось, что простейшая операция
целое=вещественное на ДВА ПОРЯДКА(!) медленнее чем, например, real*real.
Это стало излишне "узким" местом и требует "разруления" :/

Сергей
Написал: ClaList(2)

Гость

Гм... может я чего-то не понимаю, но что мешает вести эти расчеты в
decimal, масштабируя числа по мере необходимости?

--
С.А.
Написал: ClaList(2)

Гость

Хм, а ты пробовал вести расчёты с использованием DECIMAL типа?
Попробуй. И ты поймешь КАК ЭТО МЕДЛЕННО!
Как-то была тема по этому поводу (вспомни, мой тестик t_speed).
Приведу резултаты тестирования для мой машины...

Код: Выделить всё

[6000.0.915(local) P4 2400Mhz DDR333 512M]
BYTE:1             *=1,081,081,075;1,077,571,680;  150,387,240;    3,913,042
BYTE:2             *=  977,517,098;  981,120,848;  149,501,655;      485,383
SHORT:1            *=1,074,113,848;1,082,251,077;  149,501,655;    3,931,835
SHORT:2            *=  976,986,531;  975,609,751;  149,999,998;      160,711
USHORT:1           *=1,082,251,081;1,077,571,680;  149,999,998;    3,930,131
USHORT:2           *=  977,517,098;  973,093,943;  149,688,144;      230,223
LONG:1             *=1,071,428,567;1,048,721,862;  480,559,186;    3,913,042
LONG:2             *=  981,120,848;  977,517,098;  597,524,070;      129,633
ULONG:1            *=      802,134;    3,687,867;    3,916,871;    3,999,999
ULONG:2            *=    1,904,760;    2,039,098;    1,319,346;      107,694
SREAL:1            *=    2,723,215;    2,463,867;    2,721,825;    2,339,593
SREAL:2            *=  975,990,624;  967,628,895;  950,460,826;   63,113,598
REAL:1             *=    2,727,270;    2,479,333;    2,744,182;    2,330,173
REAL:2             *=  972,160,845;  968,204,028;  950,460,826;   63,348,337
BFLOAT4:1          *=    7,486,167;    7,384,198;    7,222,950;    6,356,261
BFLOAT4:2          *=    7,519,925;    7,486,167;    7,174,738;    6,875,473
BFLOAT8:1          *=    7,058,810;    7,175,469;    7,040,745;    4,162,325
BFLOAT8:2          *=    7,164,273;    7,114,624;    7,034,603;    6,784,257
DECIMAL(31,15):1   *=      520,495;      512,117;    2,055,766;    2,080,921
DECIMAL(31,15):2   *=      541,367;      623,700;      130,717;       64,787
PDECIMAL(31,15):1  *=      507,353;      512,029;    2,038,972;    1,935,481
PDECIMAL(31,15):2  *=      554,257;      540,589;      186,237;       29,999
STRING(15):1       *=      495,049;      494,739;       70,110;    1,085,802
STRING(15):2       *=      891,089;      895,082;      688,029;      146,731
CSTRING(15):1      *=      494,505;      489,608;       77,584;    1,155,197
CSTRING(15):2      *=      924,640;      952,380;      710,436;      115,072
ANY:1              *=    2,087,458;    2,102,576;    2,115,272;    1,920,428
ANY:2              *=    7,200,000;    7,142,273;    6,688,018;    6,569,343
Windows Version=Windows XP Professional Build 2600
Clarion Version=6000
Clarion SubVersion=0.915(local)
Date/Time=2004/06/10 15:56:00
;=Type:Variant=Add;Sub;Mul;Div

---------------
Кстати, никаких преимуществ, кроме 31 знака и автоматического округления, у DECIMAL нет.
Поэтому, если вам достаточно 15 знаков на число - используйте REAL и round, где надо - значительно выиграете в скорости, а заодно и в загрузке процессора.

Сергей
Написал: ClaList(2)

Гость

И тут выяснилось, что простейшая операция целое=вещественное на ДВА ПОРЯДКА(!) медленнее чем, например, real*real.
Это стало излишне "узким" местом и требует "разруления" :/

А может в этих "узких" местах вместо целого использовать тот-же REAL? Ведь наверняка все эти узкие места находятся внутри отдельных процедур (методов)? Что тогда мешает при входе в эти процедуры (методы) все используемые в "узких" местах целые переменные преобразовать в локальные REAL-переменные и уже их использовать для вычислений?

Гм... может я чего-то не понимаю, но что мешает вести эти расчеты в decimal, масштабируя числа по мере необходимости?

Как-то в этой рассылке уже был разговор про скорость работы Клары с разными типами данных.
Если важны подробности - см. архивы.
А кратко - самыми "тормозными" числовыми типами оказались DECIMAL и ULONG. На порядки! по сравнению с REAL/LONG!

=============================
С уважением, Олег А. Руденко.
Oleg_Rudenko@mail.ru
Oleg_Rudenko@mail333.com
Библиотека DynaLib
http://dynalib.narod.ru

(Добавление)

Что тогда мешает при входе в эти процедуры (методы) все используемые в "узких" местах целые переменные преобразовать в локальные REAL-переменные и уже их использовать для вычислений?

Все расчёты у меня ведуться строго в REAL формате.
Проблема возникла непосредственно при рисовании.
Т.е. все графические операторы требуют координаты в SIGNED виде. Вот тут затыка и вышла.
Тормоза до 2-х раз. Скажем если выводится 20.000 полигонов в сек без преобразования long=real, то с этим будет 10.000.
Такая потеря на пустом месте - это КРУТО!
Если я это не "разрулю", то никакие ухищрения не помогут мне сделать быстрый векторный 3D-движок.

Сергей

Привет!

А БЫСТРЫЙ векторный 3D-движок пишется по СОВСЕМ другому принципу. Поищи в инете ссылки на
- октагонные (полигонный, квадро-) индексы
- ортонормальные (ортогональные) векторы

При этом твоя задача упростится на порядки.

Александр Агеев (aageev@satren.ru)
Написал: ClaList(2)

Гость

При этом твоя задача упростится на порядки.

Спасибо, поглазею

Сергей
Написал: ClaList(2)

Гость

Так никто не поделится как вставлять asm-код в Clarion? Может кто кинет ссылку где покапатся. Мне, к примеру, необходимо для применения ASprotect. Спасибо, Олег Трунов.