[haker_fox 61]

2 hours ago, jcxz said:

Не передаётся только номер после SVC. Так а кто заставляет его использовать?

Я под аргументом и подразумевал номер.

[adnega 11]

1 минуту назад, haker_fox сказал:

регистрах нет информации об аргументе.

Да. Но вы знаете текущий стек и его указатель. Идете туда, вычитываете стандартный кадр, а уже в нем вся подноготная.

2 минуты назад, haker_fox сказал:

Я под аргументом и подразумевал номер.

В стековом кадре будет значение PC. Пошаманив со смещением найдете адрес инструкции swс, а уже в ее теле будет номер.

[jcxz 243]

9 минут назад, haker_fox сказал:

Ну так я то про ассемблер. Я не использвал вызов и обработку SVC из СИ. Так вот, при вызове прерывания из ассемблерного кода, мы попадаем в вектор SVC, но в регистрах нет информации об аргументе.

Так занесите их туда. Перед вызовом. Точно так же как при вызове обычной функции. Хоть си хоть асм - какая разница? Механизм один.

[haker_fox 61]

9 minutes ago, adnega said:

В стековом кадре будет значение PC. Пошаманив со смещением найдете адрес инструкции swс, а уже в ее теле будет номер.

У меня такое ощущение, что я об этом и говорил 

 

2 minutes ago, jcxz said:

Так занесите их туда.

Простите, зачем? Если этот номер (ранее мной неточно названный аргументом), можно найти в обработчике из кода команды.

[adnega 11]

5 минут назад, haker_fox сказал:

У меня такое ощущение, что я об этом и говорил

