HIBYTE, LOBYTE, HIWORD, LOWORD, WORD, DWORD, SHIFT

[GSerg]

Производится пробный запуск фабрики
Для начала - что-нибудь маленькое и простенькое...

[kuhtiov]

Это по поводу чего?

[tyomitch]

Читать умеем? во второй строчке описание.

[alibek]

Кстати, можно заменить деление на целочисленное деление.
Побыстрее должно быть.

[Konst_One]

если переделать это в класс, то можно и проинициализировать

[arthur2]

Вот эта функция работает не корректно:

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

Public Function LOWORD(ByVal DblWord As Long) As Integer
  LOWORD = DblWord And &HFFFF&
End Function

Если передать отрицательное число, она загибается. Переполнение.

Подскажите, как поправить, чтобы сильно не замедлить?

А ещё интересно, что делает функция Shift? Где это можно применить?

[ANDLL]

А ещё интересно, что делает функция Shift?

Умножает на два в степени n.
Если возьмешь любое число, распишешь в виде ноликов и единичек, а потом умножишь на два(да еще и несколько раз), то вероятно сразу поймешь. Ну или просто поищи bitwise shift

[Хакер]

1)

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

Public Function LOWORD(ByVal DblWord As Long) As Integer
    LOWORD  = DblWord And &H7FFF&
    If DblWord And &h8000& then LOWORD = LOWORD or &h8000%
End Function

2) Использовать GetMem2

А ещё интересно, что делает функция Shift?

