А что вам предпочтительнее - CISC или RISC?

Собственно - десктоп - на CISC, а сервер - на RISC, на десктопе нужны приложения, а от сервера мне немного нужно...

Когда говорят о приложениях, речь идёт об одном конкретном всем известном CISC, а не о CISC вообще.

Перефразируйте, я вас не понял.

Ну типа говорим CISC, подразумеваем х86.

Ну да, а под RISC я подразумеваю ARM.

Столпы индустрии ставят на ARM, а MIPS в конечном итоге выдавят даже из тех ниш, где он сейчас прозябает.

Планшеты на MIPS, телефон вон даже был. Активно используется в медиаплеерах, маршрутизаторах, телевизорах. Выползает ноутбук. MIPS сколько лет выдавливают, а он всё лезет и лезет.

Если посмотреть на процентное соотношение ARM и MIPS в планшетах, телефонах и ноутбуках, то станет ясно, что лезет, потому что закопать не могут, как следует.

Медиаплееры, маршрутизаторы, и прочая техника со скрытой прошивкой - то это как раз и есть ниша. ARM туда идёт неохотно, ибо дохода - чуть. SoC'и по доллару за пучок с узкой специализацией могут быть на какой угодно платформе, если стоят дёшево и готовые железки делаются миллионами. А основные деньги крутятся там, где гигагерцы и гигабайты.

Если посмотреть на процентное соотношение ARM и MIPS в планшетах, телефонах и ноутбуках, то станет ясно, что лезет, потому что закопать не могут, как следует.

Было много:ничего, стало много:оченьмало. Так что mips отгрызает.

прочая техника со скрытой прошивкой

Она у всех скрыта. И у большинства закрыта.

ARM туда идёт неохотно, ибо дохода - чуть.

ARM Ltd. вообще пофигу, они ничего в железе не производят.

SoC'и по доллару за пучок с узкой специализацией могут быть на какой угодно платформе, если стоят дёшево и готовые железки делаются миллионами. А основные деньги крутятся там, где гигагерцы и гигабайты.

Полагаю, что деньги делаются именно на массовых продуктах. http://www.xbitlabs.com/news/cpu/display/20120725200151_Two_Billion_ARM_Chips...

Они сделают процессоры для себя, ибо могут и не желают ни на кого оглядываться

В таком случае им ничто не будет мешать огородиться по самые помидоры — хомячью пофиг и Apple будет плюс, чтобы всякие красноглазые личности и ушлые компании не баловались с хакинтошами. Одна машина, одна ОС, одна Apple.

Инфраструктура для ARM практически готова - мелкомякоть сделала свою RT

Ой-ли? С RT ситуация далеко не четкая и не ясно взлетит или нет, тем более она не совместима со старым виндовым софтом. Что еще остается? Android? Какая у него killer-feature которая позволила бы применять его на рабочих станциях?

Посмотрит, к примеру, AMD на всё это шоу, прикинет объём денег, да и сделает

Сделает, если будет выгодно, то бишь если будет спрос, а спрос (среди массового потребителя) возможно будет только на ARM-based ноуты, ибо работать в теории должны дольше и греться меньше. Но учитывая то, что в последнее время повышенным спросом пользуются планшеты даже судьба ноутбуков в дальней перспективе остается неясной. В свое время AMD было выгодно утереть нос Intel и они сделали AMD64, продлив жизнь x86 еще на черт знает сколько лет, а не присоединились к Intel и HP чтобы допиливать Itanium.

Как только появится нормальный открытый рынок железа

Открытый рынок может появиться с открытой архитектурой. Сейчас же имеем черти что в виде кучи ARMов, каждый со своими заморочками.

Реально, кто бы мог силой пропихнуть ARM в качестве замены x86 это Microsoft, но даже если это случится такой ARM ни в каком месте не будет открытым.

А то доводится мне тут программировать умножение на avr на асме, так так заскучал по x86...

http://forum.codenet.ru/q32726/Асм, Алгоритм умножения#

