Не спорю, их мало, но практически все они очень качественные и интересные игры. Серия TW отлично себя чувствует, анонсирует новые масштабные дополнения и про консоли даже не задумывается. Серия OFP (arma) анонсирует новую часть и новые симуляторы, о консолях так же не задумывается. Diablo III вроде тож только на ПК

Видимо вы не знаете сколько их на ПК выходит

Ну если все доходы от подписки сложить, может до половины суммы дотянут

Хочется выделить одно преимущество архитектуры x86 перед любыми другими - это непревзойденный уровень однопоточной производительности (если не брать в рассчет атом и бульдозер). То, что AMD отказались от этого преимущества во многом и определило провал бульдозера в ПК. И, вероятно, это путь к проигрышу архитектере ARM. В обозримом будущем в применяемом на ПК программном обеспечении будет достаточно много кода, который в силу сложности алгоритмов плохо поддается распараллеливанию (к примеру, MS Word). Так что говорить о смерти x86, пока она сохраняет преимущество в однопоточной производительности, явно преждевременно.

умные: 1. знают что разрядность данных и адреса не тождественна.
2. умеют напрягать мозг, чтоб отделить кратко-сказанное главное , а не упираться в недосказанное (в силу обьёма полной инфы).
3. понимают, что есть физическая реализация в кремнии и логическая (она же програмная. модель) и только програмная модель эксплуатируется человечеством в виде реализации програмным кодом разных алгоритмов. Эксплуатировать физическую реализацию напрямую невозможно - это как ездить на машине с двигателем, кузовом и колесами но без руля и педалей. Декодер 286(586) мог бы вполне существовать полностью самостоятельно , но реально он сосуществует как часть.(почему см. выше).
4. как декодируется ASM в микрокоды - для тех, кто посообразительней пример:
CISC_команда INC [memWord100] (микропрограмма из 3 микрокоманд)
его реализация в RISC (который практически однозначно обязывает 1 asm команде иметь 1 микрокоманду)
Load reg1, [memWord100] (1 микрокомандa)
INC reg1 (1 микрокомандa)
Store [memWord100], reg1 (1 микрокомандa)
преимущества RISC - при прерывании откатывается 1 выполнямая команда (у CISC вся микропрограмма),
почти НЕТ декодера, полная ясность с оптимизацией времени исполнения (легче настроить логику транслятора с языков выс.уровня.)

Похоже, что многие участники дискуссии и ПРАВДА не знают, что НЕ ВЫПОЛНЯЮТСЯ коды разных квазиХ86 процессоров друг на друге, каждый на своём, просто искусно сделано переключение между разными процами (режимами в терминах интел). листинги 286 и 386 с примером кода одной команды "B8":
2 P286
3 0000 model SMALL
4 NOWARN BRK
5 locals @@
6 0000 CODESEG
7 0000 B8 1122 mov AX, 1122h
--------------------
1 IDEAL ; DEMO + pascall stdcall syscall
2 P386
3 00000000 model FLAT
4 NOWARN BRK
5 locals @@
6 00000000 CODESEG
7 00000000 B8 11223344 mov EAX, 11223344h
8 00000005 66| B8 1122 mov AX, 1122h

7 строки содержат команду с кодом B8, но она в зависимости от проца 286/386 загружает или 16 AX или 32 EAX регистр и имеет РАЗНУЮ длинну. Чтобы на 386 проце загрузить 16бит регистр AX надо добавить префикс изменения разрядности операнда - 66h (строка 8).

Имеющие голову да подумают, как несовместимые программы можно лихо "выполнять" на другом проце?
Вот они "костыли" на почве гениальности.

Добавлено спустя 35 минут 27 секунд:


НеоспАриваемая истинна. Cейчас х86 - это RISCsb в обертке 86.
Обертка только тормозит, Интел может её сменить на ARM и будет
скорость sandy на командах ARM, как сказал Cannon "intel забьёт на x86 и переключится на ARM и там продолжит убивать конкурентов".

