сложность разработки под 64 bit

Скорее всего, общение с ОС. Впрочем, мне тоже интересно послушать граблепроходцев.

кстати, в эту же степь можно отнести вопрос, почему до сих пор в гимпе нет поддержки 16 цвета? в чем проблема поменять тип с int на long int в структурах, где хранятся массивы цветовых пространств.

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

Граблей очень много (если с самого начала не удосужиться подумать чуть-чуть головой). Например, использование типов нефиксированного размера (т.е., например, long int вместо int32_t) там, где явно нужны, к примеру, 32битные целые, тем более, в передаче в бинарном виде по сети/записи в файл/et cetera. Неаккуратная работа со спецификаторами printf/scanf. И так далее, и тому подобное.

Основная проблема в том, что большинство проблем очень сложно обнаружить.

> Впрочем, мне тоже интересно послушать граблепроходцев.
если самого начала юзать как написали выше переопределенный int8, uint8, int16, uint32 и т.п. то граблей в x86_64 нет.
мне гораздо больше неприятностей доставило big/little engian.

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

>это просто поменять кое-где в коде типа вида small int на long

Так это ж еще найти надо где менять.

Пример:
void foo(int n) { ...}
...
long n;
foo(n);

соберется на обоих платформах без проблем, а нормально работать будет только на 32.

ничем.

// wbr

> Граблей очень много (если с самого начала не удосужиться подумать чуть-чуть головой). Например, использование типов нефиксированного размера (т.е., например, long int вместо int32_t) там, где явно нужны, к примеру, 32битные целые, тем более, в передаче в бинарном виде по сети/записи в файл/et cetera. Неаккуратная работа со спецификаторами printf/scanf. И так далее, и тому подобное.

низкий уровень профессионализма конкретных разработчиков мы не рассматриваем. вопрос сугубо технический и с этой точки зрения разница между i386 и amd64 сугубо минорная.

если же кто-то вдруг считает, что его int всегда и везде будет 32bit или что он будет всегда в LE/BE ордере - это его личные сексуальные трудности. но платформа то в этом не виновата, правда?

// wbr

http://www.ibm.com/developerworks/library/l-port64.html

Кстати, ЕМНИП в венде граблей чуть меньше, так как там из стандартных типов распухли только void* и size_t.

Для большинства языков от перехода с x86 на x86-64 будет только полезно.

Никаких особых сложностей с переходом x86<->x86-64 при программировании на C нет. Если программист не криворукий, то все будет нормально.

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

> Для обычных программ - только типы поменять

Для *правильно* написанных программ - только перекомпилировать.

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

Наоборот, мы не рассматриваем сферических программистов, переносящих свой сферический софт на сферический amd64 в вакууме. 8))

Вопрос был -- какие могут быть проблемы, что флеш под x86_64 так долго появлялся, например. Да, проблема только одна -- криворукость. Но эта проблема как-то уж черезчур общая. 8))

> но платформа то в этом не виновата, правда?

На платформу никто и не ругается. Более того, перенос на любую другую архитектуру ещё никому не вредил. В лучшем случае поднимает ЧСВ авторов (какие мы крутые, просто перекомпилировали -- а оно прекрасно заработало на 113битной архитектуре с mixed endian! 8)) ), в худшем -- помогает избавиться от кучи wtf'ов в коде.

> Да, проблема только одна -- криворукость. Но эта проблема как-то уж черезчур общая. 8))

Она часто встречается. Вот примеры для сравнения: Linux перетащили на amd64 довольно шустро, хотя там кода немало и завязан на архитектуру не меньше, чем тот же флеш. Можно ещё NetBSD вспомнить. А некоторые дрова под тот же Linux до сих пор прибиты гвоздями к i386.

Сложностей полно. И на продукте PVS-Studio (старое название Viva64) для поиска 64-битных ошибок в программах мы зарабатываем свои деньги.

Вот несколько тематических статей о проблемах миграции 32-битного кода на 64-битные системы:

20 ловушек переноса Си++ - кода на 64-битную платформу - http://www.viva64.com/art-1-1-1958348565.html

64-битный конь, который умеет считать - http://www.viva64.com/art-1-1-1064884779.html

7 шагов по переносу программы на 64-битную систему - http://www.viva64.com/art-1-1-1148261225.html

Проблемы 64-битного кода на примерах - http://www.viva64.com/art-1-1-1757483679.html

> Сложностей полно. И на продукте PVS-Studio (старое название Viva64) для поиска 64-битных ошибок в программах мы зарабатываем свои деньги.

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

>а на практике - Flash 64bit нет вроде до сих пор
4.2 даже http://www.adobe.com и тот давно уже как разродился. 

