я предложил тебе вариант ускорения, ты сказал, что это сложно. Если ЭТО для тебя сложно, то про конвеера и другие финты с памятью для тебя будут технологиями пришельцев из далёкой галактики.Сообщение от Bolt
бред который пишет Andrews я даже комментировать не стану.
Да, мне это сложно.
видимо не можете припомнить на вскидку ни одного алгоритма, который на zx spectrum выполняется дольше 100 мсек. или отклик с сервера у вас более 100 мсек. Дайте описание вашего акселератора функциональное. Если он у вас ускоряет обращение к памяти, то я не такие проблемы имел в виду. Такое умощнение мне не интересно! Под "тяжелыми процедурами" я понимаю такие, которые в разы и на порядок не ускорятся от оптимизации обращения к памяти.
Последний раз редактировалось andrews; 21.11.2019 в 21:28.
что за единица такая - мсек? миллисекунды? микросекунды? уточните. отклик от удалённой машины считается в миллисекундах (мс/ms). любые внутренние задержки которые требуется выполнить на машине так же считают обычно в миллисекундах, конкретно на zx spectrum требований к задержкам мало где требуется. но первое же место которое приходит на ум, это драйвер fdd и hdd. опять таки, я не понимаю вашу единицу измерения "мсек".
если у вас до вашего сервера время отклика 100мс, то у вас явно проблема с сетью/интернетом.
Да, миллисекунды, микросекунды ведь сокращаются мксек? Время отклика имелось в виду не тестового пакета при связи, а время от засылки входных данных до начала получения результата. А вообще все зависит от реальной скорости интернет, времени переключения на задание с аккаунта на сервере(там ведь должна быть инициализация-отведение ресурсов, включения кода в листинг исполняемых задач), собственное время выполнения "тяжелой процедуры" на сервере и времени передачи результата клиенту. Если взять Linux на сервер с обычным громоздким ядром, то параметры будут одни. Если облегчить его ядро и оставить только нужное для этих задач, то другие. Опять таки количество одновременно обслуживаемых подключенных клиентов. Вряд ли если их зарегится даже 10 000, все 10 000 будут онлайн каждую миллисекунду. Хотя надо встраивать статистику и вести лог, и в зависимости от этого или ограничивать регистрацию, или умощнять сервер. В общем, полагаю, что это не бред, хотя и не простая задача. Сейчас такое есть вроде только на суперкомпьютерах в университетах, да вот еще банки что-то такое в России начали делать( правда не представляю, туда ж специалисты нужны совсем иного профиля нежели чем те, которых они привыкли нанимать для своих задач). Либо надо ограничивать предметную область для вычислений. Ну и если строить софт правильно на локальном компе, то может быть просто комп, аксель на локальном компе, аксель на сервере. Причем перестроить задачу с учетом имеющихся возможностей не в процессе исполнения, а перед запуском всегда возможно. Ну это опять таки зависит от мощности компьютера-клиента. "Тяжелые процедуры" помечаются после профилера один раз, а несколько строк проверки "обстановки" сильно время выполнения всего кода не затормозит, а выигрыш при ускорении на другом акселе или сервере может быть существенное.
Последний раз редактировалось andrews; 22.11.2019 в 11:20.
Полгода не прошло, но можно подвести итог.
Сам по себе eZ80, как и другие модификации Z80, в том числе Rabbit, очень неплох. В каждой модификации Z80 есть своя фишка, но почему это не было доведено до ума, и зачем в каждой версии ломать совместимость, не понимаю. Почему нельзя было сделать внутренние порты так же перемещаемыми, как и внутренняя RAM? Почему убран #M1? Зачем добавлены несовместимые с Z80 инструкции с префиксами DD/FD?
Внешний MMU к нему прикрутить можно. Но остаётся доступ к портам, прерывания и прочее, что потянет за собой то же, что и в оригинальном Спектруме - прямой доступ программ к железу. При многозадачности в таких условиях будет такая же куча несовместимых между собой и с железом ОСей, софта, и т.д.
Была идея перехватывать чтение инструкций и заменять их, тем самым эмулируя обращение к портам и прочее, но у eZ80 нет #M1. Есть #INSTRD, что не то же самое, он активен при чтении любого байта кода. То есть при выполнении "ld A,(12345)" он активен на всех трёх байтах. Или на всех четырёх, см. ниже.
Далее возникла идея считать #M1 самому, но это было бы просто при фиксированной длине инструкций. У eZ80 есть 4 префикса и 2 режима работы, меняющих длину инструкций. Да, можно вбить в FPGA кучу таблиц и отслеживать текущий режим, но он может меняться при обработке прерываний. Ладно, это тоже можно обойти, но режим ещё может сохраняться в стеке и восстанавливаться из стека при вызове подпрограммы. Это как отслеживать? Или запретить "call" и "ret" с префиксами? Плюс к этому интересно выполняется инструкция "rst". Для syscall это хорошо, она, видимо, для этого и задумывалась, но она работает не как в Z80. Отслеживать и эмулировать ещё и её, вместе с эмуляцией недокументированных DD/FD? Далее количество заплаток, накладок, и потенциальных глюков начинает расти в геометрической прогрессии. Может тогда уже и правда проще eZ80 целиком написать?
В общем, проект многозадачного компьютера на eZ80 закрыт из-за нецелесообразной трудоёмкости и отсутствия времени на его реализацию.
И теперь я понимаю почему "взлетел" Intel, а не Zilog.
может если не получается поставить 1 современный ez80 на 50 МГц
подумать об установки 4-х старых cmos-ных z80 по 24МГц?
как раз будет и многозадачность
сделать 4 поля памяти
чтоб процы вайтились только когда обращаются в память друг друга
или 2-х процессорный вариант z80 + ez80
ну это моя давнишняя идея 1998 года навеянная HP системами с разнородными ядрами! Память ( а здесь еще и порты) делаются общими. Процессор- "партнер" выбирается, исходя из предпочтений пользователя(группы пользователей). Если это современный коммуникационный процессор, то кроме ускорителя это еще и wifi, и usb, и microSD, и BT. Старый софт пускается на z80, сервисы пристраиваются, новый пишется с учетом новых возможностей.
из 32 штук РУ5Г
и 8086, как мне уже предлагали.
Это будет многопроцессорность:
https://zx-pk.ru/threads/31260-mnogo...-spektrum.html
ну и на многопроцессорносте
как раз и возможно труЪ настоящаяя много задачность
- - - Добавлено - - -
ну дык материнки же имеют по 4 планки
Эту тему просматривают: 1 (пользователей: 0 , гостей: 1)
Ваши права
Ответить с цитированием