Состояний 16, а микропераций, на которые можно разбить 16...25.06.08 14:15 Число просмотров: 4648 Автор: Дон Амброзио Статус: Незарегистрированный пользователь
> > Не катит.. Ибо разбивать код 16-ти ветвей на более чем > 80 > > малюсеньких подрограмм нельзя назвать удачным решением > и > > упрощением программы > Зато когда эти (подозреваю, что существенно меньше 80, > состояний-то 16) подпрограммы будут написаны, можно будет > макросами (а затем макросами макросов итд, т.е. > квазиструктурно) сделать не только читабельное решение > данного вычпроцесса, но и добавить к нему дополнительных > ветвей без ущерба для мозга, времени, а также оптимальности > результата
Состояний 16, а микропераций, на которые можно разбить 16 ветвей более 80-ти.. Так что не правильно подозреваете
Посоветуйте средства для упрощения создания полиморфных модификаций фрагментов кода
Вопрос шибко заумный, но очень актуальный.
Попытаюсь объяснить, в чём суть. Надеюсь, что у меня это получится.
Объяснение построю на примере решения конкретной задачи.
Имеется 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