И еще они знают что разрядность шины адреса к разряности процессора никакого отношения не имеет.
8086 имеет 16-разрядные РОН и 20-разрядную шину адреса. И это 16- а не 20-разрядный процессор.
Аналогично, 8080 имеет 8-разрядные РОН и 16-разрядную шину адреса. И это 8- а не 16-разрядный процессор.
Итого: 80286 - процессор 16-разрядный, чтобы там peresw ни нафантазировал себе.


Ну никак ассемблер в процессоре не декодируется, совсем никак. Процессор имеет дело исключительно с машинными кодами. Точка. Ассемблер - это язык программирования, символьное представление машинных команд, но не сами команды. А тот кто не понимает разницы - очевидным образом не разбирается в вопросе.


Откатывается? Ctrl-Z? Undo? Не?

Для сусликов от IT поясню. При прерывании, а также при любом вообще непредсказанном или неправильно предсказанном переходе сбрасывается весь конвейер. ВЕСЬ. И у RISC и у CISC. (Единственное известное мне исключение - EPIC Itanium)
А поскольку во многих RISC-процессорах конвейер по длине не уступает х86 - то соответственно равное количество команд и сбрасывается, независимо от архитектуры, ога.




Имеющие голову умеют выражаться гораздо яснее. DOS программы, написанные в незапамятные времена, прекрасно выполняются на процессорах 386 и 486, без добавления префиксов, о которых такие программы, естественно, не ведают ни сном ни духом. Уверен (хотя и не проверял) что эти же программы будут прекрасно работать и на Sandy Bridge.


Не будет, декодер не является чем-то совершенно отдельным как от вычислительной части, так и от ISA.
Так что скорость Sandy Bridge для ISA ARM возможна только для заново спроектированного процессора с соответствующими затратами времени и денег.


"Блестящее владение родным языком - это мой первый критерий отбора будущих программистов" Э. Дейкстра.

К г-ну peresw к сожалению это не относится.

Он использует термины, значения которых не понимает ("откатывается 1 выполнямая команда"). Смешивает разные понятия (например, "assembler" и "машинный код", "разрядность шины адреса" и "разрядность процессора"). Делает массу банальных орфографических ошибок.

Да уж, с Docent2006 каши не сваришь. Как грится чукча писатель. Нет у меня времени.

Подумать, человек на комп форуме открывает свет про "разность ASM и маш.кодов." ? Ему видите-ли непонятно.
Пара перлов " При прерывании, а также при любом вообще непредсказанном или неправильно предсказанном переходе сбрасывается весь конвейер. ВЕСЬ.".

Браво, а какой-такой конвейер сбрасывется ? Из чего он состоит-то, этот конвейер - не прояснил и сам он не понял, что мной подчеркивалась разница в перекодировке маш.кодов R и С, и в продвинутых системах конвейер состоит из раскодированных МИКРОкодов, а не машинных(asm) кодов и именно про соотношение сброшенных и видимых кодов идёт речь (в неполном виде- естессно).

Ну тут законный бред нечитающего чукчи, с моими правками:


Батенька, осильте мои примеры выше, а лучше вставьте нативные коды DOS-8086
или 286-protected mode в исполняемый бинарник 386, 486, 586 и получите єкзепшин.

Для тупых и ленивых повторяю последний раз: НЕ ВЫПОЛНЯЮТСЯ коды разных х86 процов
друг на друге в ЕСТЕСТВЕННОМ и непринуджённом виде. Они выполняются на другом проце, или
в брехологической терминологии интел: в отдельном режиме процессора (и в отдельном сегменте, который надо нетривиально подготовить и именно это искусство отделило MS от конкурентов), типов которых столько, сколько процов налепил интел в один кристалл.


тут вижу явное медицинское явление - подтверждение ранее выдвинутых CANNON и мной
(скорее уже сотнями людей в мире) тезисов о разумности для Интела заняться ARM и
опровержение, невысказанного никем, тезиса о простоте(бесплатности, моментальности) этого шага.

