Студентам с вопросами о лабораторных работах сюда

DecMiay

В простое MessageBox -- массив ?? Думаю вы что-то путаете на данном этапе.

 

DecMiay
Вопросы абсолютно непонятны. Попробую помедитировать.
1) Насколько понимаю пример вообще не при чем. Вам нужно, видимо, передать массив в ВАШУ процедуру в DLL, т.к. у процедуры TestHello вообще нет параметров.
Для начала научитесь передавать параметры внутри одного исходника. А далее - все просто. Ведь передача в DLL ничем не отличается.

 

Собственно вот кусок кода из приложения

Код (Text):

1. ...
2.  
3. incMass :DWORD, :DWORD
4.  
5. mas DD 100 DUP(?)
6. ln  DD 0
7. ...
8. Здесь код заполнения массива
9. ...
10. INVOKE incMass,mas,ln ; вызов функции из dll

А вот кусок dll кода, в кором я не пойму некоторые вещи
Как передать этот массив в код, переписать его эл-ты на 1, и вернуть обратно???

Код (Text):

1.  ...
2. incMass PROC m:DWORD, l:DWORD
3. mov ecx,l
4. lea esi,m
5. mov ebx,1
6. start:
7. mov [esi],ebx
8. add esi,4
9. loop start
10. ret
11. incMass endp
12. ...

И ещё как я понял если использовать CALL то аргументы передаються только через СТЕК???
Почему в длл кампилятор рунаеться на OFFSET?

 

1) Аргументы передаются так, чтобы их правильно считали. Для стандартных функций есть стандарты. Для себя можете передавать как хотите, даже через регистры. Но вот стандарты придуманы для того, чтобы "ничего не испортилось".
2) DLL ничем не отличается. Покажите конкретный исходник, тогда станет понятно в чем причина.

3) Массив обычно не передается, а передают указатель на него. В DLL вы просто запишите 1 или что хотите прямо в массив.

 

Кто поможет?
Надо преобразовать строку в флоат и обратно, использую WinAPI, вот эти функции.
VarBstrFromR4
VarR4FromStr

mov edx, [param0] ;414587DDh;
invoke VarBstrFromR4, edx, 0, 0, addr szbuffer ; Преобразует значение с плавающей запятой в значение Тип bstr.
mov edi, eax
invoke SetWindowText, hwndEdit2, addr szbuffer
invoke wsprintf, addr szbuffer, addr format_int, edi ; Конвертируем число в строку
invoke SetWindowText, hwndEdit3, addr szbuffer
Возвращает ерунду, должно быть 12.34567 а выскакивают не читабельные символы.
ЗЫ
Функция возвращает 0, то есть S_OK.​

 

bstr это wide-строка (wchar_t*), а значит szbuffer тоже, с ним надо использовать SetWindowTextW/wsprintfW.
как насчет более простого варианта с atof?

 

Intro, функция принимает указатель в который записывается указатель. BSTR - это указатель на строку предваренную длиной.
Нужно завести указатель и его адрес передавать в VarBstrFromR4, а в SetWindowText передавать уже значение по этому указателю - это будет адрес UNICODE строки.

Не всегда, там можно хранить и ANSI строку и вообще любые данные для этого существует функция SysAllocStringByteLen.

 

Спасибо, заработало.
А как насчёт утечек памяти, как эти строки удалять, хотя они небольшие, а если преобразования много тысяч.
И ещё, как поменять, что бы точка была, а не запятая.
ЗЫ
А понял, на счёт запятой. Надо lcid задать равно 1.

 

SysFreeString.

 

Есть код на МАСМе.

Код (ASM):

1. Fvector_setHP MACRO vec_this:req, h:req, p:req
2.    fld     p
3.    fsincos         ; st(0)= _cp=cos(p); st(1)= _sp=sin(p)
4.    fld     h
5.    fsincos         ; st(0)= _ch=cos(h); st(1)= _sh=sin(h); st(2)= _cp=cos(p); st(3)= _sp=sin(p)
6.    fmul   st, st(2)   ; z = _ch*_cp;
7.    fstp   vec_this.z
8.    fmul   st, st(1)   ; x = _sh*_cp;
9.    fchs         ; x = -x;
10.    fstp   vec_this.x
11.    fstp   st
12.    fstp   vec_this.y
13. ENDM

