[amusin 0]

Да, конечно, для ARM надо сделать количество процессов - 32. Будет проще и быстрее.

Кол-во процессов scmRTOS_PROCESS_COUNT надо делать таким, сколько требуется, и не больше, т.к. внутри void OS::TKernel::SystemTimer() есть цикл for(byte i = 0; i < scmRTOS_PROCESS_COUNT; i++).Другое дело, что может быть действительно сделать TProcessMap 32-разрядным, хотя это и не вписывается в идеологию scmRTOS об экономии ОЗУ :).

Как вариант, ширину TProcessMap можно сделать по потребности, а ее уже приводить к 32 разрядам внутри GetHighPriority(), если позволит компилятор.

[Сергей Борщ 119]

Да, конечно, для ARM надо сделать количество процессов - 32. Будет проще и быстрее.

Кол-во процессов scmRTOS_PROCESS_COUNT надо делать таким, сколько требуется, и не больше, т.к. внутри void OS::TKernel::SystemTimer() есть цикл for(byte i = 0; i < scmRTOS_PROCESS_COUNT; i++).Другое дело, что может быть действительно сделать TProcessMap 32-разрядным, хотя это и не вписывается в идеологию scmRTOS об экономии ОЗУ :).

Как вариант, ширину TProcessMap можно сделать по потребности, а ее уже приводить к 32 разрядам внутри GetHighPriority(), если позволит компилятор.

Да, так и будем делать - размер TProcessMap минимально необходимый. Про 32 процесса с Гарри утрясли, про GetHighPriority() - для кол-ва процессов меньше 7 сделаю табличный метод - размер таблицы будет те же 64 байта для 6 процессоа, для меньшего кол-ва соответственно меньше.

 

Беру тайм-аут до выходных - в пятницу надо изделие на выставку отправлять а софт еще процентов на 40 написан.

[sergeeff 1]

Пара соображений по поводу быстродействия. Я эту идею уже как-то Harry предлагал, но он посчитал это изменение не слишком принципиальным. Тем не менее, считаю целесообразным переписать пару функций, которые многократно вызываются в ядре и scheduler’e:

 

void SetPrioTag(TProcessMap& pm, const byte pr) { pm |= 1 << pr; }

void ClrPrioTag(TProcessMap& pm, const byte pr) { pm &= ~(1 << pr); }

 

Эти две функции выполняются быстрее (короче аналога на одну команду) и отпадает необходимость в массиве TProcessMap PrioMaskTable[scmRTOS_PROCESS_COUNT+1] и функции TProcessMap GetPrioTag(const byte pr) const { return PrioMaskTable[pr]; }.

 

Выигрыш не велик – но все же – короче и быстрее.

[IgorKossak 0]

...Выигрыш не велик – но все же – короче и быстрее.

Если отпадает необходимость в массиве, то это, как по мне, уже достаточно весомый аргумент ЗА.

[dxp 33]

void SetPrioTag(TProcessMap& pm, const byte pr) { pm |= 1 << pr; }

void ClrPrioTag(TProcessMap& pm, const byte pr) { pm &= ~(1 << pr); }

 

Эти две функции выполняются быстрее (короче аналога на одну команду) и отпадает необходимость в массиве TProcessMap PrioMaskTable[scmRTOS_PROCESS_COUNT+1] и функции TProcessMap GetPrioTag(const byte pr) const { return PrioMaskTable[pr]; }.

 

Выигрыш не велик – но все же – короче и быстрее.

За счет чего выигрыш? У АРМа есть аппаратный сдвигатель?

[amusin 0]

 

Гарри, ты не добавил const в объявлении

TProcessMap PrioMaskTable[scmRTOS_PROCESS_COUNT+1]

чтобы не заморачиваться с инициализацией таблицы?

[GetSmart 0]

У АРМа есть аппаратный сдвигатель?

Конечно есть. Сдвигает регистр в 1-тактовой команде на любое количество бит.

[spf 0]

У АРМа есть аппаратный сдвигатель?

Конечно есть. Сдвигает регистр в 1-тактовой команде на любое количество бит.

Необходимо уточнить ГДЕ задается "любое количество бит".

Если в другом регистре то хорошо.

 

PS:

Имеются процы у которых количество бит сдвига задается в коде команды - любое но фиксированное.

[GetSmart 0]

АРМ имеет команды с обоими вариантами: как непосредственное число сдвига, так и из содержимого другого регистра.