/COMP/ MosTek 6502
Jan. 1st, 2006 06:28 pm![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
netchОказывается, он стал популярным за то, что продавался в 7 раз дешевле аналогичных изделий конкурентов.
А то, что писать под него в отличие от изделий конкурентов был ужас на крыльях ночи, и что всеми ругаемый x86 по сравнению с ним идеал конструктивной красоты - так, ерунда.
Видимо, в amd64 решили стремиться по уровню извратности к 6502.:(
А то, что писать под него в отличие от изделий конкурентов был ужас на крыльях ночи, и что всеми ругаемый x86 по сравнению с ним идеал конструктивной красоты - так, ерунда.
Видимо, в amd64 решили стремиться по уровню извратности к 6502.:(
![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
no subject
Date: 2006-01-01 06:19 pm (UTC)no subject
Date: 2006-01-01 06:45 pm (UTC)весь рассказ состоит из "у таких-то операций дефолтный размер такой, у таких-то такой". push 8-байтный есть, 4-байтного нет. Параметры расширяются до 64 бит то со знаком, то без. Смещения 32-битные, 64-битных нет, появились code models от которых когда-то убегали как от страшного сна при переходе на 32-битку. В стандартном (на сейчас) режиме 64-битные операции требуют спецпрефикса, поэтому код получается толще. В общем, каша x86 усугубилась ещё одним слоем бардакизации.
Бардакизацию продолжает стандартизация ABI. ABI принятый для unix - для Windows они не годится - там масса вещей решена принципиально иначе. Ладно, фиг с ним. Но 64-битная винда хранит 64-битные библиотеки в system32, а 32-битные в Wow64. Логику конечно понять можно, но её надо запить целым стаканом. У unix логика не лучше. long 8-байтный - OK, но с виндой несовместимо (впрочем, что LP64 лучше чем LLP64 доказано уже длительной историей unix)...
no subject
Date: 2006-01-01 09:53 pm (UTC)Сейчас лично меня ни грамма не интересует, почему именно у xeon с повышением частоты возрастают и так немелкие (сотни циклов) потери на cs, а также какого amd64 получается немного NUMA. Благо есть много сильно более умного народу, из-за которого Оно Даже Работает (TM) на том уровне, где уже доводится сталкиваться...
А так -- как-то думал, и оказалось, что у Intel что-то от 8080 (или 4004? ;-) и до чего-тогда-было -- PII? -- в _каждом_ поколении были более или менее финальные баги. Про то, что их есть в каждом поколении по крайней мере того AMD, с которым сталкивался -- ещё понятней.
В общем, перфекционисты всегда имеют массу поводов для хандры. :)
no subject
Date: 2006-01-01 10:55 pm (UTC)Не перепутал. Понятно, что тогда ассемблер надо было знать всем кто хоть как-то касался темы, а сейчас этим занимаются только красноглазые (неважно какой привязки) и супергуру. Но ситуации немного разные. 6502, а также такое чудо тогдашней техники как S/360, получало весьма тяжёлые ограничения в качестве работы, приводившие к выполнению колоссального количества ненужных операций. Да, S/360 - меньше, 6502 - на порядок больше. Но тем не менее это были отличные примеры как попытавшись сэкономить на спичках получаем тонны геморроя на ровном месте и заметное усложнение кодирования там, где этого можно было избежать тривиальными дешёвыми мерами.
С другой стороны, неровность системы команд приводит к усложнению исполнительных устройств, которые сейчас составляют за счёт крайне вычурной логики конвейеров заметную часть кристалла - эти миллионы транзисторов съедаются двумя основными потребителями: конвейерной логикой и кэшом, все остальные по сравнению с ними не в счёт. Вот вопрос - достаточно ли логика разбора команды в x86 была громоздка, чтобы введение дополнительного слоя бардака в amd64 не повлияло заметно на затраты элементной базы на конвейер? ;)
> Сейчас лично меня ни грамма не интересует, почему именно у xeon с повышением частоты возрастают и так немелкие (сотни циклов) потери на cs, а также какого amd64 получается немного NUMA. Благо есть много сильно более умного народу, из-за которого Оно Даже Работает (TM) на том уровне, где уже доводится сталкиваться...
Я бы не был таким беспечным.;) Оба описанных вопроса сводятся к скорости памяти, которая за всё прошедшее время не увеличилась, а местами и уменьшилась (DDR2 при равной тактовой обладает большей латентностью чем DDR1). Если к этому добавить межузловые передачи в архитектуре NUMA, тормоза начнутся совсем недетские. Ты думаешь, решение этого в традиционной парадигме ничего не знающей про проблемы NUMA сильно поможет? Достаточно ещё двух лет текущей ситуации с проблемами освоения высоких частот, чтобы необходимость учитывать неоднородность исполняющей среды вышла на уровень алгоритмов, причём на всех уровнях. Вплоть до выдачи отдельного IP каждому узлу.:)
> В общем, перфекционисты всегда имеют массу поводов для хандры. :)
Да тут речь не о перфекционизме. Чтобы избавиться от мании перфекционизма достаточно вменяемой психики и пары лет реальной работы разработчиком. Но когда видишь решение, логика которого не обосновывается даже самыми фантастическими предположениями в пределах разумности- возникает вопрос, а что же курили разработчики. Это не про amd64, там я могу найти обоснование, хотя и с небольшой натяжкой - нет, это в первую очередь про 6502.
no subject
Date: 2006-01-02 09:43 am (UTC)Гм. Думаю, у нас с тобой есть один общий знакомый (любитель тащить openbsd'шные строковые функции и прочую санитизацию в glibc), который вроде бы вполне подходит под "достаточно", но сам говорит, что не избавился ;)
> возникает вопрос, а что же курили разработчики.
"Люди склонны создавать проблемы, а потом героически их преодолевать" (c) неизвестен
Не находишь?
no subject
Date: 2006-01-03 10:05 pm (UTC)Не опознаю кто этот знакомый, но я лично согласен - данный комплект функций должен так быть. (Может быть, не в этом виде; рекомендация ISO/IEC 24731 решает те же проблемы, но иным образом.) Ты, может быть, про Solar'а?
И перфекционизмом я бы это не назвал - перфекционизм, если рассматривать данную тематику (NUL-terminated strings) будет исключением вредных функций начиная с strcpy() в принципе.
>> возникает вопрос, а что же курили разработчики.
> "Люди склонны создавать проблемы, а потом героически их преодолевать" (c) неизвестен
> Не находишь?
Да, есть и такой modus operandi. Но опять же - умеренные его количества ещё понятны. Но чрезмерные наводят на мысли о психическом состоянии...
no subject
Date: 2006-01-04 10:03 am (UTC)Нет, про ldv@ (впрочем, тоже и @openwall).
> И перфекционизмом я бы это не назвал
"Это" и не называл, тут скорее для ссылки вспомнил glibc.
> Но чрезмерные наводят на мысли о психическом состоянии...
А мы все -- больные, вот только понять этого никак не хотим. Не говоря уж о лечиться.
no subject
Date: 2006-01-02 01:18 pm (UTC)У AMD, как и Intel принципиально отсутствует задача "сделать хороший процессор".
Задача была простая -- сделать 64-х битный процессор, который был бы при работе в 32-х битном режиме хорошим конкурентом процессорам Intel, и при этом который имел бы заметные преимущества от использования его в 64-х битном режиме.
Других целей не было, поэтому сделали "как получилось".
В любом случае amd64 по совокупности характеристик лучше чем серверные процессоры от Intel. А большего и не требовалось.
Relative? :)
Date: 2006-01-03 02:23 am (UTC)"Calculation of Clock Frequency by Leo Nechaev"
PS. С новым годом, однако!
Re: Relative? :)
Date: 2006-01-03 10:16 pm (UTC)No. По крайней мере мне по этой линии ничего не известно.
> PS. С новым годом, однако!
Взаимно. Хоть я и равнодушен к нему.