А я бы рисовал примерно так: code_14060.txt
Не побоюсь показаться неоригинальным - схема себе, и - схема. Если забыть про BackEnd, конечно же
На один DoData больше... Да ну и фиг с ним, мне более симметричное - более и понятно. В основном пытался, чтобы связи не просто "можно было отследить", но чтобы они были очевидны
В прямом смысле - чтобы видно было именно очами, без употребления мыши
Ну и конечно, Хитрый_FOR - это должен быть один элемент, а не результат тупого копипастинга

да, более наглядно. Исходная схема полностью повторяла пример с википедии с оптимизацией совсем уж глупых кусков, которые там были испольованы

А я даже и не разбирался... Типа: фрактал??? Ну нехай себе фрактал
------------ Дoбавленo в 22.50:
Кстати, вот вам и пример портирования - каждый может сам посчитать соотношение строки_кода/количество_элементов

немного подумав, получаем тоже самое в исполнение FTCG
code_14065.txt

если бы не отсутствие MathParse можно бы было уложиться в 30 кубов. Ну зато в 5 раз быстрее чертит чем решение на стандартной элементной базе

Красотища какая, щас распечатаю на работе род стекло положу

...

Мдааа... Красиво говорил, особенно, последние слова



Похоже, что это стало уже не его участью...

Подождем что скажет автор.
А то возьмет и выкрутится....как например г-н |_|утин.

эти тоже не плохи

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

Dilma, "Кто старое помянет тому глаз вон"

Взрослые люди, казалось бы должны понимать, получив дозу убойного наркотика под названием "HiAsm" что только не толкнёшь с бронивичка
Давичи не так давно в этом топике Вы Dilma заявили что HiAsm это язык программирования, вот тут я тоже чуть со стула не брякнулся
А Вы nesco и Ravilr вместо того чтоб травлей заниматься лучше бы подтянули свои познания в Вашем визуальном Delphi и не впаривали бы начинающим всякую ересь, даже я не удержался и нарисовал пару решений, (хотя давно этого не делал) только из за того, что такую бредятину переварить уже немогу. Хотя что Вам собственно до этого, Вы на этом ещё и конкурсы устраиваете. (извращенцы )

Можете угарать дальше.

Я тебя перестал травить, особенно, после последних твоих приступов сознания, это -- бесполезно.


Я промолчу, какую ересь ты тут несешь.


Тебе ясно и не двусмысленно было сказано автором проекта



С удовольствием, но без тебя

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

Если начать разбираться, чего, куда, и за каким лядом - и "классика" может работать быстрее: code_14075.txt

Ибо знание - сила.
------------ Дoбавленo в 20.10:
А если включить For.onBreakEnable=True, по onStop делать специальный цвет (например - красный), и по onBreak делать цвет как и раньше из индекса
-- будет красивше

если отрисовку пикселя в FTCG упрятать, то все же в 1.5 раза быстрее будет. Собственно с учетом этого апдейта схема FTCG под эмулятором рисует фрактал за 109мс.

Впрочем речь не об этом. Galkov, можно ли оформить какой-нибудь небольшой мануал по архитектуре FastMathParse? Есть желание туда кое каких операторов и функций добавить.

Если честно, сам нефига понять не могу
Нет, ну то, что в те стародавние времена я имел очень приблизительное понимание о бинарном представлении конструкций Дельфи - это видно буквально с первых же строк

Основная идея заключалась в том, что код не генерировался сразу, а "откладывался". Вместо конечного кода команды возвращалась "заготовка" для его генерации потом
Видимо коды составных частей, и код операции которую потом надо будет сгенерировать.
Почему потом - для целей оптимизации.
Скажем, получили результат C_plus_V - это означает что где-то (помимо этого кода) мы получили константу (посчитанную в compile-time), и некий код, формирующий результат в стеке (наверное!!! - еще есть результат в памяти, проверять надо).
Далее, по результатам парсинга оказалось, что надо сложить с чем??? - оказалось что с C_minus_A.
Чего мы делаем (видимо)...
Есть код, формирующий результат в стеке сопроцессора (это первый), и есть код, формирующий результат в памяти (это второй, наверное!!! - проверять надо)
Соединяем их, приклеиваем к полученной склейке еще и команду отнимания от стека содержимого памяти, складываем две константы, и этому всему добру присваиваем код C_plus_V

Вот как-то так....
Помню, что все это разнообразие приводит к нескончаемому потоку разборок. А еще ведь и целочисленные результаты надо "обмногообразить"
Функции - надо думать про inline/call, учитывать размер требуемого им стека.
Если функциональные обращения к схеме из формулы - полная непонятка со стеком сопроцессора (его размером)
В общем, оно и так "пухлое", а любая заморочка начинает раздувать его. Не пропорционально...
Ощущение такое у меня сложилось, что надо все переосмысливать заново.

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