Я, как человек разумный, а не тупой идолопоклонник, подкорректирую даже уважаемого мною Дейкстру.
[quote=]
"Блестящее владение родным языком ,там где это эффективно - это мой первый критерий отбора будущих программистов ,как специалистов, умеющих сосредоточиться на максимальной эффективности своих временных затрат "

Адью, я вас покидаю: сил на оспаривания буквоедства нет, думал обменяться мыслями про анализ и перспективы, а не получилось...

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

Вот еще одна цитата из того же абзаца "Программист, изъясняющийся неряшливым языком, - это просто бедствие."

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

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

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

Так вот, неуважаемый peresw, у тебя каша в голове и, соответственно, каша в постах на форуме.

И "корректировать" Дейкстру можно начинать не раньше чем добьешься хотя бы половины того что сделал он.

1. Насчет разрядности процессоров ни одного слова нет - первый слив засчитан, ога.

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

3.
Тут ты выдумал все чуть более чем полностью.
О разумности для Интел заменять свою, владеющую подавляющей частью рынка десктопов/ноутбуков и серверов архитектуру, с колоссальным количеством отлаженного ПО на ARM, который занимает совершенно другую нишу (экономичных но маломощных процессоров), я не писал. "Можно вообще" и "разумно" - это очень, ОЧЕНЬ разные понятия.


Здесь вполне явно виден тезис (причем голословный) о том что тормозит ТОЛЬКО "обертка". Мол достаточно ТОЛЬКО ее заменить и фанаты ARM будут писать кипятком от счастья. Мной как раз и был опровергнут этот тезис, ага. И кто тут после этого читатель, а кто - писатель?


Не-не-не, упаси бог (хоть я в него и не верю). Зачем мне в голове эти бессвязные обрывки информации, которые ты выдаешь за мысли, оналитег?

Ну пока что видно. что тормозит не x86-обертка, а ARM
И если сравнить ситему команд арм и современный х86 со всеми его расширениями, то арм кажется сущим убожеством. Зачем Интелу менять систему команд?

вы сравнивали?)
самое главное отличие риск от циск - это то, что первая сделана для программистов изначально почти все писалось на ассме, и писать логику и оптимизировать на риск значительно проще, чем на циск, так как все намного более очевидно - известна длинна команды и скорость ее выполнения, не надо лепить 2,3,4 комманды циск - там где можно воткнуть 1 риск. циск придумывался не для людей а для тупоголовых компиляторов, которые просто физически не способны задействовать все возможности, всю многогранность, все команды и способы адресации риск. надо думать что в итоге победили компиляторы и как следствие уже - циск архитектура. компиляторам просто проще обходиться урезанным числом комманд. я как сейчас помню, когда у меня был спектрум а у моего друга БК-0010 - хоть и не совсем риск, но уже как бы и не циск там была своя собственная архитектура... все комманды 16-бит размером, 1ой коммандой можно сделать что угодно с чем угодно (утрируя). вот тогда я просто обзавидовался - на сколько быстрее однотипные варианты кода пишутся быстрее на БК, нежели на z80 спектрума.

зы разговор шел про то, что если амд уходит с рынка х86 - то архитектуре - конец. интел не сможет удовлетворить потребности рынка,, как следствие был бы отказ от архитектуры. расслабтесь амд просто не будет больше делать громких фраз про то что надерет зад i7 i5 и т.д. все будет так же как и раньше просто что получится, то и получится. и я считаю что эта политика правильная. а то устраивают сначала фурор на бумаге а в итоге никакого "вау" не получается.

зыы неспособность людей писать приличные компиляторы - никоим образом не отправдывает х86 как архитектуру.

зыы согласен с peresw по поводу префиксовых комманд- самые что нинаесть костыли. может он не совсем верно излагает мысли, но видит в верном направлении. конечно префиксовые комманды нейтрализируются однобайтовыми инструкциями, в отличии от риск, где все комманды - минимум 16 бит, но проще разом прочитать 16 бит инструкцию, чем декодировать ее по 8 бит.