Попробуй сделать так:
 Пусть есть a и b (представляешь их себе в двоичном виде), которые нужно перемножить, и есть c - приёмник результата (он по сути должен вместить результат произведения). a (или его замена) тоже должен быть таким же вместительным, что и c. Далее идёт цикл:

 1) Сдвигаешь b вправо на один бит. 
2) Смотришь, если при сдвиге произошёл перенос - тогда добавляешь a к c;
 3) Сдвигаешь a на один бит влево;
 4) Если b ещё не ноль, переходишь к пункту 1.

Я в итоге так и сделал. Факт в том, что с конандой умножения получается сильно проще, а также быстрее работает.

Она у всех скрыта. И у большинства закрыта.

Я имел ввиду технику, про которую пользователи вообще не задумываются, есть ли там прошивка, и надо ли её менять.

ARM Ltd. вообще пофигу, они ничего в железе не производят.

Зато бабла на лицензиях делают столько, сколько MIPS и не снилось.

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

Точно. Только массовые продукты - не обязательно сверхдешёвые SoC для мелочёвки. 4×Krait - тоже массовый продукт, ибо продаётся десятками миллионов. А прибыли с каждого такого процессора - как с нескольких десятков дешёвых. А MIPS на этот рынок уже не попадёт. Разве что ARM сделает какую-нибудь глупость из ряда вон.

В следующий раз бери ATMega48. Они стоят сопоставимых с tiny денег, и имеют маленькие габариты. Там есть аппаратный умножитель.

А вообще - написал бы сюда раньше, тебе бы дали готовую процедуру умножения, она состоит из пары десятков команд. Если быстро умножать не надо, то вполне нормально.

В таком случае им ничто не будет мешать огородиться по самые помидоры — хомячью пофиг и Apple будет плюс, чтобы всякие красноглазые личности и ушлые компании не баловались с хакинтошами. Одна машина, одна ОС, одна Apple.

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

Ой-ли? С RT ситуация далеко не четкая и не ясно взлетит или нет, тем более она не совместима со старым виндовым софтом.

Совместимость нужна не столь многим, как ты думаешь. А вот полная интеграция всего и вся с серверными продуктами от мелкомякоти, офисный пакет, являющийся стандартом де-факто, беспроблемная работа в уже существующей корпоративной среде, понятность техперсоналу (аппаратная платформа поменялась, принципы работы и методы экплуатации те же) - всё это решает. Выскажу крамольную мысль - для бурного старта арму не хватало только винды и мелкомякотного офиса. А теперь они есть.

Открытый рынок может появиться с открытой архитектурой. Сейчас же имеем черти что в виде кучи ARMов, каждый со своими заморочками.

Сам по себе ARM открыт. Вопрос в периферии, которая является интеллектуальной собственностью третьих фирм. Но это будет поправимо, если начнётся рост рынка. Прибегут Amd и Nvidia, вполне может быть, что и всякие зомби вроде S3 или Matrox захотят вернуться на рынок под шумок. А в конкурентной борьбе наличие полных спецификаций и широкая поддержка железа - одно из преимуществ, особенно, если нет других.

К слову - я б с удовольствием отнёс денег конторе, которая сделает видеокарту пусть и с тормозным 3D, но с быстрым и идеально работающим 2D и стабильными открытыми драйверами, и холодную. Мне 3D вообще не упёрлось на ноутбуке, а вот получить лишние пару десятков минут работы я был бы не прочь.

Я имел ввиду технику, про которую пользователи вообще не задумываются, есть ли там прошивка, и надо ли её менять.

Телефон, ноутбук, компьютер, кофеварка. «Что? Какой линукс? Не надо нам никаких линуксов, и так всё работает.»

Зато бабла на лицензиях делают столько, сколько MIPS и не снилось.

Кстати, сколько? А то этих ARM'ов столько, что я даже не знаю, где смотреть. У MIPS что-то около $48e6.

А прибыли с каждого такого процессора - как с нескольких десятков дешёвых.

А это всё под NDA идёт же. Откуда у тебя такие сведения?

Для меня atmega явно избыточно - мне надо считать средний период между срабатываниями датчика, умножить его на нужный процент, и через полученное время после срабатывания давать искру.

Да я уже управился, теперь трудности в другом уже, в обеспечении правильности алгоритма

