Для этого есть C++/C#.. ?

Есть. И С++, и C#, и перл, и жаба. Все это есть. А где есть место ассемблеру? Только в _asm клочках глубоко внутри С/С++ кода? Или, все таки, как самому мощному из всех системному языку + с великолепной возможностью реюзать тщательно отлаженные и самые быстрые по скорости клочки кода, а?

2volodya:
во! краткость сестра таланта! вот что значит опыт! именно это я и пытаюсь донести до людей! а мне все: "юзай си, а асм не трож, это только для извращенцев у которых времни навалом и делать им нечего."

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

2Asterix:
и делфи ещё есть, но ты же сам говорил, что даже в самой маленькой проге полная бредятина, да и не надо путать встроеный ассемблер с просто ассемблером, ну попробуй в делфях сегмент определить.

а и вот ещё что:

как самому мощному из всех системному языку + с великолепной возможностью реюзать тщательно отлаженные и самые быстрые по скорости клочки кода
+ возможность изучать и изменять исходные коды библиотек

Что вообще говоря тоже важно.

И еще. Мне тут некоторые необразованные темные личности в приват написали (привет, van) :), что, мол, ты ж сам плевался на .if/.elseif в MASM32. Так вот, я на них и сейчас плююсь. Не стоит путать прибаханые макросы и ООП. Класс-то ведь можно и нормально написать внутри. И геттеры/сеттеры написать разумно. И будет такой грамотно спроектированный и хорошо написаный класс пользоваться популярностью. Причем, без всяких макросов, однако, для этого нужна сильная поддержка компилятора.

JaDS
А вот это даже я не одобряю, подкладывать асм под сишные хедеры - бррр. Это конечно упростит жизнь, но лучше напрячься и переделать под асм.

А много вы хидеров переделывали? К тому же, я говорю про ПОБОЧНЫЙ ЭФФЕКТ - он практически бесплатный должен получиться, хотя исправлений там все равно хватит. Речь идет о некоторой совместимости форматов структур и все.

volodya
Причем, без всяких макросов, однако, для этого нужна сильная поддержка компилятора.
Где такой взять? С нуля писать что ли - сколько времени уйдет :(


Если не вылезит какая-нить непредвиденная бяка скоро положу простой пример с макросами на базе примитивного класса окна. Про геттеры/сеттеры я еще и не думаю даже :)

Тестировать макросы на FASM - жуть. Почти вслепую все..


Asterix
Как там те инклуды? Есть нарекания? ;-)

S_T_A_S_

Я ещё не попробовал, дело в том что я отказался, пока, от использования MMX в своей программе, но от твоих макросов крышу сносит - это точно... ;-)

S_T_A_S_
Уже избавился. Не для всех случаев ...
Если "базовых классов" несколько и они имеют члены с одинаковыми именами?

JaDS
Начинал я, значит намек на меня? я прально понял?
Правильно.

И где это я такую глупость спорол?
Твои доводы за ООП - глупость. Создается впечатление, что ты понятия не имеешь для чего нужно ООП.

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

Все твои доводы можно свести к тому, что тебе не нравится код генерируемый высокоуровневым языком поддерживающим ООП.

volodya
Класс-то ведь можно и нормально написать внутри.
Если не класс, то в принципе нельзя написать нормально?
Кулаки-то держи, а глупости зачем повторять. :(

Imho ассемблер нужен, чтобы выжимать из процессора(ов) максимум, а ООП подразумевает универсальный (избыточный) подход.

"..а ООП подразумевает универсальный (избыточный) подход..."


А можно подробнее об этом универсальном подходе?

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

Эта операция никоим образом не исключает выжимание скорости из процессора. Просто легче мыслить на объектном уровне.

А вообще-то в литературе по оптимизации написано, что самые лучшие результаты получаются при правильном проектировании, а не при 'вылизывании' тактов. Есть и исключения, но очень их мало.

2q_q: 1) ты передергиваешь мои слова, 2) я уже обещался на эту тему не спорить.

