информационная безопасность
без паники и всерьез
 подробно о проектеRambler's Top100
Атака на InternetПортрет посетителяСетевые кракеры и правда о деле Левина
BugTraq.Ru
Русский BugTraq
 Анализ криптографических сетевых... 
 Модель надежности двухузлового... 
 Специальные марковские модели надежности... 
 Крупный взлом GoDaddy 
 Просроченный сертификат ломает... 
 Phrack #70/0x46 
главная обзор RSN блог библиотека закон бред форум dnet о проекте
bugtraq.ru / форум / theory
Имя Пароль
ФОРУМ
если вы видите этот текст, отключите в настройках форума использование JavaScript
регистрация





Легенда:
  новое сообщение
  закрытая нитка
  новое сообщение
  в закрытой нитке
  старое сообщение
  • Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
  • Новичкам также крайне полезно ознакомиться с данным документом.
Не катит.. Ибо разбивать код 16-ти ветвей на более чем 80... 25.06.08 00:05  Число просмотров: 3944
Автор: Дон Амброзио Статус: Незарегистрированный пользователь
<"чистая" ссылка>
> > Так вот. Хотелось бы не переписывать каждый раз 50
> команд
> > во всех 16-ти ветвях, а просто указать директивой
> какой
> > кодовый фрагмент нужно взять за базовый и в каких
> местах и
> > что нужно заменить.
> Если разбить "некий вычислительный процесс" на несколько
> "неких вычислительных процессов", которые будут
> представлять из себя "до различия", "после различия" и
> собсно "во время различия" (которых будет несколько), а
> потом на основании флагов состояния ходить в определённый
> кусок кода с последующим возвратом?
> Понятно, что случай не общий, но приблизиться к решению
> задачи таким образом можно (а попутно мы также приближаемся
> к структурному, а затем к объектно-ориентированному
> программированию)

Не катит.. Ибо разбивать код 16-ти ветвей на более чем 80 малюсеньких подрограмм нельзя назвать удачным решением и упрощением программы
<theory>
Средства для упрощения создания полиморфных модификаций… 22.06.08 17:16  
Автор: Дон Амброзио Статус: Незарегистрированный пользователь
<"чистая" ссылка>
Посоветуйте средства для упрощения создания полиморфных модификаций фрагментов кода

Вопрос шибко заумный, но очень актуальный.

Попытаюсь объяснить, в чём суть. Надеюсь, что у меня это получится.

Объяснение построю на примере решения конкретной задачи.

Имеется 4 флага состояния некоего вычислительного процесса. Соответственно имею 16 возможных состояний вычислительного процесса. А значит 16 ветвей алгоритма. Пишу на АСМе. Но это не существенно для обсуждаемой проблемы – так как с подобными проблемами мы сталкиваемся при написании программы на любом языке: СИ, СИ++ и т.п.

Каждая ветвь представляет собой фрагмент кода, который отличается от любого другого из 16-ти в 3-4-х местах. Например, вместо команды SUBI, команда SBCI, или вместо регистра ZH в команде используется XH. Сам же размер кодовых фрагментов порядка 50-ти ASM-команд.

Так вот. Хотелось бы не переписывать каждый раз 50 команд во всех 16-ти ветвях, а просто указать директивой какой кодовый фрагмент нужно взять за базовый и в каких местах и что нужно заменить.

Макросами не получиться. Потому что изменения каждый раз в разных местах – получается более 30-ти параметров. Указывать при вызове макроса все его 30 параметров вряд ли можно назвать упрощением решения задачи.

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