Кстати, сколько? А то этих ARM'ов столько, что я даже не знаю, где смотреть. У MIPS что-то около $48e6.

Что нарыл за пару минут - плановая прибыль за 2012 - 860M$.

А это всё под NDA идёт же. Откуда у тебя такие сведения?

Примерно представляю, как распределяются прибыли при производстве микросхем. Для новых железок отчисления могут быть очень большими и поштучными, ибо там и норма прибыли очень велика. А на какой-нибудь примитивный М0 или М3 могут за сумму порядка единиц или десятков тыщ баксов дать безлимитную лицензию. Думаю, Миландр именно так и лицензировался.

Полагаю, если на переговорах грамотно прикидываться незаможником, можно получить лицензию почти нахаляву. Уверен, что дешёвые китайские армы именно так и лицензировались. :)

Систему зажигания клепаешь? На мой вкус, туда мега - самое то. Разница в цене копеечная, зато потом не придётся изгаляться, если надо будет привернуть функционал. Элементарно - датчик напряжения АКБ, датчик температуры, датчик давления, вторую свечу (третью, четвёртую)… Да мало ли что. А у tiny13 всего 5(6) доступных ног.

Скажи что делаешь, аксакалы, глядишь, и помогут. Тут дофига крутых разрабов.

Да.

Мой алгоритм таков:

есть 3 состояния:

0) idle

1) ждем указанное время. Когда дождались, включаем ток через катушку, загружаем время работы катушки в таймер и переходим в состояние 2

2) ждем. когда время истекло, выключаем катушку. В этот момент проскакивает искра. Переходим в состояние 0.

Также на каждом тике таймера мы увеличиваем на 1 счетчик времени.

Есть датчик. Он срабатывает в НМТ. Когда он срабатывает, мы запоминаем счетчик времени, делим его пополам, чтобы найти время до ВМТ. И счетчик сбрасываем в 0. Т.о. мы меряем период, и поделив его, получаем полпериода. При этом я также усредняю его с средним значением периода.

Затем полпериода умножаем на число (256-УОЗ)/256, где УОЗ меняется от 0 до 255 - 0 дает зажигание в ВМТ, 255 в НМТ.

Из полученной величины вычитаем время, необходимео чтобы катушка набрала ток. И эту величину записываем в таймер. И переходим в состояние 1.

Баг же заключается в том, что иногда проскакивает 2 искры. При этом это не помеха от первой искры, которая бы перезагрузила МК. В этом я убедился, когда в самом начале инициализации моргаю свободным контактом. Когда 2 искры, он не моргает.

вторую свечу (третью, четвёртую)

мопед.

Элементарно - датчик напряжения АКБ, датчик температуры, датчик давления

отдельным контроллером. В первом время критично.

Машинный стек если ты про него он же в памяти, конечно медленно.

в x86 уже нет. начиная с itanium образца 2005го ЕМНИП.

В принципе, алгоритм понятен. Куча вопросов по реализации. Можешь выложить исходник, или как-то ещё им поделиться?

отдельным контроллером. В первом время критично.

Не настолько. Если возьмёшь мегу, сможешь считать аппаратно, там есть 16-битный таймер. Для твоей задачи точности в 16 бит - за глаза. Тогда же и переходы между состояниями можно делать аппаратным сравнением, там оно, если мой склероз не спит с другим, тоже есть. То есть, процессор вообще будет простаивать. Используешь второй таймер на низкой скорости, чтобы несколько раз в секунду опрашивать датчики. И ещё останется место, чтобы вывести всё это на ЖК или послать по последовательному порту в другое место, опросить несколько кнопок, и вообще сделать много полезного.

Плату переделывать я уже не буду, тем более, что место на ней у меня ограничено. Поставлю мегу отдельно, и буду заливать/сливать информацию по 3-м проводам.

http://pastebin.com/zS4XJ4kg

Для меня atmega явно избыточно - мне надо считать средний период между срабатываниями датчика, умножить его на нужный процент, и через полученное время после срабатывания давать искру

Электронное зажигание? Если да, то всегда хотел фичу, в виде кнопки - спорт/эконом.