2S_T_A_S_:
такой вопрос может подскажешь, я чтото не догон.
1) определить подмакрос в макросе:

macro M
{
    macro SubM
    macroB
        db "test"
    macroE
}

macroB  fix     {
macroE  fix     }


M ; причем без этой команды не пашет, автоматом всё лишнее выкидывает:)
SubM  

2) Определить подмакрос который начинается в одном и заканчивается в другом (вот это я не могу):

macro begin
{
        macro   SubM
        macroB
}

macro end
{
        macroE
}

begin
end

выдает сообщение об ошибке, вообще это и понятно, можно ли это обойти? (по проще плиз, с коментами, если возможно конечно:)

AsmGuru62

На мой взгляд ООП нужен чтобы взять существующий код (... класс) и приспособить его для новых задач.
Выглядит так будто существующий код (класс) первичен по отношению к возникающим задачам. Будто программист сидит и думает, куда бы еще приспособить (возможно, доработав) уже готовые решения. На самом деле сначала появляется задача, ее предметная область описывается при помощи объектов и их взаимоотношений, и только потом можно смотреть есть ли уже готовые решения (например, классы).

А можно подробнее об этом универсальном подходе?
Из предыдущего предложения вытекает, что, либо надо каждый раз писать новые классы, либо наполнять существующие новой функциональностью, которая не требовалась в предыдущих задачах. Отсюда появляется библиотека/иерархия объектов имеющих богатую функциональность, которая востребована не во всех задачах использующих эти объекты.

'вылизывании' тактов - это последний этап оптимизации.

JaDS
ты передергиваешь мои слова
Только цитирую.

я уже обещался на эту тему не спорить
Нет аргументов?

Интересует низкоуровневая организация деления когда делитель > 128 бит. Целочисленая. Как можно подробнее как арифметика для детей. Когда делимое большое - тогда понятно. А делитель? К Кнутам не отсылать. Отвечать прямо здесь.

q_q
Если "базовых классов" несколько и они имеют члены с одинаковыми именами?

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

Imho ассемблер нужен, чтобы выжимать из процессора(ов) максимум

IMHO, ассемблер - это просто аппаратно зависимый УНИВЕРСАЛЬНЫЙ язык программирования. Сфера его использования ограничена лишь типом процессора. А так же личными предпочтениями.

'вылизывании' тактов - это последний этап оптимизации.

Вот сдесь я хочу сделать некоторое отступление от темы..
Существующая модель: процесор обрабатывает команды, а эти команды и данные хранятся в памяти - это конечно разумный исторически сложившийся подход..
Но не точный. Процессор не работает с памятью!! Он работает ТОЛЬКО с кешем.
А вот как использовать такую модель? Тут только асм..



JaDS
M ; причем без этой команды не пашет, автоматом всё лишнее выкидывает:

Все правильно. Макрос М при своей работе создает новый макрос. Пока первый не отработает, то второго просто нет - он еще не создан.

Определить подмакрос который начинается в одном и заканчивается в другом

macro begin	name
 {	macro   name
	{	;;  открывающая скобка макроса name
 }

end	fix }	;;  закрывающая скобка макроса name

begin	BYE	;;  macro   BYE {
xor	ebx, ebx
invoke	MessageBox,ebx,'thank you','terminated',ebx
invoke	ExitProcess, ebx
end	;;  }

BYE	;;  выполняет 2 invoke ^^

The Svin
[OFFTOP ON]
Я бы посмотрел HAC (Handbook of Applied Cryptography www.cacr.math.uwaterloo.ca/hac/), я краем уха помню, что там было что-то, метод Монтгомери, например (который ты в своем Magic Divider-e использвал).
Исчо вспомнил, неплохое описание было в статье Fast RSA implementation, автор Koc.
В общем по криптографии надо смотреть - там большие числа все равно используются - думаю, найти можно.
[OFFTOP OFF]