зыы а еще производителям выгодно продавать одно и то же под видом new! сейчас настольные процессоры перестали расти "ввысь" (мгц) и начали расти "вширь" (ядра). х86 может удовлетворить лишь потребности настольных систем и по привычке серверов, в то время, как арм может удовлетворить как потребности и настольных и мобильных и встраиваемых систем и серверов, причем последнему есть куда развиваться. ноутбуки уже давно - не мобильны в полном смысле этого слова, а лишь красивая замена настольника дома. поэтому народ будет покупать и покупать а арм будет расти и расти дальше.

А новые процессора могут поменять скорость выполнения и длину команды, оставив совместимость со старым? Если да, то со временем ARM обрастет не хуже х86.


про спектрум ещё не забыли, а БК забыли.



Какая там частота для бульдозера штатная?


Единственный костыль, это энергопотребление, возможно и это исправят в х86.

Sulphide

Ну сколько уже можно на одни и те же грабли-то наступать?

То Xeon - мертворожденный и никому не нужный, то


Угу-угу, все ровно наоборот.
Вместо CISC-варианта add [eax],ebx в RISC пришлось бы сделать что-то вроде:
mov ecx, [eax]
add ecx,abx
mov [eax],ecx


Весь ОДИН способ адресации?


Ну, о том что сообщение сложночитаемо в принципе можно и умолчать. Хотя нелюбовь к знакам препинания настораживает.
Но вот урезанное число команд, это как раз RISC (Restricted/Reduced Instruction Set Computer - коvпьютер с ограниченным набором команд), в то время как CISC - Complete/Complex Instruction Set Computer - компьютер с полным/сложным набором команд.


Конечно-конечно, своя собственная архитектура была, ни CISC ни RISC
Ну что за бред?
Там использовался К1801ВМ1 - процессор с системой команд PDP-11. 6 видов адресации, 0-, 1- и 2-адресные команды и всего 8 регистров - это читсый RISC, ага


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


Он не видит ничего кроме собственных фантазий. Даже Software Developer Manual, выложенный на блюдечке в упор не видит, зато продвигает байки о всемирном заговоре производителей процессоров и спрятанном 8086 внутри Sandy Bridge


Все команды, как правило одинакового размера. Но только CISC не декодирует по 8 или сколько-то постоянное количество бит. Простона первом шаге определяется длина команды, на втором она выбирается и декодируется.

Так что учим, учим, учим матчасть

ORLY? это решается макросами. просто команда с точки зрения х86 будет длинная.
а сколько интересно надо команд x86 чтобы сделать это??:
ADDLT r1, r0, 2 - если меньше чем .., то +2 к r0, результат в r1 (2 байта инструкция)

а вот реальный пример - процедурка возвращает абсолютное значение. На входе и на выходе, в случае х86 - eax, в случае ARM - R0:

x86 8 байт:
0042B800 83F8 00 CMP EAX, 0
0042B803 7D 02 JGE SHORT 0042B807
0042B805 F7D8 NEG EAX
0042B807 C3 RETN

ARM 6 байт:
CMP r0, #0
RSBLT r0, r0, #0
MOV pc, lr

а это родил msvc:
push ebp
mov ebp, esp
cmp [ebp+xxx], 0
jl short loc_401010
mov eax, [ebp+xxx]
jmp short loc_401015
loc_401010:
mov eax, [ebp+xxx]
neg eax
loc_401015:
pop ebp
retn 4
двойное чтение из памяти и также запись в память при любом пуке, сравнение в памяти, вместо того чтобы 1 раз прочитать значение в регистр - это болезнь всех компиляторов, я не пробовал для риск процессоров, но подозреваю, что любой риск компилятор родит нечто настолько неудобоваримое, что оно естественно не сможет конкурировать с х86, хотя вручную - все будет элегантно и красиво. (оптимизация отключалась - так как при достаточно простом коде компилятор разворачивает функцию в inline, но ее смысл не меняется, при достаточно сложном - он ее сохранит, сделано для наглядности)

