И такое говно там везде:

    4434:	e8 d2 00 00 00       	call   450b <__x86.get_pc_thunk.bx>
    4439:	81 c3 b7 ca 00 00    	add    $0xcab7,%ebx
    443f:	83 ec 14             	sub    $0x14,%esp
    4442:	8d 83 24 01 00 00    	lea    0x124(%ebx),%eax
    4448:	8d 93 24 01 00 00    	lea    0x124(%ebx),%edx
    444e:	29 d0                	sub    %edx,%eax
    4450:	c1 f8 02             	sar    $0x2,%eax
    4453:	89 c1                	mov    %eax,%ecx
    4455:	c1 e9 1f             	shr    $0x1f,%ecx
    4458:	01 c8                	add    %ecx,%eax
    445a:	d1 f8                	sar    %eax

x+=0xcab7;
y=((124+x)-(124+x))/4;
z=((124+x)>>1)+y;

struct big {
    ....//124 bytes
    char c1, c2, c3, c4;
};

struct big B;
void f() {
    if (&B.c4 - &B.c1 > 6) {...}
}

С этого места подробнее - что за ISA? Меня с похожим проектом завернули, если что...

Поскольку это код динамической библиотеки, нужно смотреть, что делает «call 450b <__x86.get_pc_thunk.bx>». Возможно, он позволяет определить адреса в позиционно независимом коде библиотеке. К чему тут сравнение, не знаю.

Пиши про духовные скрепы и про поднятие с колен, кому эти инструкции интересны.

Пока жадно писать. вдруг быстрые посоны запатентуют пока мну ждет. Посмотрим на отзыв, если не сработает ни там ни в МГУ ни в ингрии то не судьба, все в опенсорс

почему мы сможем бить интел-атом, имея кратно меньшую частоту.

тогда уж считай mips/watt

я бы после таких пассажей сразу завернул и не стал бы читать.

что мы атома дергаем если ему к ноге якорь привязал комплятор?

можешь, как интел, написать свой компилятор

p.s. ))))) атом он дёргает )))))

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

почему мы сможем бить интел-атом, имея кратно меньшую частоту

1. если не можете порвать атом возьмите что-то слабее.

2. Ты всегда можешь показать что «на воот этих вот операциях наша узко-заточенная железка рвёт всех». Судя по тому сколько проектов пытается «порвать интел, обогнать з-н Мура и ваще Джобс придёт к нам на коленях» так делают все.

3. Тупо возьмите мобильник на топовом арме, засуньте в корпус посолиднее и показывайте как оно рвёт по «производительность на ватт».

на топовом арме

Главное, написать прилагу так, чтобы она попала на правильное едро. Ибо в «топовом» арме 2 2.5-гигагерцовых A72, 4 2-гигагерцовых A53, и 4 таких же, но 1-гигагерцовых. И ещё есть огрызок для обслуживания датчиков с производительностью уровня кпкшки на винмобайле 2003.

Бинго!

Дай угадаю процессор по описанию. Так, так, так.... Mediatek heli x20/MT6797 . Где можно забрать приз? :)

все вопросы к разрабам GCC (у меня 4.8.1)

Я строго говоря и не собирался бить атом, и джобса на коленях приводить. Порвать - это фигурально. В реальности надо хотя бы не в дрободан сливать на обычных приложениях. Ядер-то будет 12 на 4кв.мм, 48 на камень. но они падлы небыстрые(<=500мгц).

Проблемы с х86 как таковой нет, ибо по плану мы сперва вообще IP-корки отдельных блоков АЛУ продаем. Эти проблемы встают на следующем шаге, где надо уже сделать SoC, и эта SoC должна попадать под много задач. Одна из таких задач, которую я для весомости добавил - это моноблок который можно присобачить как монитор. Для нищебродов просто моноблок, для людей монитор с фичами и андроидов в подарок.

И вот там-то необязательно но желательно обосновать, почему мы сможем быть не хуже днищеатома.

Дело в том, что проект проца начинался как ускоритель физики для воксельной игры типа minecraft. в софте я его сделал так, что два куба обсчитывались за 4 SSE команды + maskmov + test + je. Так что дальше уже некуда. Но проц всё равно не может это быстро. Поэтому начал думать в сторону FPGA. Ну а потом понравилось, и получилось то что получилось. Хочется чтоб оно было opensource но и денег тоже хоцца. Денег пока хочется больше.

Я вам всячески желаю успехов.

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

Так зачем потребовался очередной SoC c кучей слабых ядер? Мне казалось это тупиковое развитие. Обычным приложениям это не нужно, а остальные ориентируются на openCL/CUDA. Причём, такое железо уже можно купить (nvidia k1/x1?), причём, на современных техпроцессах.