Т.е. в каких-нибудь языках программирования средства, упрощающие и облегающие создание полиморфных модификации фрагментов кода? Если есть, то что это за средства.
Всё это очень похоже на процедуры\функции 24.06.08 15:09  
Автор: Ustin <Ustin> Статус: Elderman
<"чистая" ссылка>
> Так вот. Хотелось бы не переписывать каждый раз 50 команд
> во всех 16-ти ветвях, а просто указать директивой какой
> кодовый фрагмент нужно взять за базовый и в каких местах и
> что нужно заменить.
Если разбить "некий вычислительный процесс" на несколько "неких вычислительных процессов", которые будут представлять из себя "до различия", "после различия" и собсно "во время различия" (которых будет несколько), а потом на основании флагов состояния ходить в определённый кусок кода с последующим возвратом?
Понятно, что случай не общий, но приблизиться к решению задачи таким образом можно (а попутно мы также приближаемся к структурному, а затем к объектно-ориентированному программированию)
Не катит.. Ибо разбивать код 16-ти ветвей на более чем 80... 25.06.08 00:05  
Автор: Дон Амброзио Статус: Незарегистрированный пользователь
<"чистая" ссылка>
> > Так вот. Хотелось бы не переписывать каждый раз 50
> команд
> > во всех 16-ти ветвях, а просто указать директивой
> какой
> > кодовый фрагмент нужно взять за базовый и в каких
> местах и
> > что нужно заменить.
> Если разбить "некий вычислительный процесс" на несколько
> "неких вычислительных процессов", которые будут
> представлять из себя "до различия", "после различия" и
> собсно "во время различия" (которых будет несколько), а
> потом на основании флагов состояния ходить в определённый
> кусок кода с последующим возвратом?
> Понятно, что случай не общий, но приблизиться к решению
> задачи таким образом можно (а попутно мы также приближаемся
> к структурному, а затем к объектно-ориентированному
> программированию)

Не катит.. Ибо разбивать код 16-ти ветвей на более чем 80 малюсеньких подрограмм нельзя назвать удачным решением и упрощением программы
Чем более фундаментален кирпич, тем больше из него можно построить 25.06.08 09:45  
Автор: Ustin <Ustin> Статус: Elderman
Отредактировано 25.06.08 10:13  Количество правок: 2
<"чистая" ссылка>
> Не катит.. Ибо разбивать код 16-ти ветвей на более чем 80
> малюсеньких подрограмм нельзя назвать удачным решением и
> упрощением программы
Зато когда эти (подозреваю, что существенно меньше 80, состояний-то 16) подпрограммы будут написаны, можно будет макросами (а затем макросами макросов итд, т.е. квазиструктурно) сделать не только читабельное решение данного вычпроцесса, но и добавить к нему дополнительных ветвей без ущерба для мозга, времени, а также оптимальности результата
Состояний 16, а микропераций, на которые можно разбить 16... 25.06.08 14:15  
Автор: Дон Амброзио Статус: Незарегистрированный пользователь
<"чистая" ссылка>
> > Не катит.. Ибо разбивать код 16-ти ветвей на более чем
> 80
> > малюсеньких подрограмм нельзя назвать удачным решением
> и
> > упрощением программы
> Зато когда эти (подозреваю, что существенно меньше 80,
> состояний-то 16) подпрограммы будут написаны, можно будет
> макросами (а затем макросами макросов итд, т.е.
> квазиструктурно) сделать не только читабельное решение
> данного вычпроцесса, но и добавить к нему дополнительных
> ветвей без ущерба для мозга, времени, а также оптимальности
> результата

Состояний 16, а микропераций, на которые можно разбить 16 ветвей более 80-ти.. Так что не правильно подозреваете
Докладываю. 27.06.08 00:05  
Автор: Дон Амброзио Статус: Незарегистрированный пользователь
<"чистая" ссылка>
Докладываю.

Решил проблему с помощью препроцессорных директив #include и #define.

Удалось сократить размер исходника с 890 строчек до 278 строчек при упрощении его структуры и увеличении читабельности за счёт того, что явно выделены отличия порождаемых фрагментов от прототипа. Также удалось с помощью применения такого подхода наконец-то похерить все ошибки, возникавшие раньше из-за не внимательности при переписывании/копипастинге по 16 раз одних и тех же мелких кусочков кода. Также удалось увеличить лёгкость внесения изменений.

Реализовал парадигмы «объектно-ориентированного» и одновременно «порождающего» программирования. У меня в коде прототипа используются виртуальные метки, переменные, константы, …., вообще произвольные фрагменты текста исходника.

Сам прототип оформил как отдельный файл, а порождение его полиморфных модификаций реализовал так.

1.Линкуем виртуальные идентификаторы с помощью директив #define
2.#include “PrototipFile”
Ну а если просто передавать в качестве параметра enum и по... 25.06.08 09:19  
Автор: Heller <Heller> Статус: Elderman
<"чистая" ссылка>
Ну а если просто передавать в качестве параметра enum и по ходу кода понатыкать if'ов-switch'ей? (правда в АСМе это будет еще менее удобно).
1






Rambler's Top100
Рейтинг@Mail.ru


  Copyright © 2001-2021 Dmitry Leonov   Page build time: 0 s   Design: Vadim Derkach