>вон тут рядом удивляются, что хром так быстро под 64 бит написали
хром на 95% это webkit а остаток косметика от гугла. Так вот webkit в равной степени отлично собирается как под 32 так и под 64 бита. А "так быстро" гугл написал как раз вот ту самую косметику по кнопачкам которой тыкают пользователи. 

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

А зачем его вообще переписывать?

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

>хром на 95% это webkit а остаток косметика от гугла. Так вот webkit в равной степени отлично собирается как под 32 так и под 64 бита. А "так быстро" гугл написал как раз вот ту самую косметику по кнопачкам которой тыкают пользователи.

Там есть JIT-движок жабоскрипта V8 который девелоперы не хотят портировать на x86-64 до тех пор пока x86-64 не станет десктопным мейнстримом везде включая виндовс.

>Кстати, ЕМНИП в венде граблей чуть меньше, так как там из стандартных типов распухли только void* и size_t.

Ну вообще-то размер стандартных типов языка C (int,long, etc) зависит от разрядности системы независимо от OS.

> Вопрос был -- какие могут быть проблемы, что флеш под x86_64 так долго появлялся, например. Да, проблема только одна -- криворукость. Но эта проблема как-то уж черезчур общая. 8))

конкретно по флешу ответ скорее прост: он никому нафик не нужен на 64х битных архитектурах и AMD64 в том числе. ну совсем не нужен. даже на i386 линуксе то факт, что флеш вообще появился - это уже серьёзный прогресс. количество десктопных пользователей линуксы и так мизерно. теми же отчаянными, которые по какой-то причине гоняют десктоп на AMD64 можно смело пренебречь и вынести за пределы погрешности. овчинка совершенно не стоит выделки. вне зависимости от того, сложно портировать флеш с i386 на AMD64 или не очень.

// wbr

> Ну вообще-то размер стандартных типов языка C (int,long, etc) зависит от разрядности системы независимо от OS.

Я чуть выше запостил ссылку на IBM dW. Там есть табличка "Table 1. 32-bit and 64-bit data models" и в ней три разных набора размеров для стандартных типов на 64х-разрядной системе. Если не ошибаюсь, в линуксе используется LP64, а в виндоусе - LLP64.

Плюс ко всему, размеры большинства "стандартных" типов WinAPI (названия которых написаны обычно в блондинко-стиле =)) одинаковы в Win32 и Win64.

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

Ух как всё сложно в виндах :). Юниксы в этом плане проще.

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

>А зачем его вообще переписывать?

Уговорил, дописывать. Там же генерятся машинные инструкции, и для x64 они другие, регистров больше, т.е. V8 - это же фактически компилятор, и ему совсем не пофиг для какой платформы генерить код. AFAIK бинарной совместимости между записью машинных инструкций x86 и x64 нет.

> Flash 64bit нет вроде до сих пор...

Сто лет как есть. Сложностей никаких нет, просто кому-то лень собрать и запустить свой софт на 64х битах.

> Уговорил, дописывать. Там же генерятся машинные инструкции, и для x64 они другие, регистров больше,

Формат упаковки инструкций остался практически таким же. Опкоды такие же. 32-битный код будет спокойно работать на 64 битах.

Не знал, спасибо за инфу. А с поинтерами проблема будет(не полностью заполненные регистры)?

> Не знал, спасибо за инфу. А с поинтерами проблема будет(не полностью заполненные регистры)?

32-битный код в 32-битном сегменте будет работать в compatibility mode: формат инструкций старый, адресное пространство ограничено 4 гб.

> Она часто встречается.

Она часто встречается как причина любой проблемы. 8)) Так что лучше подняться на уровень выше, и описать последствия криворукости, которые непосредственно и приведут к проблемам в переносе на другую архитектуру.

> Ну вообще-то размер стандартных типов языка C (int,long, etc) зависит от разрядности системы независимо от OS.

Какая новость для меня... Номер параграфа в C99 не подскажете, где такое написано?

>Там есть JIT-движок жабоскрипта V8 который девелоперы не хотят портировать на x86-64 до тех пор пока x86-64 не станет десктопным мейнстримом везде включая виндовс.

Absurd тем не менее JIT на x86-64 у webkit давно есть. Смотреть 
/var/tmp/portage/net-libs/webkit-gtk-9999/work/webkit-9999/WebCore/bindings/v8
/var/tmp/portage/net-libs/webkit-gtk-9999/work/webkit-9999/JavaScriptCore/jit
и вот вам лог сборки net-libs:webkit-gtk-9999:20090802-091725.log    http://pastebin.ca/1536354 

А v8 пусть с ним гугл дальше играется. Дойдет до всего время...

>> Ну вообще-то размер стандартных типов языка C (int,long, etc) зависит от разрядности системы независимо от OS.

