В основном все утыкается в обратную совместимость. Потому intel до сих пор поддерживает набор инструкций i386.
И это на самом деле позволило intel вырваться вперед.
Если вас не беспокоит обратная совместимость — не проблема. Большая часть альтернативных архитектур либо забивают на это, либо их ISA была изначально грамотно составлена и не меняется уже годами. Посмотрите на RISC архитектуры.
На сегодняшний день если задача не требует адресации более чем разрядность регистров — никто привентивно не пытается ее увеличить. Посмотрите сколько 16-ти битных контроллеров. Но штука в том, что сам ALU там выполняет административную функцию в то время как основная задача выполняется в железе(кодеки, сеть, etc.)
А придумывать сложность чтоб выиграть на «паре» вентилей — это удел 60х где вентили были размером с кулак и жрали больше чем нынешний ноутбук средней паршивости.
Конечно, на данный момент это одно из узких мест многопроцессорных и многоядерных систем.
Если этот «кластер» не будет выполнять операции параллельно то можно про накладные расходы закрыть глаза. Но зачем тогда строить кластер?
Допустим, что у вашего процессора хитрая индексация памяти и когда дается команда «дай мне данные по адресу X» процессор по факту будет выдавать 16 бит по адресу X << 1. Так получится адресовать 1MB, но отсутствует возможность выборки/сохранения байта — придется самостоятельно делать сдвиг. Это по сути то же, что многие процессоры делают при невыровненном доступе к памяти, только проблема обратная.
Другая проблема в том как разделять состояние между окнами? В регистрах вряд ли получится — слишком жесткое ограничение.
Возможно делать дополнительный набор «разделяемых» окон и вводить специальные инструкции(что-то вроде ld|st reg, addr, win, где значения addr и win хранятся в регистрах). Но это по сути тоже самое, что сегментная память у x86 от которой intel слава богу отказался. Да и тогда прийдется вводить либо понятие расширенных инструкций, либо увеличивать разрядность инструкции, либо уменьшать количество регистров, потому, что если архитектура использует 16 регистров, то при 3х операндных инструкциях остается всего лишь 4бита под OpCode, что достаточно печально.
Мне все-таки пока непонятно каковы могут быть причины требования разрядности 16бит если стоит задача адресовать большое количество памяти.
На самом деле надо рассчитать требуемое количество вентилей(gates) для одного случая и представить сколько это займет на кристалле. При нынешних тех процессах ALU+register file занимает не более нескольких процентов площади. Основной «прожора» — память(cache, sram, etc.)
Разве что этот процессор должен быть выполнен по тех процессу «лампа накаливания» — тогда да, разница будет ощутима =D.
Из этого мысленного эксперимента могу сделать вывод — да, конечно, реально иметь такую архитектуру, если это оправданно технологически. В противном случае вводимые ограничения влияют как на удобство разработки(придется писать хитрый компилятор и загрузчик, затачивать программы под архитектуру) так и поддержку.
Если я правильно понял то Sony потому и перешла на x86_64 в PS4 потому, что всех задолбало переписывать игрушки под их хитрую архитектуру. Да, IBM Cell был бесподобен но вызывал головную боль у разработчиков.
Я подумаю над этим, но если честно, то у меня есть сомнения в эффективной организации работы CPU-RAM, если последней на много порядков больше. Можно взять чистую гарвардскую архитектуру, тогда у вас адресуемое пространство удваивается ;) — 64K под инструкции, 64K под данные. Собственно подавляющее большинство микроконтроллеров на 8/16 бит используют этот трюк.
Как выход — можно сделать кластер из таких 16-битных CPU. У каждого по своей функции. Правда расходы на коммуникацию будут губительными.
Я вот прочитал про магическое число 5 и сразу прыгнул в комментарии — неужели до одного меня не доходит в чем суть алхимической формулы R % n = 0.
А тут прям дискуссия. В общем до сих пор непонятно чем автору числа 5, 6, ну в обще которые не степени двойки не угодили. Ну нельзя всунуть 5 битовых кортежей одинаковой длины в 32 бита. Ну и что? Я лично знаю очень мало примеров где используется упаковка по 4x4 бита, Если идет жесткое кодирование(как, например, передачи данных по воздуху), то никто не выравнивают и у Вас может быть нечетное количество полей в байте.
Более интересно это то, чтоб желательно машинное слово было кратно степени двойки. В таком случае относительная адресация пространства — всего лишь операция сдвига:
ADDR(MEM[idx]) == log2(access_size_bytes) << idx
Да и если все сводить к степени 2ки, то получается, что 16-разрядные PICи с машинным словом 12 бит неудел =(.
Ну как Вам сказать, кроме адресации еще есть потребность в вычислениях с большим машинным словом — криптография, кодирование.
Конечно, можно разделять регистры адресов и данных, но во первых — неэффективно: может простаивать часть тех или этих, во вторых нет особой экономии в плане реализации в железе, в третьих постоянная путаница в арифметике(что хуже всего).
Также не видно большого выигрыша по памяти. Был даже эксперимент в linux — x32 abi, но не выжил из-за нерентабельности.
Я согласен с тем, что инструкции должны иметь фиксированную длину. Декодировать для CPU проще, возможность быстро предсказывать переходы, распараллеливание выполнения. Если не хватает разрядов — можно добавить расширенные — по два машинных слова(смотрите ARM Thumb2). Или что-то вроде VLIW.
К стати intel(по примеру amd) перегоняет все свои x86x инструкции в RISC-подобный микрокод перед тем как начать выполнять их. Если я не ошибаюсь последним пиком совершенства у них было декодирование 5-7 инструкций за такт. Естественно плата за это — усложнение внутренней архитектуры, необходимость в повышенной частоте, повышенном энергопотреблении. В то время как в архитектуре с фиксированной длинной инструкции такой блок просто-напросто ненужен, его нет.
Если нужно адресовать память, так 2 такта это уже будет 32 бита, 4 — 64 бита.
Даже если опустить кэш, то это разрядность и частота шины данных между CPU и RAM. Ну и обычно все передается burst-ами, так что нет большой разницы для 1 или 4 байта.
Если я понял правильно автора статьи и вообще концепцию ФП, то надо сказать «нет» императивному подходу.
Я просто показал, что в языках с императивным стилем можно создавать вполне лаконичные конструкции-аналоги.
Согласен, мои примеры не совсем императивные, но это то, что используют «императивщики» каждый день.
Я предпочитаю балансировать и не вдаваться в крайности. Я не вижу смысла переходить на Erlang только потому, что это, возможно, круто.
Я вот к стати попробовал на С++14(уже 300 лет не прикасался к С++ выше С++98):
template<typename T>
auto plus1(const vector<T> &lst)
{
auto mod = lst;
transform(mod.begin(), mod.end(), mod.begin(),
[](auto &x) {
return x+1;
});
return mod;
}
Не самый красивый вариант, да и для rvalue прийдется перегружать, если захочется оптимизировать. Но можно, товарищи =)
Я уверен, вы потратите много минут (не самых приятных), переписывая данный пример в императивном стиле, уместив код в две строки, и при этом, сохранив читаемость.
Потратил 10 секунд на python, столько же на ruby. На C/C++/Java/etc. это получится чуть больше.
>>> def plus1(lst):
... return [x+1 for x in lst]
...
>>> plus1([1,2,3])
[2, 3, 4]
>>>
Спасибо за информацию. В моем случае(использую уже более полугода) пока никаких проблем не наблюдаю. Правда дополнительные кнопки и кнопку под колесом прокрутки не использую.
Не понимаю почему автора заминусовали. У меня коллега по работе использует клавиатуру а-ля 80е которая клацает так, что аж по зубам отдает. Добавьте к этому то, что он иногда строчит по ней так, что как будто это пианино, а он великий маэстро. Тихая печать актуальна.
К сожалению, в моем случае ноутбучная клавиатура более шумная, чем дешевая от Dell ;(.
Меня она всем устраивает кроме «оригинального» беспроводного интерфейса. В основном ставил на то, что беспроводная.
В противном случае я бы попробовал «Orbit Trackball» от Kensington.
К сожалению ассортимент трэкболов весьма ограничен, и, к тому же, цены на них выше среднего.
Про вес согласен, но касательно задержек — не думаю, что они ощущаются. Я лет 8 назад использовал bluetooth мышь toshiba(уже не помню какая модель) и не могу сказать что замечал какие-то проблемы
Сейчас использую Ligitech M570. Эргономика у этой модели не высоте. Одной из причин выбора именной этой модели было то, что она беспроводная(к сожалению не bluetooth и потому адаптер занимает один порт USB) и недорогая.
До этого использовал Logitech Marble, но из-за отсутствия колесика для прокрутки она пылится на полке =(.
Почему в мыше такого класса в нынешнее время все еще используется провод? Тот же bluetooth есть в почти каждом ноутбуке и во многих брендовых станциях. В крайнем случае можно прилагать usb-bluetooth адаптер.
Отходя от темы: после перехода на трэкболл другие «мыши» что-то не цепляют.
И это на самом деле позволило intel вырваться вперед.
Если вас не беспокоит обратная совместимость — не проблема. Большая часть альтернативных архитектур либо забивают на это, либо их ISA была изначально грамотно составлена и не меняется уже годами. Посмотрите на RISC архитектуры.
На сегодняшний день если задача не требует адресации более чем разрядность регистров — никто привентивно не пытается ее увеличить. Посмотрите сколько 16-ти битных контроллеров. Но штука в том, что сам ALU там выполняет административную функцию в то время как основная задача выполняется в железе(кодеки, сеть, etc.)
А придумывать сложность чтоб выиграть на «паре» вентилей — это удел 60х где вентили были размером с кулак и жрали больше чем нынешний ноутбук средней паршивости.
Если этот «кластер» не будет выполнять операции параллельно то можно про накладные расходы закрыть глаза. Но зачем тогда строить кластер?
Другая проблема в том как разделять состояние между окнами? В регистрах вряд ли получится — слишком жесткое ограничение.
Возможно делать дополнительный набор «разделяемых» окон и вводить специальные инструкции(что-то вроде
ld|st reg, addr, win, где значения addr и win хранятся в регистрах). Но это по сути тоже самое, что сегментная память у x86 от которой intel слава богу отказался. Да и тогда прийдется вводить либо понятие расширенных инструкций, либо увеличивать разрядность инструкции, либо уменьшать количество регистров, потому, что если архитектура использует 16 регистров, то при 3х операндных инструкциях остается всего лишь 4бита под OpCode, что достаточно печально.Мне все-таки пока непонятно каковы могут быть причины требования разрядности 16бит если стоит задача адресовать большое количество памяти.
На самом деле надо рассчитать требуемое количество вентилей(gates) для одного случая и представить сколько это займет на кристалле. При нынешних тех процессах ALU+register file занимает не более нескольких процентов площади. Основной «прожора» — память(cache, sram, etc.)
Разве что этот процессор должен быть выполнен по тех процессу «лампа накаливания» — тогда да, разница будет ощутима =D.
Из этого мысленного эксперимента могу сделать вывод — да, конечно, реально иметь такую архитектуру, если это оправданно технологически. В противном случае вводимые ограничения влияют как на удобство разработки(придется писать хитрый компилятор и загрузчик, затачивать программы под архитектуру) так и поддержку.
Если я правильно понял то Sony потому и перешла на x86_64 в PS4 потому, что всех задолбало переписывать игрушки под их хитрую архитектуру. Да, IBM Cell был бесподобен но вызывал головную боль у разработчиков.
Из-за сложностей развития такой сложной архитектуры проект похоже умер.
Как выход — можно сделать кластер из таких 16-битных CPU. У каждого по своей функции. Правда расходы на коммуникацию будут губительными.
ADDR(MEM[idx]) == idx << log2(access_size_bytes)
R % n = 0.А тут прям дискуссия. В общем до сих пор непонятно чем автору числа 5, 6, ну в обще которые не степени двойки не угодили. Ну нельзя всунуть 5 битовых кортежей одинаковой длины в 32 бита. Ну и что? Я лично знаю очень мало примеров где используется упаковка по 4x4 бита, Если идет жесткое кодирование(как, например, передачи данных по воздуху), то никто не выравнивают и у Вас может быть нечетное количество полей в байте.
Более интересно это то, чтоб желательно машинное слово было кратно степени двойки. В таком случае относительная адресация пространства — всего лишь операция сдвига:
ADDR(MEM[idx]) == log2(access_size_bytes) << idxДа и если все сводить к степени 2ки, то получается, что 16-разрядные PICи с машинным словом 12 бит неудел =(.
Конечно, можно разделять регистры адресов и данных, но во первых — неэффективно: может простаивать часть тех или этих, во вторых нет особой экономии в плане реализации в железе, в третьих постоянная путаница в арифметике(что хуже всего).
Также не видно большого выигрыша по памяти. Был даже эксперимент в linux — x32 abi, но не выжил из-за нерентабельности.
Я согласен с тем, что инструкции должны иметь фиксированную длину. Декодировать для CPU проще, возможность быстро предсказывать переходы, распараллеливание выполнения. Если не хватает разрядов — можно добавить расширенные — по два машинных слова(смотрите ARM Thumb2). Или что-то вроде VLIW.
К стати intel(по примеру amd) перегоняет все свои x86x инструкции в RISC-подобный микрокод перед тем как начать выполнять их. Если я не ошибаюсь последним пиком совершенства у них было декодирование 5-7 инструкций за такт. Естественно плата за это — усложнение внутренней архитектуры, необходимость в повышенной частоте, повышенном энергопотреблении. В то время как в архитектуре с фиксированной длинной инструкции такой блок просто-напросто ненужен, его нет.
Даже если опустить кэш, то это разрядность и частота шины данных между CPU и RAM. Ну и обычно все передается burst-ами, так что нет большой разницы для 1 или 4 байта.
Конечно, если T не PDO, то будет неэффективно.
Я просто показал, что в языках с императивным стилем можно создавать вполне лаконичные конструкции-аналоги.
Согласен, мои примеры не совсем императивные, но это то, что используют «императивщики» каждый день.
Я предпочитаю балансировать и не вдаваться в крайности. Я не вижу смысла переходить на Erlang только потому, что это, возможно, круто.
Я вот к стати попробовал на С++14(уже 300 лет не прикасался к С++ выше С++98):
Не самый красивый вариант, да и для rvalue прийдется перегружать, если захочется оптимизировать. Но можно, товарищи =)
Потратил 10 секунд на python, столько же на ruby. На C/C++/Java/etc. это получится чуть больше.
К сожалению, в моем случае ноутбучная клавиатура более шумная, чем дешевая от Dell ;(.
В противном случае я бы попробовал «Orbit Trackball» от Kensington.
К сожалению ассортимент трэкболов весьма ограничен, и, к тому же, цены на них выше среднего.
До этого использовал Logitech Marble, но из-за отсутствия колесика для прокрутки она пылится на полке =(.
Отходя от темы: после перехода на трэкболл другие «мыши» что-то не цепляют.