Ага, оказывается на мопед. Следующую версию делай для двигателя с инжектором. И обязательно с несколькими режимами работы.

ZISC

</thread>

И в чем преимущества?

набора команд как такового нет. А вообще это был толстый троллинг.

Для ассемблера cisc конечно же, для c/c++ без разницы.

Я лично выбираю CISC. А насчёт RISC... не знаю, не доверяю я как-то ему.

Ну и как же управлять таким процессором?

http://www.kevindowd.com/zisc.txt

http://www.kevindowd.com/zisc.txt

Похоже на прикол. Эта вундервафля была кем-то реализована или применена на практике?

https://github.com/jteeuwen/ZISC-vm

В железе видимо нет.

Что во фьюзы шьёшь?
Какова расчётная длительность цикла (мин/макс)?
Что за датчик НМТ - холл?
В какой момент проскакивает вторая искра - замечал?

fuse не менял.

датчик оптический.

со второй искрой видимо была радионаводка от искры на усилитель датчика, в результате чего программа считала что каждый следющий период вдвое короче предыдущего и иногда это давало вторую искру

вобщем, сейчас программа такая:

http://pastebin.com/ve81ZgyH

в ней пока нет умножения на угол

датчик оптический

Да, может звенеть. я сначала удивился, зачем холлу защита от дребезга, они обычно со встроенным триггером Шмидта делаются.

со второй искрой видимо была радионаводка от искры на усилитель датчика

Была? Теперь нет? Как поборол?

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

Да, может звенеть. я сначала удивился, зачем холлу защита от дребезга, они обычно со встроенным триггером Шмидта делаются.

ну я в основном проверяю, замыкая пальцем)) Просто датчик смонтирован на подкову генератора, а она здоровая и неудобная

Ты не ответил, какая у тебя длительность цикла расчётная? Мин/макс частота вращения коленвала какая? Защиту от разноса делать не думаешь?

Время я храню в трехбайтной величине, таймер тикает 512 или 4096 раз в секунду, Так что минимальная частота 3*10^-5 в одном и 2.4*10^-4 в другом случае герц.

Максимальная ограничена таймером

Думаю, не сократить ли до двухбайтного

Если принять максимальную частоту вращения 6000 об/мин (условно, циферка удобная), то получается, что импульсы с датчика НМТ поступают с частотой 100Гц. Если счёт ведётся с частотой 512Гц, то дискретность измерения на максимальных оборотах - примерно 70°. Если 4096 - около 9°. Многовато, не? Даже если максимальная частота вращения меньше, всё равно погрешность значительна.

Минимальную частоту вращения, полагаю, можно определить, как 300 об/мин (думаю, стартер медленнее не крутит). Всё, что медленнее, можно считать остановом, бессмысленно зажигать искру на таких малых оборотах. Исходя из этого, можно определять максимальную расчётную длительность цикла - 200мс. Если частота прерываний от таймера - 4096Гц, то при длительности цикла 200мс максимальное значение твоего счётчика - ~820.

Итого - третий байт, вероятно, не нужен. И частоту прерываний я бы сделал побольше.

UPD: ну вот, мы пришли к одному выводу.

Где крохотный стек? В стандарте Си вообще ни слова о стеке не сказано.

Где крохотный стек? В стандарте Си вообще ни слова о стеке не сказано.

в tiny он крохотный, аппаратный на 3 значения. Особенно на С не разбежишься, 3 уровня вложенности для вызовов функций и всё

У современных tiny стек лежит в ОЗУ. Можно устанавливать размер на свой вкус. Я обычно ставлю 8-16 байт. Аппаратный стек на 3 значения был у первых tiny, они уже давно никем не используются.

У меня таки дошли руки поковырять твой код… Короче, я ни хрена не понял. :) Вот мой вариант - он на базе подобной разработки нескольколетней давности, которая в серию не пошла. Вечерком причесал… Если будешь использовать - скажи о результатах, любопытно. Собственно, код и комментарии.

Был ещё вариант с датчиками разрежения и температуры - он позволяет получить близкое к идеалу опережение для любых условий, лучше только с датчиками кислорода. Но думаю, тебе это не надо…