x86_64 x86 llvm ada TenDRA Об исключенных командах или за что «списали» инструкцию INTO?
Любопытно было почитать материал от разработчика компилятора, способного выжимать из процессора максимум. Ещё @Tajunu писал про ущербность LLVM по сравнению с TenDRA, но так, достаточно поверхностно, а тут — от того, кто реально в теме.

Ну и интересно было узнать, что это не чисто случайно под Аду подходит, а под PL/1 делалось, а Ада попутно получилась, как тоже нормальный язык программирования.

x86_64 SEH GCC amd64 mingw64 SEH_Init

On x86_64 windows exception mechanism is no more based on a chained list of handlers addresses on the stack. Instead unwinding information is used to retrieve the exception handler (similar to ZCX GCC mechanism). So in order to register an exception handler we need to put in the final executable some unwinding information. This information might be present statically in the image file inside the .pdata section or registered through RtlAddFunctionTable API. Currently the GCC toolchain does not generate the .pdata information for each function. As we don't need to handle SEH exceptions except for signal handling we are registering a "fake" unwinding data that associate a SEH exception handler to the complete .text section. As we never return from the handler, the system does not try to do the final unwinding using the pdata information. The unwinding is handled by the runtime using either the GNAT SJLJ mechanism or the ZCX GCC mechanism. The current implementation is using the RtlAddFunctionTable.

Here is for information purposes the equivalent using a static .pdata section: …

Теперь понятно, что имеет в виду @vt под «знает, как компилировать под Windows». Если считать Microsoft законодателем мод, то что-то в этом есть, хотя как по мне, — скорее вкусовщина. По-любому, без брандмауэров исключений никакой работы с COM не делается, так что какая разница, что внутри.

lubuntu x86_64 vs *i386
У меня, наконец, дошли руки сравнить в лоб 32 и 64 битные системы по потреблению памяти. Поставил две совершенно идентичных Lubuntu в виртуалках и работаю сейчас с ними синхронно. Вот результат.

Обратите внимание на VIRT в Хроме :D

~~~

А тут — ещё немного LibreOffice: i.imgur.com

mingw wыndows x86_64 Win8 work Работа, обновили комп, на компе стоит win8 с установленным ClassicShell вроде как даже пользоваться можно, система 64битная. Решил попрбовать mingw, который использую для различных симуляций, поставить 64битный тоже и собрать за компанию свежий буст... Как результат, на сборке фейлится cc1plus (выдаётся сообщение: cc1plus.exe has stopped working). При этом были опробованы различные 64бит сборки mingw — везде результат один и тот же. На маленьких файлах нифига не воспроизводится. Гугл обозначивает проблему, частично отсылает к editbin и играм с размером стека, но решения окончательного так и не даёт. При этом 32бит версией компилятора на этой же машине всё отлично строится.

В общем, кто сталкивался, как решали?

x86_64 Linux Gentoo qemu /etc/init.d/qemu-binfmt по непонятной причине регает какие угодно архитектуры, но только не x86_64. Чтобы добавить поддержку x86_64, нужно просто продолжить по аналогии ряд

echo ':alpha:M::\x7fELF\x02\x01\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x02\x00\x26\x90:\xff\xff\xff\xff\xff\xfe\xfe\xff\xff\xff\xff\xff\xff\xff\xff\xff\xfe\xff\xff\xff:/usr/bin/qemu-static-alpha-binfmt:' > /proc/sys/fs/binfmt_misc/register
echo ':arm:M::\x7fELF\x01\x01\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x02\x00\x28\x00:\xff\xff\xff\xff\xff\xff\xff\x00\xff\xff\xff\xff\xff\xff\xff\xff\xfe\xff\xff\xff:/qemu-static-arm-binfmt:' > /proc/sys/fs/binfmt_misc/register
echo ':sparc:M::\x7fELF\x01\x02\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x02\x00\x02:\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xfe\xff\xff:/usr/bin/qemu-static-sparc-binfmt:' > /proc/sys/fs/binfmt_misc/register

x86_64 x86 ldt asm Оказывается, инженеры AMD64 подложили большую свинью быстрым песочницам и эмуляторам в юзерспейсе, запретив сегментацию даже в x86 программах. В нормальной x86 OS можно запрограммировать LDT как больше нравится, загрузить селекторы в сегментные регистры и, таким образом, получить эмулируемое окружение, например, Xbox или Linux, и даже долбаный fork(), от которого всё никак не откажутся в пользу pthread_create() и posix_spawn(), вполне реализуем без глюков (как в Cygwin), так как внутри эмулируемого окружения расположение нулевого смещения можно выбрать так, чтобы невыгружаемые страницы не занимали место, на котором в форкаемом процессе было что–то другое. В эмуляторе Xbox LDT используется, так как форматы fs:[...] на Windows и Xbox отличаются. А ещё есть программы, которые для противодействия отладке работают на изменённых селекторах. И всё это шмяк — и не работает. В принципе нельзя сделать, чтоб работало как раньше. Только fs и gs можно программировать.