А это С++

Код (C++):

1. IC   SelfRef   setHP   (T h, T p)
2. {
3.    T _ch=_cos(h), _cp=_cos(p), _sh=_sin(h), _sp=_sin(p);
4.    x = -_cp*_sh;
5.    y = _sp;
6.    z = _cp*_ch;
7.    return *this;  
8. }

Есть проблема, код асм который сочиняет компилятор очень не эффективный. Как сделать что бы компилятор использовал инлайн код sincos? Короче, что на выходе был похожий код.

 

Intro,
Никак, разве что попробовать оптимизацию включить. Для вашей задачи можно использовать инлайн вставку __asm {}

 

Intro,

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

Кстате как это работает - после первого обращения к блоку математики система начинает перезагружать контекст математики в течении нескольких поточных квантов. Это очень тяжёлые по таймингу операции. Поэтому либо крутитесь в мат вычислениях, либо минимизируйте их вызовы. Если поток один раз выполнит мат блок, то далее он будет тормозить в течении нескольких квантов, хотя при этом он не будет вычислять математику.

 

То есть в С++ нету встроенной функции fsincos?
Забыл сказать что проект: движок XRay С.Т.А.Л.К.Е.Р. Тень Чернобыля.
Ещё.

Код (C++):

1. IC float   _cos   (float x)     { return cosf(x); }
2. #define IC         inline
3. #define ICF         __forceinline       // !!! this should be used only in critical places found by PROFILER

Наверное можно IC заменить на ICF, проблема именно в том, что все эти синусы с косинусами компилятор делает не инлайн, а в результате, промах кеша, задержка сотни тактов, если не тысяча, мне это и без всяких профайлеров понятна, и ещё код длинней становится.
Всё таки VС++ не самый лучший ЯП. Что ещё заметил, если код простой, то компилятор его хорошо оптимизирует, сложные конструкции плохо оптимизируются, даже если настройки все правильные. Говорят что С++ делает часто код более оптимальным, по сравнением кодом на ассемблере, но это работает если прогер хорошо программирует на С++, но плохо программирует на ассемблере(быдлокодер). Это хорошо заметно по проекту XRayExtensions, большинство коммитёров полные, ну да ладно.

 

А если через ряды с использованием AVX? Интересно быстрее будет или нет?

 

Мановар, быстро можно сделать через параллельные SSE, там сразу можно вычислить два синуса и косинуса, только код длинней будет.

 

Мановар,

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

 

Intro,

> Говорят что С++ делает часто код более оптимальным, по сравнением

Не согласен. Есть скрытые параметры, как и в данном случае. Не зная как работает шедулер вы лишь методом перебора сможить оптимизировать код.

 

Не факт. Возможно, что при определённых ключах компиляции будет не-inline, а при определённых - inline (зависит от заголовочного файла, там тоже может быть условная компиляция при разных ключах оптимизации). Надо дизасмить вызывающую функцию после компиляции с оптимизирующими ключами.

Прув есть? Дизасм вызывающей функции смотрели?

Вы себя переоцениваете, узкое место может быть совсем в другом месте.

Компилятор - не панацея от кривых рук. Ему тоже надо помогать.

Мало ли что говорят, на заборе тоже много чего понаписано.

Техника оптимизации всегда заключалась и заключается в итеративном выполнении следующих шагов:
1. Выбор оптимального алгоритма с учётом факторов и ограничений (архитектура, память, ОС и т.д.). Нет оптимального алгоритма - нет оптимального решения.
2. Написание кода на высокоуровневом языке и отладка.
3. Переписывание кода с поправкой на векторизацию вычислений (если требуется).
4. Упрощение кода, преследующее единственную цель - дать понять компилятору, что это можно скомпилировать проще.
5. Переписывание критических участков на асме. Хочешь - не хочешь - а векторизация пока работает в компиляторах паршивенько.

 

Вопрос? В виртуальных методах this всегда передаётся через ECX. В обычных, может и через EAX и другие регистры. Я сейчас про VS C++ любой версии. Мне надо точно знать для создания макроса вызова виртуальных методов в МАСМе.