[]

masquer,
Правильный топик ON, муть OFF.
Во первых, метод Монтгомери использывал Половников, у меня свой метод :) Но подход схожий. Обнаружена модульная зависимость разрядных частей при делении умножении и найдена функция определения этой зависимости для конечных участков.
Во вторых это для констант годится.
Замаешься это динамически делать с делителем произвольной длины и содержания.
В третьих никак не поможет с длинным делителем.

В четвёртых сам отвечай :))

Вот у тебя делитель в скажем 4*800*8 бит. 800 двойных слов.
И делимое в мегабайт двойных слов.
Что будем делать?
Подробное объяснение и арифметические выкладки для тупых
в OПП Свинах приветсвуются.

Вообще прикольно это ОПП для низкого уровня.
Это типа что, то
MyInstruction.modrm.codrfield==110
Так что-ли?

The Svin
В четвёртых сам отвечай :))
Тяжело мне самому отвечать :) Я серьезно все это не смотрел, была задача, но потом обошлось без этого - так, в памяти осталось чуть-чуть :)
С ходу не скажу по теме, но подумаю (я иногда жалею, что вышку прогуливал :)).
Надо бы исходники Miracl еще глянуть - межет там чего есть...
Может, лучше отдельную тему завести?

то типа что, то MyInstruction.modrm.codrfield==110
Ага, это уже будет ООП - ниже некуда :)

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

The Svin
Особено интересно как ОППа будет защищать мой код от меня самого работая с объектом длинный делитель нефиксированного размера.

Вот это я не знаю :(

А вот это я уже начал понимать:

mov	eax, [foo]
call	foo_proc
.....
mov	eax, [foo+4]
call	foo_proc2
.....
mov	eax, [foo+8]
call	foo_proc2


И:

mov	ebx, offset foo
mov	eax, [ebx]
call	[ebx+proc]
.....
mov	eax, [ebx+4]
call	[ebx+proc2]
.....
mov	eax, [ebx+8]
call	[ebx+proc2] 

Т.е. в каких-то случаях вполне оправдано просто собрать некоторые DWORDы в одно место и экономить память на опкодах-операциях с ними. Вот и все.

Дык таблицы указателей на функции.
Это что как то за ОПП кто-то пытается закрепить :)
Тогда таблица векторов прерываний тоже ОПП :))

The Svin

Это типа что, то
MyInstruction.modrm.codrfield==110
Так что-ли?

Во-во, вы угадали: в ia-64 есть эта гребаная ооп-нотация, например:
br.ret.sptk.many r5
- значит "бранч типа ret, независимо от предсказания загрузить инструкции в кэш, причем много":))

Valery
:))))))

Вообще прикольно это ОПП для низкого уровня.
Это типа что, то
MyInstruction.modrm.codrfield==110
Так что-ли?

Забавно, Свин. А поумней что-то выбрать можно было? Давайте я словами бацнутый примерчик приведу. Немного, прадва, поумнее вашего будет. Просто так. Итак, есть строка. А есть функция, которая парсит строку в поисках, ну, чего-нибудь. Плевать чего. Строка может быть юникодовской - ага, UTF-16, два байта на символ. Строка может быть юникодовской UTF-8 - ага, уже один. Строка может быть ASCII (стандартная ISO-1251) - еще один случай. Строка, опять-таки, может быть ASCII, но уже в KOI-8 или в чем-нибудь еще. Теперь как можно поступить. Для того, что вы называете "ОПП" подход будет одним, для того, что вы назвыаете "структурным прогарммированием", подход будет другой. В структурном программировании у меня есть только один выход - написать кучу процедур, с разными названиями для обработки каждого случая (ну, или одну процедуру, очень умную, которая сама будет детектить тип строки и обрабатывает ее соответственно - для данного случая это достаточно просто, только и пример-то ведь детский). А для ООП подход может быть и другим. Вариант - перегрузка функции. Вариант - костяк в виде виртуальной фунции, которая переопределяется в классах-потомках. Причем последний вариант невероятно удобен. Я знаю общую концепцию, я понимаю главный принцип, а детали реализации определены в соответствующих методах.
Простите, наверняка я говорю очевидные вещи, но, Свин, ей богу, если все ваше понимание об ООП заключается в MyInstruction.modrm.codrfield, то грош такому представлению цена, если честно. Мы же говорим об альтернативной концепции, ином мышлении (заметьте, я не говорю "новом", я говорю "ином"), которое предполагает другой стиль программирования и, как любят говорить мои англоязычные друзья, very well scalable.

Удалил всё нафиг. Так вот.
:))

Вух. Я ждал какого-то подобного ответа :)
Свин, многое из того, что вы сказали - это правда. Только я бы хотел задать вопрос. Цитируя вас же:

потом глядишь - эти же люди начинают радостно вопить - ура я нашёл способ чтобы писать не
push 0
call ExitProcess
а ExitProcess(0)
с помощью макросов
Правда?! Быть не может! Ураа!

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

Я сам к макросам отношусь очень негативно. Я не люблю их и не высоких языках, ни, тем более, в асме. Труп страуса говорил, что использование макроса подтверждает дефект языка. Я не готов пока спорить на таком концептуальном уровне, но, в глубине души, без особой зубодробительной документации, я с ним согласен. Макрос - это бяка.

Но, Свин, возвращаясь к нашим баранам. Ясный пень, в асме не мне с вами равняться. Но даже мне хотелось как-то бы написать программу быстрее, немного проще. Упаси господи, не используя макросов, гадость это, а как бы так-нибудь, ну, побыстрее, короче!

Ну и отвечу на один из выпадов:

"Костяк виртуальной функции" - это что такое в мире
низкого уровня

Указатель на некоторую область памяти, содержащую указатели на функции либо оффсеты на данные. Чаще всего виртуальная функция преобразуется в нечто в виде call [reg+xx]

со своим внутренним сложным форматом, который описать с помощью ОПП забодаешься

И опять двадцать пять. Да растуды вас в качель с вашим опкодом, мать его за ногу и через забор.
ОК, вы писали СУБД. Рад за вас. Флаг в... и ветра в... Попутного.
Есть задачи, требующие ООП, есть - нет. ООП - это образ мышления, а не конкретные столь любимые вами байтики и битики.

Моё крестьянское мнение - низкий уровень для снятия абстраций, как ты только вводишь абстрацию - он скрывается. То что при этом будет использоваться ассемблерный транслятор - сути не меняет

Что ж. Возможно. Хотелось бы услышать еще пару аргументов. Я не слишком тверд пока в своих убеждениях. Я только против того, чтобы ООП вытягивали на макросах - это уебище будет в прямом смысле этого слова. Но о чем говорит сама тенденция писать макросы, а?

Удалил всё нафиг. Так вот.

Ну и зря.

Макросы, конечно, неплохо иметь для ускорения написания кода. Но делать ООП с помощью макросов - это, наверное, излишне... А что, моя идея скриптового Ассемблера никого не задевает? А что там не так? Какие есть неудобства?

JaDS && volodya
Судя по вашему задору, у вас есть конкретные идеи по сабжу?
Почему бы тогда не озвучить их, чтобы услышали все
присутствующие в этой студии?
Прототип синтаксиса такого языка? Еще что-то?

All
Зачем создавать новый ассемблер, писать макросы для "расширения" возможностей асмов уже существующих и т.д. и т.п. ?! IMHO, если человеку лень ввести с клавиатуры лишний мнемоник (push 0), ему ассемблер не нужен. А ООП можно реализовать и на чистом асме (без макросов, но со структурами :-) Я описываю класс на масме примерно так:

; Class:
; ------
; Generic - abstract class on top of the whole hierarchy
Generic STRUCT
 ; Pointer to methods
 methods        dd ?
 ; Attributes
 X0             dd ?
 Y0             dd ?
 dWidth         dd ?
 dHeight        dd ?
Generic ENDS

; Generic methods
Generic_tbl STRUCT
 destroy_ptr    dd ? ; destructor
 draw_ptr       dd ?
 hittest_ptr    dd ?
 save_ptr       dd ?
Generic_tbl ENDS
Generic_destroy PROTO ptr_this:DWORD
Generic_hittest PROTO ptr_this:DWORD,xy:DWORD

"Наследование":

; Class:
; ------
; StaticTxt - extends Generic
StaticTxt STRUCT
 GEN            Generic <>
 ; Extended attributes
 color          dd ?
 caption        dd ?
StaticTxt ENDS

StaticTxt_tbl STRUCT
 GEN            Generic_tbl <>
 ; Extended methods
 ; nothing to add so far...
StaticTxt_tbl ENDS

Ну, и т.д. Наглядный пример полиморфизма на базе класса Generic:

; Draw the environment and all of it's objects
; Return: void
drawSpace PROC uses esi lpSpace:DWORD,hdc:DWORD
   invoke IsBadReadPtr,lpSpace,MAX_TOKENS * DWORD
   test eax,eax
   jnz @end
   mov esi,lpSpace
   mov ecx,MAX_TOKENS
@draw:
   lodsd
   test eax,eax
   jz @F
   push ecx
   push hdc   ; <- HDC
   push eax   ; <- ptr_this
   mov eax,(Generic PTR [eax]).methods
   ; Draw
   call (Generic_tbl PTR [eax]).draw_ptr
   pop ecx
@@:
   loop @draw
@end:
   ret
drawSpace ENDP

В общем, такой метод реализации ООП не очень отличается от модели by NaN & Exagon, но обратите внимание на отсутствие дополнительных макросов. Передачу this и вызов методов можно организовать и через регистры, но суть не в этом.