"Битовое вращение" или сдвиг

[GSerg]

А, то есть у тебя быстрее, чем один jmp?

[tyomitch]

Честно говоря, основную идею кода я не уловил

По сути то же, что и влинковка OBJ-ей в ехешник, только руками.

Так уж и руками? Или подразумевались "VB-руки"? Только не влинковка, а локальная перелинковка. Раз и навсегда, чтобы не городить огород.

Именно руками править ехе-шник. И не раз и навсегда, а при каждой перекомпиляции.
Уверяю тебя, влинковывать OBJ-и перехватом вызова link-а гораздо проще и надёжнее, и весь тот огород, что у тебя, городить не придётся.

Наш метод - без модификации ехешника - существенно круче \m/

Дык, "ваш метод" я давеча ужо обсуждал. А так я предложил функцию, аналогичную CallWindowProc, но быстрее. Не оценили.

Ссылки давай, искать лень. Тогда и обсудим.

[Approximator]

:)
А, то есть у тебя быстрее, чем один jmp?

Ну, во-первых, всё-таки не jmp, а call, или я опять не понял того, что вам было нужно?
Во-вторых, у меня в промежутке получается всего два раза call: первый - при обращении к функции dll, второй при переходе внутри. Быстрее, импользуя VB ты к произвольному куску кода не обратишься, даже изменяя код динамически (максимум может выпасть один call, если эта функция будет в твоей проге, но это не серьёзный выигрыш в производительности, так как остаётся ещё проблема Run-Time debug'а). Не веришь, покажи обратное.

[Approximator]

Честно говоря, основную идею кода я не уловил

По сути то же, что и влинковка OBJ-ей в ехешник, только руками.

Так уж и руками? Или подразумевались "VB-руки"? Только не влинковка, а локальная перелинковка. Раз и навсегда, чтобы не городить огород.

Именно руками править ехе-шник.

Не, Тёмыч, ты значит тоже нихрена не понял. Я компилю DLL файл, скидываю кусок кода функции из модуля в файл. Затем другой прогой на VB нахожу этот кусок кода в DLL и меняю.

И не раз и навсегда, а при каждой перекомпиляции.

И делаю это, разумеется, раз и навсегда. В том и смысл был использовать ActiveX DLL. Далее, остаётся только подключать эту библу и хоть заюзайся.

Уверяю тебя, влинковывать OBJ-и перехватом вызова link-а гораздо проще и надёжнее, и весь тот огород, что у тебя, городить не придётся.

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

Наш метод - без модификации ехешника - существенно круче \m/

Дык, "ваш метод" я давеча ужо обсуждал. А так я предложил функцию, аналогичную CallWindowProc, но быстрее. Не оценили.

Ссылки давай, искать лень. Тогда и обсудим.

Скажи честно, что не искать лень, а читать лень. Так в этой теме (но она не единственная, было ещё две) ты был. Вот здесь есть и про Read/WriteProcessMem и про доступ к сегментам кода в Run-Time и про флаги доступа к сегментам данных/кода в PE-файлах:
http://bbs.vbstreets.ru/viewtopic.php?t=8818&start=0

[tyomitch]

Не, Тёмыч, ты значит тоже нихрена не понял. Я компилю DLL файл, скидываю кусок кода функции из модуля в файл. Затем другой прогой на VB нахожу этот кусок кода в DLL и меняю.

И не раз и навсегда, а при каждой перекомпиляции.

И делаю это, разумеется, раз и навсегда. В том и смысл был использовать ActiveX DLL. Далее, остаётся только подключать эту библу и хоть заюзайся.

Я, значит, действительно с первого раза нихрена не понял. Сейчас понял. Ничего себе метод. Но наш (по крайней мере) ничем не хуже.
Чем тебе наш не нравится?

Наш метод - без модификации ехешника - существенно круче \m/

Дык, "ваш метод" я давеча ужо обсуждал. А так я предложил функцию, аналогичную CallWindowProc, но быстрее. Не оценили.

Ссылки давай, искать лень. Тогда и обсудим.

Скажи честно, что не искать лень, а читать лень. Так в этой теме (но она не единственная, было ещё две) ты был. Вот здесь есть и про Read/WriteProcessMem и про доступ к сегментам кода в Run-Time и про флаги доступа к сегментам данных/кода в PE-файлах:
http://bbs.vbstreets.ru/viewtopic.php?t=8818&start=0

[/quote]
"Про Read/WriteProcessMem и про доступ к сегментам кода в Run-Time и про флаги доступа к сегментам данных/кода в PE-файлах" есть. А про вызов ассемблерных функций путём всего этого - нет. Так?

[Approximator]

Не, Тёмыч, ты значит тоже нихрена не понял. Я компилю DLL файл, скидываю кусок кода функции из модуля в файл. Затем другой прогой на VB нахожу этот кусок кода в DLL и меняю.

И не раз и навсегда, а при каждой перекомпиляции.

И делаю это, разумеется, раз и навсегда. В том и смысл был использовать ActiveX DLL. Далее, остаётся только подключать эту библу и хоть заюзайся.

Я, значит, действительно с первого раза нихрена не понял. Сейчас понял. Ничего себе метод. Но наш (по крайней мере) ничем не хуже.
Чем тебе наш не нравится?

А ты попробуй эту идею много раз прогнать. В смысле поэксплуатируй этот код (jmp или call из произвольного места в произвольное место с во(и)звратом). Нормально?

Наш метод - без модификации ехешника - существенно круче \m/

Дык, "ваш метод" я давеча ужо обсуждал. А так я предложил функцию, аналогичную CallWindowProc, но быстрее. Не оценили.

Ссылки давай, искать лень. Тогда и обсудим.

Скажи честно, что не искать лень, а читать лень. Так в этой теме (но она не единственная, было ещё две) ты был. Вот здесь есть и про Read/WriteProcessMem и про доступ к сегментам кода в Run-Time и про флаги доступа к сегментам данных/кода в PE-файлах:
http://bbs.vbstreets.ru/viewtopic.php?t=8818&start=0

"Про Read/WriteProcessMem и про доступ к сегментам кода в Run-Time и про флаги доступа к сегментам данных/кода в PE-файлах" есть. А про вызов ассемблерных функций путём всего этого - нет. Так?

Ну, всё-таки, наверное, не ассемблерных, а маш. кодовых вставок. Про это я тоже говорил. Хотя и не уточнял, как именно - не было ни вопроса, ни необходимости. Да и я не оспариваю первенство (у GSerg'а на эту тему давно и статья имеется, правда, там всё было очень сыро, как в самом начале этой дискуссии), просто не понял зачем я должен был про это здесь повторять, когда вы оба вроде бы в той теме были. А с GSerg'ом так мы вообще кое-что в привате обсуждали. Несмотря на то, что обсудили мало, но мне это очень помогло определиться с направлением.

[Approximator]

Кстати, кто-нибудь смотрел вот это:
http://www.vbstreets.org/Projects/LASM/Default.aspx
Правда, там всё запускается "по старинке", то бишь через CallWindowProc, может автору будет интересно наше мнение относительно его работы и наши варианты решения быстрее, чем CallWindowProc

[GSerg]

:)
А, то есть у тебя быстрее, чем один jmp?

Ну, во-первых, всё-таки не jmp, а call, или я опять не понял того, что вам было нужно?

Нэт
У меня ровно 1 jmp, причём устанавливается он 1 раз, после чего вызывается сколько угодно раз. Имхо, 1 jmp круче 2 call и даже 1 call Это просто для того, чтобы работало и из IDE, параллельно используется совсем другой, гораздо более медленный способ - но в exe он не попадает

А статья мне тоже давно не нравится

[tyomitch]

Я, значит, действительно с первого раза нихрена не понял. Сейчас понял. Ничего себе метод. Но наш (по крайней мере) ничем не хуже.
Чем тебе наш не нравится?

А ты попробуй эту идею много раз прогнать. В смысле поэксплуатируй этот код (jmp или call из произвольного места в произвольное место с во(и)звратом). Нормально?

Пожалуйста, не надо загадок. Если ты знаешь, чем он хуже, почему бы просто не рассказать об этом?
Именно это твоё стремление поучать, не обучая, я и имел в виду в фразе "Ещё раз, мы все на этом форуме, чтобы учиться."

Наш метод - без модификации ехешника - существенно круче \m/

Дык, "ваш метод" я давеча ужо обсуждал. А так я предложил функцию, аналогичную CallWindowProc, но быстрее. Не оценили.

Ссылки давай, искать лень. Тогда и обсудим.

Скажи честно, что не искать лень, а читать лень. Так в этой теме (но она не единственная, было ещё две) ты был. Вот здесь есть и про Read/WriteProcessMem и про доступ к сегментам кода в Run-Time и про флаги доступа к сегментам данных/кода в PE-файлах:
http://bbs.vbstreets.ru/viewtopic.php?t=8818&start=0

"Про Read/WriteProcessMem и про доступ к сегментам кода в Run-Time и про флаги доступа к сегментам данных/кода в PE-файлах" есть. А про вызов ассемблерных функций путём всего этого - нет. Так?

Ну, всё-таки, наверное, не ассемблерных, а маш. кодовых вставок. Про это я тоже говорил. Хотя и не уточнял, как именно - не было ни вопроса, ни необходимости. Да и я не оспариваю первенство (у GSerg'а на эту тему давно и статья имеется, правда, там всё было очень сыро, как в самом начале этой дискуссии), просто не понял зачем я должен был про это здесь повторять, когда вы оба вроде бы в той теме были. А с GSerg'ом так мы вообще кое-что в привате обсуждали. Несмотря на то, что обсудили мало, но мне это очень помогло определиться с направлением.

Говорил - где? Честно тебе говорю, мне интересно. В том топике, куда ты дал ссылку - нет.
Что вы обсуждали с GSerg-ом в привате, я не знаю. Если мне это важно, расскажи, - а если нет, зачем было упоминать?
А вызов вставок через CallWindowProc тоже была впервые придуман не GSerg-ом, а Оловянниковым, а может - даже и кем-то до него.

Что было, то и будет; и что делалось, то и будет делаться, и нет ничего нового под солнцем.
Бывает нечто, о чем говорят: 'смотри, вот это новое'; но [это] было уже в веках, бывших прежде нас.
Нет памяти о прежнем; да и о том, что будет, не останется памяти у тех, которые будут после.

[GSerg]

Ага
Я не претендую на первенство, хотя и сам нахожу решения

[Approximator]

:)
А, то есть у тебя быстрее, чем один jmp?

Ну, во-первых, всё-таки не jmp, а call, или я опять не понял того, что вам было нужно?

Нэт
У меня ровно 1 jmp, причём устанавливается он 1 раз, после чего вызывается сколько угодно раз. Имхо, 1 jmp круче 2 call и даже 1 call Это просто для того, чтобы работало и из IDE, параллельно используется совсем другой, гораздо более медленный способ - но в exe он не попадает

Пример здесь приведёшь? А то пока я никакого решения не видел, а со слов возможно тоже недопонял.

А статья мне тоже давно не нравится

Хм... Да, разве об этом речь?

[Approximator]

Я, значит, действительно с первого раза нихрена не понял. Сейчас понял. Ничего себе метод. Но наш (по крайней мере) ничем не хуже.
Чем тебе наш не нравится?

А ты попробуй эту идею много раз прогнать. В смысле поэксплуатируй этот код (jmp или call из произвольного места в произвольное место с во(и)звратом). Нормально?

Пожалуйста, не надо загадок. Если ты знаешь, чем он хуже, почему бы просто не рассказать об этом?
Именно это твоё стремление поучать, не обучая, я и имел в виду в фразе "Ещё раз, мы все на этом форуме, чтобы учиться."

Помилуй, дАрАгой, разве я сразу не указал проблему. На мой взгляд вставка в маш. кодах в тело процесса требует тщательного его debug'а. Во-первых необходимо знать произойдёт ли смещение и т.п. Просто так внутрь произвольного процесса тыкнуть jmp. Опять же вместо чего? А если не внутрь, то как к этому jmp'у обращаться?
Опять повторюсь, что говорю о локальной задаче - упрощении Call.
Так как, вместо того, чтобы тыкать где ни попадя jmp'ы можно было вообще организовать весь цикл (хотя бы при твоём тестировании "на производительность") в маш. кодах. Тогда изначально способ GSerg'а был бы быстрее...

Наш метод - без модификации ехешника - существенно круче \m/

Дык, "ваш метод" я давеча ужо обсуждал. А так я предложил функцию, аналогичную CallWindowProc, но быстрее. Не оценили.

Ссылки давай, искать лень. Тогда и обсудим.

Скажи честно, что не искать лень, а читать лень. Так в этой теме (но она не единственная, было ещё две) ты был. Вот здесь есть и про Read/WriteProcessMem и про доступ к сегментам кода в Run-Time и про флаги доступа к сегментам данных/кода в PE-файлах:
http://bbs.vbstreets.ru/viewtopic.php?t=8818&start=0

"Про Read/WriteProcessMem и про доступ к сегментам кода в Run-Time и про флаги доступа к сегментам данных/кода в PE-файлах" есть. А про вызов ассемблерных функций путём всего этого - нет. Так?

Ну, всё-таки, наверное, не ассемблерных, а маш. кодовых вставок. Про это я тоже говорил. Хотя и не уточнял, как именно - не было ни вопроса, ни необходимости. Да и я не оспариваю первенство (у GSerg'а на эту тему давно и статья имеется, правда, там всё было очень сыро, как в самом начале этой дискуссии), просто не понял зачем я должен был про это здесь повторять, когда вы оба вроде бы в той теме были. А с GSerg'ом так мы вообще кое-что в привате обсуждали. Несмотря на то, что обсудили мало, но мне это очень помогло определиться с направлением.

Говорил - где? Честно тебе говорю, мне интересно. В том топике, куда ты дал ссылку - нет.

Есть, и точно не меньше, чем здесь. Вы сами себя здесь перечитывали? Перечитайте.

Что вы обсуждали с GSerg-ом в привате, я не знаю. Если мне это важно, расскажи, - а если нет, зачем было упоминать?

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

А вызов вставок через CallWindowProc тоже была впервые придуман не GSerg-ом, а Оловянниковым, а может - даже и кем-то до него.

А это здесь причём? Блин, мы, что здесь будем подобной ерундой страдать? Меня интересует только нормальное решение.

[Approximator]

Есть предложение. Открыть топик на тему экстремального использования VB (mem/code/debug-сёрфинг). Там более менее подробно обсуждать возможные решения. Выкладывать код. Я появляюсь значительно реже вас обоих, потому оставлю создание топика за вами. Собственно это и покажет готовность к нормальной беседе. По данному вопросу меня волнуют не вопросы установления приоритетов, а эффективные решиния.

[GSerg]

Да ёлки
Иди в Трёп, тему сразу увидишь
Иди в Проекты, и там увидишь сразу

[Approximator]

Да ёлки

Ты про свой пример с jmp'ом чё-нить расскажешь?

[Approximator]

Да ёлки
Иди в Трёп, тему сразу увидишь

Здесь ничего не нашёл.

Иди в Проекты, и там увидишь сразу

Здесь, наверное, ты про это http://bbs.vbstreets.ru/viewtopic.php?t=9317

[GSerg]

Ага, про это
Так вот там в тексте есть ссылка на Треп

[Approximator]

Ага, про это
Так вот там в тексте есть ссылка на Треп

Ага, спасибо, нашёл. Это (в трёпе) то о чём вы здесь с Тёмычем говорили?

[GSerg]

Видать
Более того, оно и есть

[Approximator]

Видать
Более того, оно и есть

Посмотрел, есть небольшие замечания и ... пример, работающий быстрее. Сейчас у меня куча висяков. Потому выложу всё это там, как только освобожусь (в конце этой - первой половине следующей недели).

[Approximator]

Ну что, у меня выдалась свободная минутка. Я там ( http://bbs.vbstreets.ru/viewtopic.php?p=57141#57141 ) набросал примерчик. Любуйтесь.

[XPraptor]

Тема была как сдвиг написать, а народ академию развел, хотя сдвинуть в VB можно не медленне чем в C++:

A>>B
A And (2 ^ B)
A<<B
B And (2 ^ A)

[tyomitch]

Тема была как сдвиг написать, а народ академию развел, хотя сдвинуть в VB можно не медленне чем в C++:

A>>B
A And (2 ^ B)
A<<B
B And (2 ^ A)

Во-первых, не And, а *
Во-вторых, во втором примере вообще гон. У тебя получается, A>>B и B<<A - одно и то же.
В-третьих, я этот способ упомянул в самом начале топика. Неплохо бы сначала читать топики, на которые отвечаешь.
В-четвёртых, это всё же медленнее, чем в C++, из-за возведения в степень.
В-пятых, не знаешь - не умничай

[marvan]

2 GSerg
Далеко забрались, однако теперь неплохо сравнить скорость с этим
Сам бы поветил, но не разобался в "Полноценном вызове функций по указателю"

[XPraptor]

To tyomitch:
Во первых не * а именно And это самая быстрая операция, и в твоем примере в начале топика именно умножение, что приводит к замедлению в рассчетах при возведении в степень. А возведение в степень без предшествующих математических операторов - самый быстрый метод подсчета, And в данном случае не рассматривается компилятором как математический оператор перед возведением в степень и тормозить не будет. При компиляции, мой пример будет скомпанован в машинный код идентично тому как в C++ написан сам оператор сдвига в компиляторе. Так что господин tyomitch
сначала самому не мешало бы разобраться.

[tyomitch]

To tyomitch:
Во первых не * а именно And это самая быстрая операция, и в твоем примере в начале топика именно умножение

Ну что ещё тебе сказать?

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

Debug.Print 1 And (2 ^ 1) '1<<1, должно быть 2, выдаёт 0
Debug.Print 2 And (2 ^ 1) '2>>1, должно быть 1, выдаёт 2


Операция, может, и быстрая, только вот код твой не работает.

[XPraptor]

Ну товарищ tyomitch, ну не нужно же объяснять что это не операция сдвига байта, а операция получения битов самого байта после сдвига.
Для этого ведь и используется такая операция, чтобы данные в виде битов фигурировали в программе, что ускорит обсчет. А массив из 256 элементов для байта можно всегда загнать в память при старте.

[tyomitch]

Ну товарищ tyomitch, ну не нужно же объяснять что это не операция сдвига байта, а операция получения битов самого байта после сдвига.

Вот когда ты покажешь нам функцию сдвига байта, тогда и будем обсуждать её скорость. Что-то мне кажется, что склейка битов в байт на скорости скажется достаточно сильно.
Кроме того, про то, что твой пример "будет скомпанован в машинный код идентично тому как в C++ написан сам оператор сдвига в компиляторе". Ты хочешь сказать, что компилятор C++ при сдвиге разрезает байт на биты, сдвигает каждый, и потом их склеивает?

Заодно расскажи, зачем "массив из 256 элементов для байта". Ведь битов в байте, кажется, 8?

Два поста назад я тебе был "господин", а уже "товарищ"? Неплохо...

[XPraptor]

TO tyomitch:
Во первых: функции в коде и результат после компиляции это совсем разные веши, т.е. если в коде происходит разрезка на биты и склейка, то это не значит что после компиляции в машинном коде это будет происходить точно так же (читайте описание компилятора для языка). Операция определения битов в VB и операция >> в C++ в машинном коде будет иметь схожий код.
А что касается склейки и скорости то для этого и нужен массив из 256 элементов для представления уже имеющихся значений битов для каждого байта (чтобы не было никакой склейки)

[marvan]

ShiftLeft - оператор "<<" - 6 возможных реализаций
ShiftRight - оператор ">>" - 5 возможных реализаций
ShiftRightZ - оператор ">>>" - 8 возможных реализаций