Отдельный кэш для шлюзов, для мостов, и для переменных. Снова цикл с параметром.

[QUOTE]То есть вы решили подстроить процессор под программу,[/QUOTE]
Не под программу, а под то, как я программирую.
[QUOTE]Да, придется еще написать компилятор с ЯВУ[/QUOTE]
компилятор да, только ЯВА тут причём? Вообще не при чём.
[QUOTE]Сможете написать оптимизирующий не хуже чем GCC?[/QUOTE]
оптимизирующий что? Оптимищирующий машинный код? Машинный код у меня вполне упрощается за счёт отделения по кэшу даже циклов, а ЯП собственно, по уровню будет привязан к этому разделению, следовательно и оптимизация сложная требоваться не будет. Это будет совсем другая вычислительная машина, практически, разве что электронная и пока на двоичной логике, а там видно будет.
[QUOTE]Если нет, то все оптимизации в проце сведет на нет не оптимальная программа.[/QUOTE]
в программировании вопросы веры меня волнуют меньше всего.

Для кого-то может не понятно, насколько код упрощается за счёт отделения циклов от кода, как это влияет на программирование вообще. Это вообще другое программирование. Нет необходимости в привычных метках, неудобных, запутывающих и вносящих кучу неудобств и ограничений. Тут всё будет выглядеть иначе, и вообще не важно какая логика реализуется, цикличность наблюдается везде и во всём, циклы переплетаются с событиями по определённым законам. Это во всей наблюдаемой вселенной. Это даже больше будет похоже не на процессор, а на аппаратную среду. А насколько удачно я её разовью - другой вопрос.
Как минимум - противопоставляющийся алгоритм Брезенхема проиграл в эффективности к текущему ТЗ по генерации карт трассировок.

[QUOTE]Для кого-то может не понятно, насколько код упрощается за счёт отделения циклов от кода, как это влияет на программирование вообще. Это вообще другое программирование. Нет необходимости в привычных метках, неудобных, запутывающих и вносящих кучу неудобств и ограничений. [/QUOTE]
Чтобы было понятнее - нужен перевод кода. Хорошо, я как раз над этим работаю в свободное время.

Но сначала о мостах. Циклы - гейты, шлюзы, мосты связывают гейты с блоками исполняемого кода. И вот тут главное - мост определяет ячейку выхода. Это следует из этого участка кода
[PASCAL]{%REGION 'Engine'}
asm
JMP p
end;
p1:
StringGrid1.Cells[px^, py^] := IntToStr(pTracerX^) + ',' + IntToStr(pTracerY^) + ',' + '1';
//запись правого столбца
p := @p3;
goto p4;
p2:
y1:=y+1;
//автоматическое забивание координат в местах скоса трассы
p := @p3;
goto p5;
p3:
y1:=y;
p5:
x1:=x-xInc;
StringGrid1.Cells[px^, py^] := IntToStr(px1^) + ',' + IntToStr(py1^) + ',' + '0';
//автоматическое забивание координат трассы на прямых участках
p4:
x:=x+xInc;
{%ENDREGION} [/PASCAL]
Тут не получится избежать меток, если мост не будет содержать информации о выходе с блока кода.
Зато если мост содержит её - то всё легко и без меток, легко и естевенно.
детали о коде тут [url]https://habr.com/ru/articles/769972/[/url]
Информация о мостах должна содержаться ... точно не в кэше блоков кода... .
В ввиду модификаций она должна была-бы содержаться в кэше переменных... с учётом того что мосты могут изменяться в ходе модификаций, но ...
мосты - не переменные величины... архитектура не простая... модификации в кэше циклов лучше не проводить. Задачка. Четвёртый кэш совсем не хочется делать. Информацию о мостах можно хранить в кэше переменных, но после них. Это как вариант.
Зато становится очевидным, что увеличение количества кэшей может сократить емкость хранимой инофрмации необходимой для работы аппарата, при этом увеличивается число команд такого процессора... Тут нужно подумать.

Ну во первых ничего в моём коде не сведёт оптимизацию. Оптимизация аппаратная по максимуму будет.
Думать о собственно было не о чем, на предмет мостов, достаточно было определить их формат хранения и функционирования, чтобы понять (где их данные будут храниться и как выводиться), что мосты будут так-же как и код - блоками, если надо, а если нет - не блоками. Мосты - основное средство модификации программы.
Изначально задумывалось, что мост будет указывать на начало блока кода в кэше кода и на его окончание. Следовательно аппаратно под мосты нужно выделить две шины, чтобы мосты работали за один такт, с одной шины пойдёт на адрес в кэш на считку первой ячейки. Сам блок кода в кэше мостов активироваться будет по обычной адресации, но выходить данные будут первые, по отдельной шине, на начало в кэш кода, вторые сразу на регистр слежения за точкой останова.
То-есть мосты имеют вдвое увеличенный кэш, две шины. Та что соединяет кэш мостов с регистром слежения, будет служить для ожидания сигнала от процессора - команды.
В публикации правка, скрин схемы. Описание в публикации после изображения.
[QUOTE=Usaga;bt33836]А нельзя программировать как все? Чтобы не нужно было тратить время и ресурсы на изобретение собственных процессоров? Или цель не результат (программа), а что-то другое?[/QUOTE]
[QUOTE]Для чего я это делаю? Для чего не знаю, знаю почему - потому что алгоритм Брезензема проиграл в текущем ТЗ генерации карт.[/QUOTE]
Вы-же не задумываетесь, когда вам холодно - зачем вы одеваете тёплую одежду. Не зачем вы одеваете тёплую одежду, а почему : потому что есть причина - холод. Так и тут.


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

[QUOTE=Usaga;bt33845]Если продолжать аналогии, то твой подход - при холоде начать проектировать фабрику пошива одежды,[/QUOTE]
-
не точно, точно:
сшить одежду с своего материала, пусть даже это будет шкура мамонта - мне не важно.
[QUOTE]Если алгоритм плохо работает[/QUOTE]
[B][I]Мой алгоритм отлично [U][COLOR="Red"]не работает[/COLOR][/U][/I][/B]: достигает тот-же результат по ТЗ что и алгоритм Брезенхема мне навязываемый, при выполненном объёме работ по расчётам в разницу [B][I]x*y - (x+y)[/I][/B], а результат количественно - одинаковый, равен [B][I]x*y[/I][/B].
Удачи.
Обычные процессоры очевидно под другие алгоритмы, которые выполняют столько работы, сколько вряд-ли когда требовалось вообще для достигнутых результатов. Суетяги - одним словом. Мне зябковато в вашем мире бесполезной суеты (в мире вашего программирования, жить можно, но одежку нужно с своего материала иметь).

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