SVCHandler:
	tst				lr, #4
	ite				eq
	mrseq			r3, msp
	mrsne			r3, psp
	ldr				r1, [r3, #24]
	ldrb			r0, [r1, #-2]
	cmp				r0, #2
	it				hi
	bxhi			lr
	tbb				[pc, r0]

svc_func_table:
	.byte	((svc_func_timer_set - svc_func_table) / 2)
	.byte	((svc_func_timer_tick - svc_func_table) / 2)

svc_func_timer_set:
	ldr				r0, [r3, #0]
	ldr				r1, [r3, #4]
	str				r1, [r0]
	str				r1, [r3, #0]
	bx				lr

svc_func_timer_tick:
	ldr				r0, [r3, #0]
	ldr				r1,	[r0]
	add				r1, #10
	str				r1, [r0]
	str				r1, [r3, #0]
	bx				lr

	.global	svc_timer_set
svc_timer_set:
	svc	0
	bx	lr

	.global	svc_timer_tick
svc_timer_tick:
	svc	1
	bx	lr

Вместо тысячи слов...

[jcxz 243]

11 минут назад, adnega сказал:

Спора никакого нет. Я изначально сказал, что SVCall - это исключение, и для него справедливы все правила исключений.

Похоже Вы так ничего и не поняли...

SVC - это СИНХРОННОЕ исключение. В прошлый раз выделил, сейчас ещё и напишу большими буквами. Именно из-за того что оно синхронное, а не асинхронное (как некоторые другие) оно и выполняется именно так: вызывает блокировку если его невозможно выполнить немедленно. Для асинхронных исключений это правило не действует. Какие исключения являются синхронными, а какие нет - смотрите мануал на ядро - там есть табличка. Так что "всех правил" для исключений - нет, они разные.

11 минут назад, adnega сказал:

Вы же начали обсуждать частные случаи. Вот их и обсуждаем.

Я вообще-то всего-лишь сказал, что если хочется вызывать SVC вместо функций, то запрещать fault-ы нелья:

2 часа назад, jcxz сказал:

Есть ограничение вызова SVC от обычных функций: обычные можно вызывать при запрещённых fault-ах, но если так попытаться сделать с SVC, то очень поплохеет.

Против чего Вы вдруг начали спорить:

2 часа назад, adnega сказал:

Конечно нет - ядро блокируется. Запрещение fault`ов тут ни при чем.

 

11 минут назад, adnega сказал:

Насколько вам известно, исключение SVCall можно возбудить двумя способами: соответствующей инструкцией (синхронный) и через pending-бит NVIC (асинхронный).

Мне это неизвестно. Где я такое писал???   Да и разработчикам ядра Cortex-M - тоже неизвестно. Объясните - как именно можно вызвать SVC "через pending-бит NVIC (асинхронный)."?

Ещё раз: SVC - это синхронное исключение. Ну не бывает оно асинхронным!

 

11 минут назад, adnega сказал:

Я утверждаю, что асинхронный вызов SVCall не должен никак повредить системе даже с "запрещенными" fault`ами. А вы?

Мне неизвестно ядро где SVC - асинхронный. Просветите нас о каком ядре ведёте речь???

В Cortex-M вызов SVC при запрещённых (через FAULTMASK фаултах приведёт к блокировке CPU). Это по вашему значит "не должен никак повредить системе"?  

 

11 минут назад, adnega сказал:

Замаскировать NMI-обработчик невозможно. Отключить все возбудители NMI - даже обсуждать не стоит в силу очевидности.

Ну ясно - значит вам просто охота поспорить не важно о чём.....

38 минут назад, haker_fox сказал:

Я под аргументом и подразумевал номер.

"Аргумент" - это то что можно передать в функцию. Номер после слова SVC - это часть команды SVC. Это не только моё мнение, но и авторов IAR например. См. "#pragma swi_number".

[jcxz 243]

38 минут назад, haker_fox сказал:

Простите, зачем? Если этот номер (ранее мной неточно названный аргументом), можно найти в обработчике из кода команды.

Затем что кто-то говорил:

3 часа назад, haker_fox сказал:

т.е. вызыван будет обработчик по адресу SVC. Аргументы при этом через регистры не передаются!!!

Передавать аргументы в обработчик SVC можно точно также как в обычных функциях. По-крайней мере те аргументы, что влезают в регистры. Никакое тело команды не нужно. И если рассматривать интерфейс IAR для SVC-функций - там именно так и поступают:

#pragma swi_number=SVCF_trap0
__swi void trap1(u32);
#pragma swi_number=SVCF_trap1
__swi void trap2(u32, u32);
#pragma swi_number=SVCF_trap2
__swi void trap3(u32, u32, u32);

Итого объявляется 3 функции: trap1(), trap2(), trap3(). Вроде всё предельно ясно. Всё передаётся через регистры. А разные номера SVC - это разные функции.

[adnega 11]

22 минуты назад, jcxz сказал:

Ещё раз: SVC - это синхронное исключение. Ну не бывает оно асинхронным!

Использовать SVC в асинхронном виде - смысла, конечно же, лишено, но.

Есть такой регистр System handler control and state register (SCB_SHCSR).

У этого регистра есть rw-бит с номером 15:

Bit 15 SVCALLPENDED: SVC call pending bit, reads as 1 if exception is pending.

Описание бита имеет такую сноску:

Pending bits, read as 1 if the exception is pending, or as 0 if it is not pending. You can write to these bits to change the
pending status of the exceptions.

Осмелюсь предположить, что запись в 1 бита 15 регистра SCB_SHCSR должно спровоцировать исключение с обработчиком SVCall.

Повторюсь, практического смысла в этом ноль, проверять - не проверял, но истина дороже.

[adnega 11]

Проверил - прекрасно возбуждается.

void SVCHandler(void)
{
	con_str("{SVCall}\n\r");
	con_start();
}

void func_scall(void *p)
{
	asm("svc #0");
}

void func_acall(void *p)
{
	SCB->SHCSR = (1 << 15);
}

Имею лог:

Цитата

>scall
{SVCall}
>acall
{SVCall}
>

 

[jcxz 243]

18 минут назад, adnega сказал:

Осмелюсь предположить, что запись в 1 бита 15 регистра SCB_SHCSR должно спровоцировать исключение с обработчиком SVCall.

И что? Осмелюсь предположить (исходя из принципа работы всех синхронных исключений), что если в данный момент SVC можно выполнить, то оно выполнится и бит снимется тут же, а если выполнить нельзя - CPU заблокируется, а этот бит установится (а может просто ничего не произойдёт). 

Да и при чём тут этот бит запроса? Разговор вроде был про команду SVC.

[adnega 11]

7 минут назад, jcxz сказал:

Да и при чём тут этот бит запроса? Разговор вроде был про команду SVC.

Нет - разговор был про SVCall-исключение.

Про асинхронность SVCall вы не знали - рад, что вы для себя сегодня открыли что-то новое.

[jcxz 243]

2 минуты назад, adnega сказал:

Про асинхронность SVCall вы не знали - рад, что вы для себя сегодня открыли что-то новое.

Откройте наконец-то мануал на ядро Cortex-M и найдите таблицу: "Table 2-16 Properties of the different exception types". Найдите в ней столбец "Activation".

Если не согласны с ней - спорьте с разработчиками архитектуры. Мне спорить с Вами - пустая трата времени, Вы же лучше знаете как работает Cortex-M лучше тех кто его разрабатывал.  

11 минут назад, adnega сказал:

Нет - разговор был про SVCall-исключение.

Да я уже понял что передёргивать Вы умеете. И бессмысленно тыкать в историю этого треда - любой может прочитать о чём был разговор.

[adnega 11]

Только что, jcxz сказал:

Если не согласны с ней - спорьте с разработчиками архитектуры.

Я вас понял.

void func_scall(void *p)
{
	asm("svc #0");
}

void func_acall(void *p)
{
	SCB->SHCSR = (1 << 15);
}

if(fcall)
{
	fcall = 0;
	asm("cpsid f");
	SCB->SHCSR = (1 << 15);
}

if(xcall)
{
	xcall = 0;
	asm("cpsid f");
	asm("svc #0");
}

Исход такой:

Цитата

>scall
{SVCall} - обычный синхронный вызов

>acall
{SVCall} - "недокументированный" асинхронный вызов

>fcall
>{SVCall} - запретили fault`ы и спровоцировали "недокументированный" асинхронный вызов. Все ок.
xcall - словили блокировку.

 

 

Мое представление архитектуры по этому вопросу оказывается полностью соответствует поведению железа.

[jcxz 243]

18 минут назад, adnega сказал:

Мое представление архитектуры по этому вопросу оказывается полностью соответствует поведению железа.

К чему эта портянка что выше? о чём она и для чего? ничего не понятно...  

Так Вы до сих пор считаете что:

4 часа назад, adnega сказал:

Иначе: можно ли вызвать исключение из исключения?

Конечно нет - ядро блокируется. Запрещение fault`ов тут ни при чем. Или я вас не понял.

Так при чём или не причём запрет fault-ов? Вам уже удалось вызвать SVC при запрещённых fault-ах?  

Приведите код который это позволяет сделать. Чтобы мы могли его проверить. Именно код позволяющий сделать вызов обработчика SVC при запрещенных исключениях, а не ту невразумительную портянку, что выше. Пускай даже через этот бит SHCSR, а не через обсуждавшуюся команду.

[adnega 11]

5 минут назад, jcxz сказал:

Именно код позволяющий сделать вызов обработчика SVC при запрещенных исключениях

			asm("cpsid f");
			SCB->SHCSR = (1 << 15);