У него (у GSerg'а) эта функция может делать 4 вещи: сдвигать биты влево, сдвигать биты вправо, и аналогично - вращать влево, и вращать вправо.

Подбробнее - [url=http://ru.wikipedia.org/wiki/Битовый_сдвиг]здесь[/url]. (Вращение там называется циклическим сдвигом).

Где это можно применить?

Да хоть в твоей проблеме - заменить LOWORD(x) на HIWORD(SHIFT(smShiftLeft, x, 16)). Только это более криво, чем предложенный выше вариант.

[arthur2]

ANDLL
То есть, это побитовое смещение? Тогда понятно. Ну, ShiftLeft, ShiftRight - это смещение влево-вправо. А что такое RotateLeft?

И всё-таки, первый вопрос интересней. Как код LOWORD поправить? На сколько я понял, в hex-то она даёт правильный ответ.

НО:

&hffff=-1
А вот &hffff&=65535, что в intege помещаться отказывается

Можно ли исправить, не пребегая к копимемери?

[arthur2]

Хакер
Понятно!

То есть, без перемещения памяти, чисто логически - не получится? обидно (а кирпич-то, кстати, нужно поправить).

Да и с loword в кирпиче тоже не всё в порядке - если там поставить целочисленное деление, то функция ошибается на один в некоторых случаях, а если обычное - то ошибается на один в других некоторых случаях.

Чуть позже:
Прости, туплю - мне показалось, у тебя там цитата, а там исправленный код! Работает на ура - спасибо!

[Хакер]

То есть, без перемещения памяти, чисто логически - не получится?

Что значит "чисто логически"?
Что значит "без перемещения памяти - не получится"? Где ты увидел в моём примере признаки перемещения памяти??

Да и с loword в примере тоже не всё в порядке - если там поставить целочисленное деление, то функция ошибается на один в некоторых случаях, а если обычное - то ошибается на один в других некоторых случаях.

Чё? Какое ещё деление? Куда подставить?

И всё-таки, первый вопрос интересней. Как код LOWORD поправить? На сколько я понял, в hex-то она даёт правильный ответ.

В хексе всё, разумеется, даёт правильный ответ.
Здесь Overflow происходит главным образом из-за конвертации Long-а в Integer. Дело в том, что для Singned-типов (а вб-шные Integer и Long таковыми и являются) конвертация - чуть более интеллектуальное действие, чем простое копирование двух-байт. На словах это можно описать так:
Отдельно берётся знаковый бит, и отдельно берутся биты числа.

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

Именно из-за этой интеллектуальной особенности приведения типов, когда ты преобразуешь -1% в Long, ты получаешь -1&, а не 65535&, как получил бы при использовании CopyMemory.

Можно ли исправить, не пребегая к копимемери?

Я ведь вроде бы показал, что можно.

[arthur2]

Хакер
Стоп-стоп-стоп... Я же уже сказал, что ступил, не туда поглядел. Я про getmem и двиг битов

Исправленный код работает на ура - ещё раз спасибо

Чё? Какое ещё деление? Куда подставить?

а это про hiword из кирпича (кажется, слова уже заплетаются, пора спать идти, пол-третьего как ни как)

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

Public Function HIWORD(ByVal DblWord As Long) As Integer
  HIWORD = DblWord / &H10000
End Function

Для некоторых чисел она ошибается на один. Если поменять / на \ как предложил alibek, она исправляется, но начинает ошибаться для других чисел.

А вот так:

?hex(HIWORD(&hfff08001))
FFF1

?hex(HIWORD(&hffff8001))
0

она ошибается в любом варианте!

Именно из-за этой интеллектуальной особенности приведения типов...

Ну, в общем, это я более-менее понимаю. &hffff& на самом-то деле &h0000ffff, поэтому оно и положительное - бит знака сброшен.

[Хакер]

Такой вариант устроит?

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

Public Function HIWORD(ByVal DblWord As Long) As Integer
  HIWORD = ((DblWord And &HFFFF0000) \ &H10000)
End Function

[arthur2]

В общем, методом своего любимого тыка дорылся-таки.

"Неправильное" округление при делении получается при отрицательных числах. Функция ошибается на один всегда, если установлен хотя бы один бит в loword.

В связи с чем исправил так:

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

Public Function HIWORD(ByVal DblWord As Long) As Integer
  HIWORD = DblWord \ &H10000
  If DblWord < 0 Then
    If DblWord And &HFFFF& Then HIWORD = HIWORD - 1
  End If
End Function


Функция больше не ошибается. Но, мне кажется, то же самое можно сделать как-то по-оптимальнее. А?

[arthur2]

Хакер
Упс... Пока я методом тыка, ты уже исправил! Спасибо!

Теперь бы автору просигналить, чтобы поправил кирпич...

[Хакер]

Теперь бы автору просигналить, чтобы поправил кирпич...

На форуме был большой бунт, "после чего автор красиво свалил оттуда, махнув хвостом" (с) Мышъх.

[arthur2]

А чё за буча-то была? Великая октабрьская?

Сделат тест на скорость:

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

Public Sub testLo()
Dim l As Long, tc As Long, k As Long
tc = GetTickCount
For l = 0 To 10000000
  loWord k
Next
Debug.Print "без апи"; GetTickCount - tc

tc = GetTickCount
For l = 0 To 10000000
  loWord_ k
Next
Debug.Print "copyMem"; GetTickCount - tc

End Sub

Public Function loWord(ByVal DblWord As Long) As Integer
    loWord = DblWord And &HFFFF&
    If DblWord And &H8000& Then loWord = loWord Or &H8000
End Function

Public Function loWord_(ByVal DblWord As Long) As Integer
  CopyMemory loWord_, DblWord, 2
End Function


Получилось:
без апи 2875
copyMem 2531

Практически, поровну. Но апи всё-же чуточку быстрее (в прошлом варианте и правда было быстрее где-то на треть, но нафига быстрее, если с косяком )

Появился ещё такой вопрос: параметры приходят в процедуру рядышком? можно ли вот так сделать:

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

Public Sub HLWord(dw As Long, hW As Integer, lW As Integer)
   CopyMemory lW, dw, 4
'  Debug.Print Hex(dw)
'  Debug.Print Hex(hW); " "; Hex(lW)
End Sub


Вроде бы, работает - но не черевато ли это каким глюком?..

[alibek]

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

[Хакер]

Public Sub testLo()
Dim l As Long, tc As Long, k As Long
tc = GetTickCount
For l = 0 To 10000000
loWord k
Next
Debug.Print "без апи"; GetTickCount - tc

tc = GetTickCount
For l = 0 To 10000000
loWord_ k
Next
Debug.Print "copyMem"; GetTickCount - tc

End Sub

Public Function loWord(ByVal DblWord As Long) As Integer
loWord = DblWord And &HFFFF&
If DblWord And &H8000& Then loWord = loWord Or &H8000
End Function

Public Function loWord_(ByVal DblWord As Long) As Integer
CopyMemory loWord_, DblWord, 2
End Function

1) Нельзя так измерять скорость. Нельзя ни при каких обстоятельствах использовать Declare Function для API-функций, где важна скорость.

2) Использовать CopyMemory для копирования двух байт - извращенство. Видел бы, сколько там кода, внутри CopyMemory, а сколько внутри GetMem2.

3) Судя по тому, что ты используешь Debug.Print, ты замеряешь скорость не в скомпилированном варианте, а в IDE. А этого нельзя делать - в IDE твой код компилируется в P-code, а он хоть-как будет медленнее нативного (внутри CopyMemory).

Появился ещё такой вопрос: параметры приходят в процедуру рядышком? можно ли вот так сделать:

Да. Но лучше для первого аргументы использовать ByVal.

[Antonariy]

Я думаю при количестве циклов аж в 10000000 и нескольких запусках, можно полагаться и на IDE. Для получения точного результата нужно использовать VB Watch2.

[Хакер]

Antonariy
Нельзя. Отношение времён будет одинаковым что при 100 циклах, что при 10000000. Случайная погрешность в последнем случае будет меньше, да. Но зато будет лишнее время засчёт работы самого цикла.

Взять хотя бы то, что в IDE после вызове любой API-функции осуществляется проверка валидности структуры стека.

[arthur2]

alibek

Но если нужно будет заниматься поддержкой кода...

В том смысле, что потом не пойму, чё это такое? а какая реализация лучше?

