-
- у 8086 префикс LOCK. а вообще-то ПО ХОРОШЕМУ :) следует обработчик писать так yes(99 знак., 15.08.2008 17:37)
- 68000 :-) Правда, это скорее "у какой была" - ReAl(27.07.2008 19:49)
- Я как-то всю жизнь 68k считал 32 битной архитектурой... -> - Evgeny_CD(27.07.2008 19:55, ссылка)
- Но именно 68000, если я правильно помню, АЛУ имел 16-битное и add.l выполнял вдвое дольше, чем add.w. Т.е. 32-битные операции именно у родителя линии выполнялись как "атомарные операции с 32 битами на 16-битном железе". Хотя я могу и ошибаться. - ReAl(28.07.2008 01:25)
- Т.е. 68000 на момент своего появления, пока не было всяких 680*0 - шина данных 16 бит, АЛУ 16 бит => 16-битный процесор, но может делать кучу атомарных 32-битных операций, для облегчения чего только лишь РОН были 32-битные. :-) :-) - ReAl(28.07.2008 01:44)
- "Новое - хорошо забытое старое"? - Evgeny_CD(28.07.2008 22:07)
- Т.е. 68000 на момент своего появления, пока не было всяких 680*0 - шина данных 16 бит, АЛУ 16 бит => 16-битный процесор, но может делать кучу атомарных 32-битных операций, для облегчения чего только лишь РОН были 32-битные. :-) :-) - ReAl(28.07.2008 01:44)
- Но именно 68000, если я правильно помню, АЛУ имел 16-битное и add.l выполнял вдвое дольше, чем add.w. Т.е. 32-битные операции именно у родителя линии выполнялись как "атомарные операции с 32 битами на 16-битном железе". Хотя я могу и ошибаться. - ReAl(28.07.2008 01:25)
- Я как-то всю жизнь 68k считал 32 битной архитектурой... -> - Evgeny_CD(27.07.2008 19:55, ссылка)
- А накуа атомарить не-i/o 32-битные операции? Если сохранение контекста и разделение ресурсов выполняется грамотно, то никакая атомарность и не нужна. В dsPIC есть багофича с невозможностью восстановления части статуса DSP-ядра, но и она прекрасно MBedder(43 знак., 27.07.2008 15:37)
- Штоб блокировок (и потерь времени на них) было меньше. Хотя вообще говоря, "атоммаривание" группы команд- самое грамотное решение в этой области. PIC24 рулят. Интересно, в C компилере от микрочип есть интрисик какой для поддержки этого Evgeny_CD(17 знак., 27.07.2008 18:00)
- у PIC24/dsPIC есть одна атомарная инструкция для 32-бит Alex B.(494 знак., 28.07.2008 00:31)
- Т.е. для "атоммаривания" вводишь некую команду, потом в симуляторе считаешь на готовом коде, сколько выполняется нужный тебе кусок, и затем подставляешь искомое значение? Тоскливо. За объяснение по поводу mov.d Ws, Wd спасибо! - Evgeny_CD(28.07.2008 01:29)
- ну я бы так делать не стал. Обновили версию компилятора, он соптимизировал получше и привед. Alex B.(138 знак., 28.07.2008 01:39)
- Да вот и я про то же. Ручной подбор - он всегда стремный. - Evgeny_CD(28.07.2008 01:40)
- ну я бы так делать не стал. Обновили версию компилятора, он соптимизировал получше и привед. Alex B.(138 знак., 28.07.2008 01:39)
- Т.е. для "атоммаривания" вводишь некую команду, потом в симуляторе считаешь на готовом коде, сколько выполняется нужный тебе кусок, и затем подставляешь искомое значение? Тоскливо. За объяснение по поводу mov.d Ws, Wd спасибо! - Evgeny_CD(28.07.2008 01:29)
- у PIC24/dsPIC есть одна атомарная инструкция для 32-бит Alex B.(494 знак., 28.07.2008 00:31)
- Штоб блокировок (и потерь времени на них) было меньше. Хотя вообще говоря, "атоммаривание" группы команд- самое грамотное решение в этой области. PIC24 рулят. Интересно, в C компилере от микрочип есть интрисик какой для поддержки этого Evgeny_CD(17 знак., 27.07.2008 18:00)