вы поймите, тут спорить бесполезно, везде есть плюсы везде есть минусы. и да, компилятору проще поставить условный переход чем сложную условную инструкцию. во всяком случае я не увидел ни одной, просматривая libctr-jni.so из одной игрушки для андроида.
И, если честно, я так и не понял что вы хотите доказать, кроме того что мастерски меня цитируете?) Еще раз подчеркну, что основная моя мысль была - если амд уходит с рынка х86, то этому рынку конец. Тут не надо кидаться количеством команд, и количеством способов адресации и прочими наворотами. Вам продадут - вы купите. Интел - без АМД - никто и ничто. Здесь должен быть длиннющий список компаний и корпораций поддерживающих арм, но его не будет, достаточно наугад ткнуть в любую.

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

Добавлено спустя 41 минуту 43 секунды:
По поводу серверов - arm64 была разработана явно не для того чтобы в побрякушки пихать. Все еще только начинается.

Добавлено спустя 13 минут 29 секунд:

... на 100500+ шаге она переводится в набор инструкций risc которые наконец-то выполняются.. сори за сарказм.

Sulphide

Простите, но ваши примеры - это те самые сферические кони в ваккуме из анекдота.
Я, конечно, понимаю что очень хочется утвердить свою точку зрения, но...

Программы работают с данными, данные находятся в памяти. Они оттуда читаются и туда пишутся.
Поэтому даже если ваша гипотетическая процедура возвращения абсолютного значения и рассчитана на то что кто-то заранее положит в регистр R0 аргумент, то вск равно рано или поздно кто-то (человек или компилятор) должен считать данные из памяти и туда же их вернуть. И тогда epic win резко обернется epic fail'ом.

Та же по смыслу процедура, но не маскирующая факт постоянного "проживания" данных в памяти (а не в регистрах, пусть даже их в ARM 16 против 8 в х86-32). Исходные данные в памяти, в регистрах (eax и R0) расположен адрес числа, абсолютное значение которого нужно получить.

cmp [eax], 0
jge short label1
neg [eax]
retn

LDR r1, [r0]
CMP r1, #0
RSBLT r1, r1, #0
STR r1, [r0]
MOV pc, lr

О размере кода я в данный момент не пишу, но по количеству команд ARM уже проигрывает, не так ли?


Я это прекрасно понимаю. Только вот там где у ARM плюсы - там он и занимает 95% рынка. А там где плюсы х86 - там 95% занимает он.
Ключевое достоинство ARM - экономичность: в количестве транзисторов, площади кристалла, потреблении энергии, стоимости. Его место там где нужно считать экономно и экономично.
А где нужно считать быстро - там дело х86 живет и побеждает.


а) этому рынку придет конец либо если некому будет продавать, либо если некому будет покупать. Только так и никак иначе.
б) Отсутсвие конкуренции - это несомненно плохо, но вы вместо этого начали настаивать на том, что проблема х86 не в отсутствии конкуренции, а в том что он весь "кривой, с костылями" и т.п. Именно это и заставляет меня до сих пор писать в данную ветку.


Эта фраза столь же бессмысленна как "Абрамович без Васи Пупкина - никто и ничто"


Ошибки от описок отличить можете?
Подсказываю: описки могут встречаться часто, но практически всегда они разные. Где-то соседнюю букву нажал, где-то порядок 2-х (а то и 3-х) букв изменил, где-то лишнюю букву поставил, где-то наоборот букву или пробел пропустил.
А ошибки систематически одинаковые. Слово "комманда", повторенное как минимум дважды, именно из этой серии.


Словом RISC можно обозначить конкретный процессор или архитектуру. А вот команды не могут быть в общем обозначены как CISC или RISC.
Например команда MOV есть и в х86 и в ARM. Какого типа эта команда?

Даже в терминологии Intel и AMD вы не встретите терминов RISC-команда. Есть микрокоманда у Intel, есть свой термин у AMD (не помню какой именно, соответствующий Developer Manual читал лет 9-10 назад, не обессудьте). Вот так и называйте их.