> Какая новость для меня... Номер параграфа в C99 не подскажете, где такое написано?

5.2.4.2.1, внимательно читать слова minimum/maximum.

Не знаю про "зависит независимо", но размер типов не определён. Есть соглашения ILP32, LP64 итп. Это и есть самые популярные грабли. Можно найти кучу быдлокода с приведением указателей к int (вместо intptr_t, если очень уж хочется) и наоборот.

> 5.2.4.2.1, внимательно читать слова minimum/maximum.

Ну дык ента... Где там сказано, что "размер стандартных типов языка C (int,long, etc) зависит от разрядности системы независимо от OS"? Там несколько не про то. Там про то, что гарантируется минимальный размер, а реальный может быть больше в зависимости от реализации, нет? Под рукой только драфт...

>Там про то, что гарантируется минимальный размер

По моему стандартом гарантируется только то что sizeof(char)<=sizeof(short)<=sizeof(int)<=sizeof(long)

> По моему стандартом гарантируется только то что sizeof(char)<=sizeof(short)<=sizeof(int)<=sizeof(long)

В C99 ввели минимальные размеры.

> В C99 ввели минимальные размеры.

А максимальные - нет. Поэтому int будет хотя бы 16-разрядный, но может оказаться и 32-, и 64-разрядным. Это из реальной жизни. Если он вдруг окажется килобитным, это тоже не выйдет за рамки стандарта :)

>Какая новость для меня... Номер параграфа в C99 не подскажете, где такое написано?

6.2.5 Types

A ‘‘plain’’ int object has the natural size suggested by the architecture of the execution environment (large enough to contain any value in the range INT_MIN to INT_MAX as defined in the header <limits.h>).

Вообще по идее создателей языка int соответствует разрядности процессора.

>> В C99 ввели минимальные размеры.

> А максимальные - нет.

О чём спорим-то? 8))

> A ‘‘plain’’ int object has the natural size suggested by the architecture of the execution environment (large enough to contain any value in the range INT_MIN to INT_MAX as defined in the header <limits.h>).

> Вообще по идее создателей языка int соответствует разрядности процессора.

Неочевидно, что natural size - это разрядность процессора. Вроде, в интеловском мануале по процам сказано, что шустрее всего обрабатываются 32-битные целые, а не 64, 16 или 8.

> О чём спорим-то? 8))

Интонация через форум не передаётся, а додумывается не всегда правильно ;)

> Уговорил, дописывать. Там же генерятся машинные инструкции, и для x64 они другие, регистров больше, т.е. V8 - это же фактически компилятор, и ему совсем не пофиг для какой платформы генерить код. AFAIK бинарной совместимости между записью машинных инструкций x86 и x64 нет.

А тем временем, они его почти дописали:

http://code.google.com/p/v8/issues/detail?id=330&colspec=ID%20Type%20Stat...

> Зато в линуксе, при условия правильного написания кода, проще получить преимущества 64х-разрядной системы.

А проясните такую вещь - 64битный процессор mov'ит 8 байт за то же время что 32битный 4 байта или нет?

Просто в противном случае неочевидно, откуда в 64битном режиме берётся ускорение.

> А проясните такую вещь - 64битный процессор mov'ит 8 байт за то же время что 32битный 4 байта или нет?

Если взять два сферических процессора в вакууме - 64х-разрядный и 32х-разрядный, то однозначно да =).

> Просто в противном случае неочевидно, откуда в 64битном режиме берётся ускорение.

Будет быстрее в случаях, когда нужна 64-разрядная целочисленная арифметика. Конкретно в amd64 ещё добавили новых регистров, примочек для виртуализации и т.п. Вот тут можно почитать: http://en.wikipedia.org/wiki/X86-64.

> Будет быстрее в случаях, когда нужна 64-разрядная целочисленная арифметика.

Я это и пытаюсь понять. 64битный проц mov'ит, складывает и перемножает 8-байтное значение за столько же тактов что и такой же точно но 32битный проц 4 байта, или нет?

> Я это и пытаюсь понять. 64битный проц mov'ит, складывает и перемножает 8-байтное значение за столько же тактов что и такой же точно но 32битный проц 4 байта, или нет?

В идеале - да.

вот статейка по теме. как-то пролетала на ЛОРе:

http://www.ibm.com/developerworks/library/l-port64.html

"Porting Linux applications to 64-bit systems"

А что скрывается под "не в идеале"?

> А что скрывается под "не в идеале"?

Под "не в идеале" скрывается, например, x86 и amd64. Из-за обилия всяких кешей, систем предсказаний, микрокодов, конвееров и прочих подобных примочек, невозможно однозначно сказать за сколько тактов выполнится та или иная инструкция.