Сообщество

Можно завести системный таймер и считать с частотой процессора.

Кстати, раз уж вы предлагаете прерывания (прочитать таймер ведь не атомарная операция?), есть ли какие-нибдуь отличия в обработке прерываний, по сравнению с классическими архитектурами?
Ведь в вашем процессоре, насколько мне помнится, вычисления начинаются "по готовности данных", неужели это актуально и для ввода-вывода?
Кстати, есть ли в процессоре кэш?
Да, я уже как-то тут высказывался, на тему, что в современных процессорах - прерывание, это просто апокалипсис для всех "механизмов производительности". И по моему мнению, в большинстве случаев, прерывание вообщ не нужно, а нужен некий симбиоз DMA и ввода-вывода, что бы когда на определённый порт поступят даныне, DMA их директом копирнул в нужную ячейю или по смещению, можно ещё время в тактах для контроля в пару приписывать, если нужно. А процессор, уже прерываясь по мере надобности, сразу бы обрабатывал целую кучу данных напиханных DMA в память. При этом, выборка данных из внешних источников (реакция процессора) получается практически мгновенной, в плане обработки сигналов, это хороший плюс.

VaalKIA wrote:

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

В мультиклеточной архитектуре обработка прерываний немного отличается от классических архитектур.
Как выглядит обработка прерываний на ассемблере:
В регистр #IHOOKADDR кладем метку параграфа - обработчика прерываний, в #MSKR устанавливаем маску для нужных нам прерываний, разрешаем прерывания установкой нулевого бита #PSW.
Механизм обработки прерываний сейчас следующий:
1) если в параграфе выполнилась команда записи, то параграф доработает до конца и потом мы перейдем на параграф обработки прерываний
1) если в параграфе команда записи ещё не выполнилась, то мы сразу переходим на обработчик прерываний
После выхода на обработчик прерывания устанавливается запрет прерываний, т.е. нулевой бит #PSW очищается.
Перед выходом из обработчика прерываний необходимо разрешить прерывания в #PSW, возврат из обработчика происходит по регистру #IRETADDR.

Как выглядит обработка прерываний на Си:
Для поддержки прерываний в Си реализованы некоторые функции в подгружаемом к Си проектам файле crt0.s (или crt0.o).
В своей программе на Си мы задаем обработчик прерываний, например так:
set_irq_vector(interrupt_GPTIM0, IRQ_VECTOR_GPTIM0); // interrupt_GPTIM0 - пользовательский обработчик прерываний от системного таймера
Устанавливаем маску asm_setl_MSKR((1<<IRQ_VECTOR_GPTIM0)|(1<<IRQ_VECTOR_ADC0);//устанавливаем маску прерываний GPTIM0, ADC0

Также в crt0.s реализован первичный обработчик прерываний, который определяет адрес обработчика прерываний(если он установлен) и осуществляет переход на него, подкладывая в качестве адреса возврата из пользовательского обработчика прерываний свой параграф для выхода из обработчика с включением разрешения прерываний.

Кстати, есть ли в процессоре кэш?

Одной из особенностей нашего процессора является то, что кэша нет.

Да, я уже как-то тут высказывался, на тему, что в современных процессорах - прерывание, это просто апокалипсис для всех "механизмов производительности". И по моему мнению, в большинстве случаев, прерывание вообщ не нужно, а нужен некий симбиоз DMA и ввода-вывода, что бы когда на определённый порт поступят даныне, DMA их директом копирнул в нужную ячейю или по смещению, можно ещё время в тактах для контроля в пару приписывать, если нужно. А процессор, уже прерываясь по мере надобности, сразу бы обрабатывал целую кучу данных напиханных DMA в память. При этом, выборка данных из внешних источников (реакция процессора) получается практически мгновенной, в плане обработки сигналов, это хороший плюс.

У нас это можно сказать, что реализовано в R1). Наш DTC умеет по прерываниям от периферии перекладывать данные из регистров периферии или из памяти в нужные ячейки.

Одной из особенностей нашего процессора является то, что кэша нет.

Я считаю - это преимуществом, слишком много сложностей вносит кеш в работу, это можно посмотреть просто по развитию языков программирования, которые уже навернули просто мощнейшие инструменты хоть для какого-то контроля этого дела. По мне, так современный уровень элементной базы, позволяет просто разбить память на два участка - быструю и помедленней, если вспомнить, что 2МБ ещё совсем недавно, было достаточно для запуска винды (95ая это вполне современный продукт, хоть и морально устаревший), а 4-16Мб это уже было супер, и сравнить это с современными кэшами (Xeon E7-8893 v3 4 ядра 45Мб кэш L3), которые за 16Мб легко могут перепрыгнуть (было бы желание), то вообще непонятно, почему не сделать таким образом и пусть уже софт решает, что имеет смысл поместить в быструю память, что пусть лежит в обычной: прекрасный прозрачный механизм управления "кешем", плюс проц поставляется уже с оперативкой и сразу готов к работе. И логичное продолжение SSD, котоыре уже по скорости доступа равны DDR2 800.. и скоро будут просто продолжением оперативки с энергонезависимым эффектом (это, кстати, на заметку, почему x64 надо обязательно делать).

У нас это можно сказать, что реализовано в R1). Наш DTC умеет по прерываниям от периферии перекладывать данные из регистров периферии или из памяти в нужные ячейки.

А смещение реализовано? То есть из одного регистра переферии может ли он класть каждый раз в следующую ячейку?

Так мне очень понравилась идея, реализованная некогда в БК0010, как правило, все процессоры предусматривают целый набор комманд, который по своей сути дублирует комманды работы с памятью, ориентированный на ввод-вывод. А в БК0010 просто отображались порты ввода-вывода на адресное пространство памяти, имея 32/64 битное пространство, отдать 64Кб-16Мб под порты ввода-вывода не является проблемой вообще, но как сильно упрощается процессор и полностью, весь мощный механизм работы с памятью, доступен для портов в неурезанном виде (а для портов его всегда урезают)!

И всё же получить атомарный счётчик, с разршением не хуже тактового сигнала и без всяких прерываний - было бы очень неплохо, в железе это реализуется просто, а для софта это очень удобно, возьмите хотя бы целые библиотеки на PC типа ZenTimer, которые учились подсчитывать промежутки времени (а не дату), и в конечном итоге в x86 вроде появились комманды позволяющие получать "время" в тактах. Да даже любые многозадачные ОС, оперируют квантами времени, а для вытесняющей многозадачности это вообще манна небесная. Даже в RND функции, про которую была целая история (типа тормоз Андроид) используется зачастую время. Возьмите на заметку этот момент: моменты времени и аппартный RND (тут надо не псевдо, а что-нибудь на физических процессах) это очень полезно и может значительно разгрузить многие алгоритмы.