И да, если даже сугубо теоретически предположить, что в х86 сферические CISC-команды декодируются ("превращаются") в еще более сферические RISC-команды, то (внимание, вопрос!) во что превращаются внутри процессора после декодирования сферические RISC-команды ARM? Или они все еще недостаточно сферические? Или они не RISC вообще?

Docent2006 цитировать самого себя - это конечно не comme il faut, но при всем богатстве выбора другой альтернативы не было...


а это код собран в IAR EW, та же самая функция:


ладно, ладно... конвенция передачи параметров х86_32 подразумевает работу через стэк, в винде по крайней мере... и чтобы было справедливо возьмем х86_64 - конвенция передачи параметров через регистры:

на входе ecx, на выходе eax при int, при int64 (long long) - все тоже самое, только ecx=rcx, eax=rax, ну и толщина команд в среднем на байт больше.


)) кроме опять же слов "родил msvc", омг, wtf?, кучи знаков вопросов и прочего, на ум ничего не лезет. да действительно, тут х86 показал всю свою мощь, все команды и способы адресации. я думаю, никто не будет спорить что сейчас на ассме пишут только эмбедед программеры. а весь зоопарк приложений написан на компилируемых языках и если раньше было принято хоть как-то оптимизировать узкие участки кода вручную на ассме, то с приходом слова "кроссплатформенность" и эти методы ушли.

а вот сама виновница торжества:
int abs1(int xxx)
{
if (xxx>=0)
return xxx;
else
return -xxx;
}
кстати из таких "сферических коней в вакууме" строится среднестатистическое приложение.

я несколько постов тому назад писал что х86 создавалась для компиляторов (во всяком случае так учил интернет, и я в этом не сомневался), но сейчас беру свои слова назад.

зы to Docent2006 можно еще разик написать что мол работа с памятью и т.д.... но я скажу, что ничем оно не отличается от того же х86, просто используется там где надо, а не как попало.
и попытайтесь не цепляться к словам, risc команда - это команда из набора команд risc процессора, чтобы отделить одни команды от других я использовал этот термин, можете считать его авторским.
зыы по поводу языка изложения - ога у меня тоже буква М залипает...

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

зыыыы тег [сарказм] можете применить ко всему посту.

Sulphide

А теперь взгляните на свой первый пост в этой теме и на последний.
Вначале вы упорно отстаивали точку зрения, согласно которой крива и глючна сама архитектура х86.
А сейчас оказывается что проблема в компиляторах и программистах. Так каким же образом это относится к кривизне архитектуры?

Точно так же компиляторы могут генерировать такой же неудобоваримый код как для ARM, так и для любой другой RISC-архитектуры. Но мне все еще непонятно почему это дает основания говорить о кривизне х86?


Таки вы не ответили - в какие команды декодируются RISC-команды ARM?


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

Да я и не особо говорю что х86 убога она мне на столько же близка и родна как и первый "хеллоу ворд" на ассме z80 спектрума 20 лет назад, я просто говорю, что она стара как мир и многие ее аспекты требуют реального пересмотрения. я вобще за то, чтобы создать что-то новое по крайней мере еще на ближайшие 20 лет, но чтобы сразу было продумано все от начала и до конца и возможность расширения без дурацких префиксов. risc под это дело подходит очень хорошо. хочешь побольше команд - меньше плотность кода - компилируй в родном режиме процессора, хочешь высокую плотность кода за счет еще меньшего числа комманд - пили в режиме thumb, причем все это в одном приложении, на примере арм. вон китайцы забацали свой проц, у которого свой набор инструкций, но он может работать в режиме эмуляции х86, у наших были прекрасные разработки на эту тему и уж куда лучше х86. плохо что выживает не лучшее, а продвигаемое.

зы по поводу буквы М - так и быть признаюсь - это болезнь переводчиков, когда второй язык оказывает влияние на родной, так что бывает пишу дабл М, бывает еще в слове "адрес" дублирую и Д и С. прискорбно, но это просто привычка.

Sulphide
Думаю что теперь мы пришли к некоторому взаимопониманию (в том числе и касательно буквы "м")


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