https://news.ycombinator.com/item?id=32148318
> And looking further down, some X86 instructions (that people would usually call low-level) actually trigger execution of an entire ELF binary inside the CPU
Схоронить пока не удолили: git clone https://github.com/chip-red-pill/MicrocodeDecryptor
Где скачать https://en.wikipedia.org/wiki/Blue_Pill_(software)#Red_Pill для amd64?
Тролльвардс попрофайлил прыщи и обнаружил, что 80% времени пейджфолта на хасвелле - это тормоза железа: https://plus.google.com/u/0/+LinusTorvalds/posts/YDKRFDwHwr6
PAUSE
Spin Loop Hint
Improves the performance of spin-wait loops. When executing a "spin-wait loop," a Pentium 4 or Intel Xeon processor suffers a severe performance penalty when exiting the loop because it detects a possible memory order violation. The PAUSE instruction provides a hint to the processor that the code sequence is a spin-wait loop. The processor uses this hint to avoid the memory order violation in most situations, which greatly improves processor performance. For this reason, it is recommended that a PAUSE instruction be placed in all spin-wait loops.
An additional function of the PAUSE instruction is to reduce the power consumed by a Pentium 4 processor while executing a spin loop. The Pentium 4 processor can execute a spin-wait loop extremely quickly, causing the processor to consume a lot of power while it waits for the resource it is spinning on to become available. Inserting a pause instruction in a spin-wait loop greatly reduces the processor's power consumption.
This instruction was introduced in the Pentium 4 processors, but is backward compatible with all IA-32 processors. In earlier IA-32 processors, the PAUSE instruction operates like a NOP instruction. The Pentium 4 and Intel Xeon processors implement the PAUSE instruction as a pre-defined delay. The delay is finite and can be zero for some processors. This instruction does not change the architectural state of the processor (that is, it performs essentially a delaying no-op operation).
#7O3DFJ
(2)
/ @ninesigns / 3937 дней назад
http://opencores.org/project,zet86
Реализация x86 SoC на Verilog для FPGA
http://www.via.com.tw/en/products/processors/quadcore/
У VIA, оказывается, тоже есть аппаратная поддержка виртуализации (VIA VT)
увидел у codedot-a в тватере: x86 MMU #PF handling is Turing-complete
http://www.youtube.com/watch?v=Y1ypnYIyzKk
#6MA8GV
(0+1)
/ @ninesigns / 4316 дней назад
Котаны, ситуация. Есть, допустим, линуксы x86_64. Есть старое приложение нативное под x86 ии есть вайноприложение, тоже x86.
Вопросы такие:
1. Смогу ли я запустить это нативное приложение в 64-битной системе? Как?
2. 64-битный вайн сможет запустить 32-битное приложение?
Оказывается, инженеры AMD64 подложили большую свинью быстрым песочницам и эмуляторам в юзерспейсе, запретив сегментацию даже в x86 программах. В нормальной x86 OS можно запрограммировать LDT как больше нравится, загрузить селекторы в сегментные регистры и, таким образом, получить эмулируемое окружение, например, Xbox или Linux, и даже долбаный fork(), от которого всё никак не откажутся в пользу pthread_create() и posix_spawn(), вполне реализуем без глюков (как в Cygwin), так как внутри эмулируемого окружения расположение нулевого смещения можно выбрать так, чтобы невыгружаемые страницы не занимали место, на котором в форкаемом процессе было что–то другое. В эмуляторе Xbox LDT используется, так как форматы fs:[...] на Windows и Xbox отличаются. А ещё есть программы, которые для противодействия отладке работают на изменённых селекторах. И всё это шмяк — и не работает. В принципе нельзя сделать, чтоб работало как раньше. Только fs и gs можно программировать.
Единственное решение в юзерспейсе — патчить код на лету, как это делает vx86. А ещё узнал, что для 64битной Windows нет coLinux.
ваше x86 говно и должно умереть http://blogs.msdn.com/oldnewthing/archiv.....47685.aspx
Цоперайт © 2010-2016 @stiletto.