Единственное решение в юзерспейсе — патчить код на лету, как это делает vx86. А ещё вчера узнал, что для 64битной Windows нет coLinux.

log x86_64 софт Opera Новая сборка Opera Next.
-64-битная версия
-Drag'n'Drop
-CSS3 Animation
-Плагины работают отдельными процессами.
my.opera.com
P.S. Можно поставить параллельно обычной Opera, у них будут разные настройки.

x86_64 sbcl see_/12 it's_work Windows Антон Коваленко анонсировал, что он завёл sbcl на x86-64 архитектуре. Собственно линк: siftsoft.com

Его порт явно не может работать (как минимум из-за того что в src/runtime/x86-64-assem.S не исправлено соглашение о передаче параметров, которое на win64 отличается от всех остальных x86_64 систем) и у меня не работает. Жуйкоюзер, если у тебя шестидесятичетырёхбитные окошки — можешь попробовать запустить? Если я правильно понимаю код и это не мои локальные проблемы, а он действительно не работает, то надо будет идти в рассылку со своим вариантом порта (где на данный момент GC ещё не хочет работать, но вся остальная инициализация из src/code/cold-init.lisp проходит).

x86_64 sbcl Windows Кроме указанных в предыдущем сообщении проблем (вторая и третья поправлены, первая заменена заглушкой) наткнулся на то, что соглашения о вызове функций на Windows x64 отличается от всех остальных систем архитектуры x86_64. Так в юниксах для аргументов используется соответственно последовательность мест "rdi — rsi — rdx — rcx — r8 — r9 — rest on stack", а для windows x64 "rcx — rdx — r8 — r9 — rest on stack".

Пока получается что-то вроде pastebin.com

Наверное стоить оформить окончательно удаление long из кода и, если такие изменения не придутся по нраву разработчикам sbcl, то забить на доведение кода до рабочего состояния.

x86_64 sbcl Windows Для портирования SBCL на 64-битную Windows необходимо решить три проблемы:

1. Замена SEH на VEH, для обработки ошибок. Тут можно оставить заглушку до тех пор, пока не соберется относительно рабочий SBCL.
2. Изменить схемы именования системных функций. Так функции, которые в 32-битной системе (кстати, это особенность Windows или MinGW?) соответствуют символам "_Name@number", а в 64-битной "_Name" или просто "Name" (откуда возникает эта проблема? В amd64-mingw у меня под дебианом создаются символы "_Name", а с использованием drangon.org сборки — "Name")
3. Убрать из исходников надежду на то, что система поддерживает ANSI C. Или, говоря конкретнее, исправить все места, где встречается long int или unsigned long int, подставив вместо long подходящий тип, который будет иметь размер не меньше, чем long int, int и void* на всех архитектурах.

Третий пункт требует порядка 500 правок. К сожалению после того как я внёс эти правки, а также поправил правила именования и организовал заглушку на исключениях, получившийся runtime не в состоянии правильно разобрать сгенерированный в результате кросскомпиляции sbcl.core файл. Так что, судя по всему, до сих пор в коде есть места, в которых размеры переменных не сходятся.

x86_64 Flash Когда флеш для 64-систем от адобе был в глубокой альфе и развиваться совсем не планировал, фф с ним работал как с родным.
Сейчас когда адобе опять начал пилить, стоит только сменить вкладку в фф с роликом на другую и вернуться наза, как имею "The Adobe Flash pligin has crashed".
Чувствуется, что ребята работают и там и там.

fail x86_64 VirtualBox блин, ну почему виртуалбокс не умеет гостевые 64 разрядные системы на 32 разрядной хостовой? какой-то угребищный монстроподобный вмваре умеет, а уютный ламповый виртуалбокс нет :( что за несправедливость >__<

x86_64 Linux Господа, скажите, на сколько 64 разрядные дистрибутивы хороши? То есть стоит ли переходить на х86_64 и какие есть подводные камни? И вообще, как субъективные впечатления от пользования 64 разряжных по сравнению с 32?

x86_64 ненависть x86 арч убунта всё! больше нет Арча на моём ноуте.. заебало.. в конце концов я программист и обычный пользователь, и мне действительно Арч мешает спокойному написанию и отладке кода, а также просмотру видео и прочего... постоянно трясёшься перед обновлением (иногда вынужденным!) хотя, надо отметить, прозрачность Арча помогала не раз, и в душе я всё равно арчер, арчер, ищущий стабильность и простоту... ждём Арч-стабля... так же надо отметить, что в моей личной жизни больше нет богомерзкого x86_64 (это не значит, что x86 православен): так же заебало, но уже как программиста... фух [выдохнул]. аминь.

x86_64 ненависть pusha <-- error: instruction not supported in 64-bit mode... чё делать, чё делать?

x86_64 Linux Поставил альфа-версию 64-х битного flash-plugin'а и, слава Туксу, заработал звук во флэше. Но флэш всё равно не нужен, да.