Хакер
1. Способ - какой придумался. Обе функции из win32.tlb А как измерять лучше?

2. Это в том смысле, что лучше getmem2? я просто не очень с ней знаком

3. Да, это я снова ступил. Заменил на msgbox и скомпилировал - без апи почти в 5 раз быстрее!
без апи 109
copyMem 484

А вот разница с проектом, где функции из win32.tlb и где Declare почти не заметна
Она есть, но очень маленькая

Да. Но лучше для первого аргументы использовать ByVal

Это я не понял. В смысле, в деклорации апи? Если byval, то передавать надо не переменную, а указатель? или как? Или в смысле первого аргумента моей процедуры( byval dw As Long )? А почему? внутри же она всё равно не изменяется?

[Хакер]

1. Способ - какой придумался. Обе функции из win32.tlb А как измерять лучше?

Тогда ок.

2. Это в том смысле, что лучше getmem2? я просто не очень с ней знаком

http://www.vbstreets.ru/VB/Articles/65973.aspx

А вот разница с проектом, где функции из win32.tlb и где Declare почти не заметна

Это очень просто объяснить: ты используешь всего-лишь одну API-функция. Компилятор VB для многократных вызовов Declare-функций используется регистр ESI для хранения указателя на функцию.

При этом, в регистр ESI указатель попадает до первого использования. Там де осуществляется проверка ячейки кастомной таблицы импорта (есть внутри VB-программ такая, для всех Declare-функций) и вызов DllFunctionCall (которая на самом деле нифига не Call) в начеле безопасного контекста.

Но стоит тебе вынести вызов loWord k и вызов loWord_ k в отдельные функции Fun и Fun_, и вставить в циклы вызовы функций Fun и Fun_ -- как ты заметишь значительную разницу.

Ибо между вызовами функции Fun_ хранить указатель в ESI уже не получится, и код будет вынужден каждый раз его получать из ячейки кастомной таблицы импорта.

[alibek]

В том смысле, что потом не пойму, чё это такое? а какая реализация лучше?

Именно. Напиши обычно, с использованием логических операторов (AND и целочисленное деление).
Будет не так изящно, но зато ты (или кто другой) никогда не застрянут на этом месте, пытаясь понять, что делает код.

[arthur2]

Antonariy

нужно использовать VB Watch2.

А что это? Поиском не ищется

Хакер

Но стоит тебе вынести вызов loWord k и вызов loWord_ k в отдельные функции Fun и Fun_, и вставить в циклы вызовы функций Fun и Fun_ -- как ты заметишь значительную разницу.

Спасибо, понял! А есть у .tlb подводные камни? Скажем, если на машине нет нужной библиотеки, то при Declare вызов такой функции легко ловится обработчиком ошибок. А с .tlb - будит ли так же?

alibek

Будет не так изящно, но зато ты (или кто другой) никогда не застрянут на этом месте, пытаясь понять, что делает код.

Ага! И, как выяснилось - ещё и быстрее! (Но сам способ интересный - может где в другом месте использую. Да и в чужом коде увижу - теперь соображу)

А вот насчёт наглядности - не соглашусь. Теперь - после того как понял - второй вариант кажется внятнее (да можно и пояснить комментарием). А с and я хоть и, вроде бы, понимаю, но с некоторым усилием. Да и самый внятный первоначальный вариант, как выяснилось, оказался несколько глючным.

[Хакер]

Спасибо, понял! А есть у .tlb подводные камни? Скажем, если на машине нет нужной библиотеки, то при Declare вызов такой функции легко ловится обработчиком ошибок. А с .tlb - будит ли так же?

Подводных камней нет. .tlb предоставляет возможность воспользоваться родным виндозным механизмом импорта функций из DLL. Родной виндовый загрузчик при подгрузке DLL в случае её отсутсвия будет вынужден обрадовать тебя таким сообщением:

[arthur2]

Хакер
Я вот про что:

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

Option Explicit
Private Declare Function lalala Lib "figlimigli.dll" () As Long
Private Declare Function trampampam Lib "kernel32" () As Long

Private Sub Form_Load()
  On Error Resume Next
  lalala
  trampampam
End Sub

У меня нет библиотеки figlimigli.dll, а в kernal32 нет функции trampampam, но скомпилированный ехе нормально загружает окно и ничего не сообщает. Будет ли так же с .tlb? (я бы сам проверил, да не придумаю, как)

[Хакер]

Ты перечитай верхнее сообщение. А то, кажется, ты его не понял. Если так и не поймёшь, я перефразирую.

[arthur2]

Да, не понял.

[Хакер]

Может у тебя отображение картинок выключено?

Ещё раз:
Библиотеки, функции которых импортируеются статическим импортом, грузятся при загрузке EXE.

Если какая-то библиотека будет не найдена, отобразится сообщение, скриншот которого я выше показал, и загрузка будет остановлена на этом. Т.е. приложение не запустится. (Ну а толку-то его запускать, если библиотеки нет?)