Потом, есть решения и с 64-я ядрами (https://www.parallella.org/board/), но я поделил ширину памяти и объём кэша на кол-во ядер и мне стало грустно. Мне кажется, люди часто пихают много ядер чтобы похвастаться попугаями в синтетических бенчмарках и как элемент маркетинга. Такое ощущение что вы сейчас на том же пути.

Что скажешь, tailgunner?

Я скажу, что этой планете не нужна еще одна ISA, особенно когда есть RISC-V и lowRISC.

просто решили поиграть в процессоростроение

Вообще-то это именно так и начиналось.

зачем потребовался очередной SoC c кучей слабых ядер?

Слабые ядра слабые от того, что они так сделаны, что они мелкие. Если скоро запустят безмасочную литографию, это дело станет реальностью, так что проект не совсем безумный. Но люди из маппера писали, что главная цель - сделать доступной 65-45нм, а не сразу 22 штурмовать. Так что оценка 65нм со всеми вытекающими.

Конкретная актуальная задача - это GPU. 0.3кв.мм. @ 65нм оценка сильно сверху против 1.7кв.мм mali t760 @ 14нм. На квадрат у нас 24 против 19 операций на цикл, так что не всё так однозначно. В роли GPU справимся. Куда нафиг не нужна, просто делаешь for(int x = 0; x<N; ++x) kernel(x); Это вот как раз наследие игрушки которую я делал. Короче, каждые 12 ядер можно считать одним процом, и вообще их комбинировать. Каждое из них 4 сложения и 4 умножения тянет. Предусмотрен прозрачный garbage collection опять же, можно GC на одном ядре крутить не мешая. Жаберы будут писать про то, как у них жаба быстрее проца работает. И плюс еще ряд других фишек, которые сработают на мультимедии - в общем, 500мгц будут не настолько сливными.

Единственный момент - это немультимедийный код. Вот его наш проц будет хавать грустно, и как раз его я пытаюсь оценить. А тут GCC 4.8.1 говно выдает что его стыдно в обоснование пихать.

ЗЫ:

А параллела укатилась на днище и о ней уже давно не слышно, ибо они вообще не думали про задачи когда сооружали своё чудище. Там бесполезно делить кэш на ядра, это в принципе плохой подход: сделаем много абстрактных MIPS и мало ватт а анонимусы всё остальное замутят. А эппл их рассмотрел и сказал нет(на сайте а адаптевы написано). Баллмера надо было слушать, когда он скакал по сцене с криками «девелоперс! девелоперс!», мужык странный но всё таки не круглый дурак.

Предусмотрен прозрачный garbage collection

O_O это как? У меня закрадывается нехорошее предчувствие...

если в двух словах: в нормальных процах 99% обращений в память косвенные. т.е. [reg+offset]. остальные можно свести к косвенным в одну команду. мы просто ввели адресные регистры куда НАДО класть адрес прежде чем что-то адресовать. так вот, эти регистры физически сидят глубоко в блоке кэша, они write-only для кода(кроме снятия задачи где выгружаются оптов в составе контекста).

по команде с шины их можно атомарно заменить невидимо для программы. а чтоб не лезть в регистры, то вместо записи адреса предусмотрен режим записи индекса, который спецпроц(1 на 12 ядер) пересчитывает в адрес и возвращает командой с шины. И такой же посылкой можно и переписать.

Программа же этой кухни не видит(write-only же), а реализовать оказалось просто, потому что это побочный продукт от одной графической фишки. Ну а раз просто, то надо писать в advantages.

Речь идёт о copying gc? Ты хочешь подсунуть программе другую кучу?

типа того, но куча одна и та же.

я хочу подсунуть программе аллокатор SLAB, причем аппаратный. а еще там аппаратный ускоритель хеш таблиц(1D, 2D, 3D - текстурки же) вот он индексы в указатели пересчитывает.

это всё как раз в ray casting используется и оказалось что можно и жабу ускорять за те же деньги.

есть возможность отмечать для задачи GC где мы «забыли» указатель, а она проверив доступность, может delete эти блоки. а потом закомпактить внутри SLABа. там даже копирования-то нету, только тэги правятся.

процессор ненормальный очень, он не RISC и не VLIW и кэш у него дикий и ненормальный.

Пока жадно писать. вдруг быстрые посоны запатентуют пока мну ждет.

Так я почему спрашиваю:

Я придумал новый микропроцессор

сравнить хочу

впрочем, из предыдущих сообщений многое стало понятно. Если не секрет, в ккаком состоянии вот это всё? Прототип имеется?

Блоки АЛУ по 2к gates готовы. Double, float integer all in one. В работе декодер и память. Ибо вылезают на ходу ньюансы. Эмулятор тоже в работе(system c)

Я почитают вечером, есть мнение что можно объединиться. Напиши на krogomvolki at gmail

оказалось что можно и жабу ускорять за те же деньги.

Вы запустили на своем проце полную Java или какое-то подмножество?

Почитай про PIC: http://ewontfix.com/18/. А то сядешь в лужу за нефиг делать. Бери не PIC код, и не для x86, а для x86-64, где всё статически слинкованно. Там всё будет очень хорошо соптимизированно.

во-первых, атом 32хбитный. во-вторых, мне всё таки надо показать что мы не в дрободан сливаем.

во-вторых, x86-64 складывает 64битные за 1 цикл, у нас будет 2 ибо мы тоже 32-битные. на 86-32 в 32битных штуках регистров 8 целых + 16 fpu(идут за 2) + 32 SSE. Есть запас(у мну 64): можно мутить out-of-order.

в 86-64 регистров вдвое больше и вдобавок целые вдвое жирнее. Даже без SSE целые займут 16*2=32.

имеет ли смысл сравнение? мы ж GPU делаем, х86 там очень побочный продукт, для весомости не более. линукс то все равно нативно пойдет

про PIC я знаю, копетанить было необязательно

во-первых, атом 32хбитный.

был когда-то.

всегда можно потягаться с quark