ビリャチピスデツナフイ Войти !bnw Сегодня Клубы
Привет, TbI — HRWKA! 1239.0 пользователей не могут ошибаться!
?6942
прекрасное6443
говно5905
говнорашка5512
хуита4712
anime3066
linux2652
music2634
bnw2601
рашка2565
log2354
ололо2170
дунч1822
pic1815
сталирасты1491
украина1439
быдло1437
bnw_ppl1418
дыбр1238
гімно1158

Мне бы хотелось поподробней узнать, как обстоят дела с обучением низкоуровневому программированию в вузах. В частности http://dump.bitcheese.net/files/owujilu/method-vax.doc вот методичка одного питерского вуза, их там учат писать под VAX, притом писать не на ассемблере, а напрямую в машинных кодах, примерно как через щестнадцатиричный редактор http://dump.bitcheese.net/files/ihewiso/vaxsim.tar.bz2 притом этот говноэмулятор написан какими-то студентами на дельфи, и не все инструкции там реализованы. Еще студентов учат писать под КР580ВМ80 (совместим с i8080A) вот на такой хрени УМПК-80 http://img.radiokot.ru/files/24372/2if8g5o5k.jpg и конечно же в комплекте к этому идет багованный эмулятор, написанный на дельфях, скачать и посмотреть скриншоты можно тут http://cifra.studentmiv.ru/simulyator-umpk-80/ А да, еще в вузах студентов учат программировать под DOS в реальном режиме, переключать видеорежим через INT 10H, сегментной адресации в реальном режиме и тому подобному Нахера учить такую херню в вузах? Возьмите какой-нибудь *актуальный* микроконтроллер, можно AVR, ARM, MIPS, учите писать на нем. Может @dluciv может это как-нибудь прокомментировать
#HUHBSY (65+5) / @j123123 / 3174 дня назад

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 / 3910 дней назад

http://ache.vniz.net/demos.html охуительная история:

Своеобразный программисткий подвиг совершил Дима Бурков. В то время начали появляться первые PC. Unix на них выглядел неубедительно. Linux еще не появился, зато повился Venix. Хачить его было невозможно - не было исходных текстов ядра. Дима Бурков реассемблировал ядро, потом писал программы на Си, которые давали тот же текст ассемблера - так появились тексты ядра на Си ... работа не для слабонервных.

#FBAN47 (0) / @j123123 / 4038 дней назад

Проверял GCC на предмет того, как он умеет рекурсию оптимизировать.
Вот такая штука

unsigned int plus(unsigned int a, unsigned int b)
{
  if (b == 0) return a;
  return plus (a+1, b-1);
}

Относительно успешно сворачивается сложение. Получается такая шняга:

movl %edi, %eax
addl %esi, %eax
ret

Хотя в идеале можно было бы обойтись

leal (%rsi,%rdi), %eax
ret

Что касается умножения, там ситуация более печальная

inline unsigned long int product_0(const unsigned int a, const unsigned int b, const unsigned long int tmp)
{
  if (b == 0) return tmp;
  return product_0(a, b-1, tmp+a);
}

unsigned long int product(const unsigned int a, const unsigned int b)
{
  return product_0(a, b, 0);
}

В ассемблере получается такая фигня

product:
.LFB34:
.cfi_startproc
    xorl %eax, %eax
    testl %esi, %esi
    je .L7
    leal -1(%rsi), %eax
    mov %edi, %edi
    addq $1, %rax
    imulq %rdi, %rax
.L7:
    rep
    ret
.cfi_endproc

Тут оно зачем-то зануляет значение регистра, в котором хранится возврашемое из функции значение и сравнивает с нулем значение регистра, в котором в функцию передается число. Если ноль то прыгаем в конец функции, возвращая 0. Тогда внезапно появляется смысл в этом rep ret http://repzret.org/p/repzret/

Why? Because “The processor is unable to apply a branch prediction to the single-byte near-return form (opcode C3h) of the ret instruction.” Thus, “Use of a two-byte near-return can improve performance”, because it is not affected by this shortcoming.

Ну а дальше через leal из регистра rsi число копируется в eax, уменьшаясь при этом на 1 (нахрена?) и потом из регистра edi двигается в edi (НАХРЕНА??), увеличиваем rax на 1 через addq (ну тут понятно зачем, перед этим ведь оно было непонятно зачем уменьшено на 1, но нахрена уменьшать и потом увеличивать? И вообще, для увеличения на 1 лучше incq использовать) ну и в итоге компилятор таки вставляет инструкцию imulq. Распознать умножение в этой рекурсивной хрени компилятор смог, но при этом как-то через жопу все, нагенерировал кучу говна всякого. Можно было намного проще сделать

movl %esi, %eax
imull %edi, %eax

gcc version 4.5.1 если что

#3BR06J (1+1) / @j123123 / 4058 дней назад

http://govnokod.ru/13470#comment189390

А я ассемблерщика знаю. Пишет биосы. Играет с ботами в квейк. С работы уходит последним. В 40 живет с мамой.

Прямо таки герои нашего времени...

#UK66KH (0) / @j123123 / 4135 дней назад

https://i.imgur.com/8DQTtCs.png
Процесс обучения сишкоасмоебству. Указатели на функции. Watcom Debugger. XP. Виртуалка.
http://ideone.com/W1XMHh - код

#HEFX8X (0) / @j123123 / 4139 дней назад

https://research.microsoft.com/en-us/um/people/simonpj/papers/ndp/haskell-beats-C.pdf

Abstract
Stream fusion [6] is a powerful technique for automatically transforming high-level sequence-processing functions into efficient implementations. It has been used to great effect in Haskell libraries for manipulating byte arrays, Unicode text, and unboxed vectors. However, some operations, like vector append, still do not perform well within the standard stream fusion framework. Others, like SIMD computation using the SSE and AVX instructions available on modern x86 chips, do not seem to fit in the framework at all.
In this paper we introduce generalized stream fusion, which solves these issues. The key insight is to bundle together multiple stream representations, each tuned for a particular class of stream consumer. We also describe a stream representation suited for ef ficient computation with SSE instructions. Our ideas are implemented in modified versions of the GHC compiler and vector library. Benchmarks show that high-level Haskell code written using our compiler and libraries can produce code that is faster than both compiler- and hand-vectorized C.

На ассемблере такие вещи надо делать. Алсо, тут http://benchmarksgame.alioth.debian.org/u64q/benchmark.php?test=all&lang=gcc&lang2=ghc&data=u64q хаскель сливает сишке почти по всем пунктам. И я бы не сказал, что кода на х-е сильно меньше, чем кода на Си

#BAHBZO (7) / @j123123 / 4157 дней назад

http://gcc.1065356.n5.nabble.com/Ways-to-fill-the-stack-td912561.html#none
Если через запятую объявлять члены массива из char в C и откомпилить это в GCC, оно это запишет как куча mov-ов по байтику
sztfg - я

#SG2QH2 (6) / @j123123 / 4157 дней назад

Тут я отвечу на вопрос "Зачем нормальный программист должен знать ассемблер?" но сначала пятиминутка ненависти

Ну собственно, есть такая тема, что люди, которые не то что ассемблера, даже сишку толком не пробовавшие, пишут на своих жабоскриптах такую дикую хуиту с точки зрения оптимизации, что просто пиздец. Ибо нет нифига понимания(даже примерного) в какие такие машинные инструкции будет оттранслирована та хуерга, которую наплодили эти "программисты".
Раньше мой дед на целероне 400 мгц 256 метрами ОЗУ успешно смотрел интернет на несвежем дистрибутиви GNU/Linux. Но потом тупые индусы понаделали тормозных жабаскриптов и дед начал жаловаться на появление какого-то непонятного окошка "скрипт недоступен". Он еще начал интересоваться, что такое скрипт и на что он должен отвечать. Ну типа типичные последствия. Вообще, дофига сайтов адово тормозят от этих говен, поэтому у меня NoScript всегда наготове, ибо от этого говна тормозятся даже современные браузеры на современном железе. Это ж надо было дойти до того, чтобы делать абгрейд из-за того, что какие-то *** понаписали быдлокода на JS? Если вы у себя на сервер-сайде ворочаете всякие тормозные питоны, похопе и Node.js то это ваши личные половые проблемы. Но вот когда вы кормите этим JS-говном МОЙ процессор, тут уж я на это вынужден применять меры, вроде NoScript
http://www.opennet.ru/opennews/art.shtml?num=36962 вот на такое клиенд-сайд веб программирование (если его сильно запаковать в сандбокс) я согласен. Есть еще такая тема, как asm.js http://habrahabr.ru/post/171561/ но это всё полумеры.

А теперь по теме, нафига вообще ASM. Любой (за исключением CUDA и прочей GPU-ускоренной хреноты) код на любом ЯП в итоге транслитуется в опкоды и переваривается центральным процессором (всякие CUDA и опенжл передаются в видеокарту и перевариваются через GPU). Я лично не против, чтобы кто-нибудь писал на языках, подобных Java, JavaScript, Python, Ruby и что там еще... Вся беда в том, что для эффективного программирования даже на таких ВЫСОКОУРОВНЕВЫХ ЯП как эти, необходимо хотя бы примерно представлять, в какой машинный код преобразуются ваши высокоуровневые конструкции.
Иногда приходится смотреть на сгенерированный сишным компилятором код, чтобы понять причины тормозов. Чтение ассемблерного выхлопа GCC позволило мне выявить хреновую оптимизацию записывания байтиков в стек, вот http://gcc.1065356.n5.nabble.com/Ways-to-fill-the-stack-td912561.html почитайте (да, я знаю, у меня плохой английский)

Понимание архитектуры ЭВМ, недостатков некоторых вещей (типа NULL-terminated string http://www.joelonsoftware.com/articles/fog0000000319.html ) позволяет избегать ошибок на более высоких уровнях.
Меня тут обвиняли что я статейки какие-то даю, так вот тут я их действительно выдам
http://www.joelonsoftware.com/articles/ThePerilsofJavaSchools.html
https://lwn.net/Articles/250967/
http://www.insidepro.com/kk/145/145r.shtml
https://savannah.nongnu.org/projects/pgubook/

И вот типа цитата, но я не вполне согласен с ней. Иногда ASM нужен именно для написания

Целью обучения программированию на асме, как ни странно, не может быть само по себе программирование на асме, это навык (если его рассматривать с профессионально-коммерческой точки зрения) абсолютно бессмысленный. Никто никогда не пишет на асме. Но при этом опыт такого писания жизненно необходим, чтобы примерно представлять себе, что на самом деле происходит при выполнении программы. И с этой колокольни, вообще говоря, пофигу, какой ассемблер и под какой процессор изучать. Ну, допустим, процессор всё-таки желательно использовать живой и реально существующий, чтобы не оставалось ощущения, что «с настоящим точно не получится», но и только.

Критика приветствуется

#GHU55Z (53+3) / @j123123 / 4200 дней назад

http://dump.bitcheese.net/images/otozemi/sdfsdb.png процесс удаленного обучения ассемблеру пол виндой (винапи)

#MU0PC5 (4) / @j123123 / 4205 дней назад

Вот говорят, что софт, написанный руками на ассемблере работает быстрее, чем софт, написанный на более высокоуровневых языках. И ведь не врут. Правда, не за счёт того, что «человек делает это лучше, чем машина», а потому, что такой софт, как правило, ничерта не умеет.

Навеяно новостью про KolibriN.

#LB55WN (0) / @pew / 4280 дней назад
Оказывается, инженеры AMD64 подложили большую свинью быстрым песочницам и эмуляторам в юзерспейсе, запретив сегментацию даже в x86 программах. В нормальной x86 OS можно запрограммировать LDT как больше нравится, загрузить селекторы в сегментные регистры и, таким образом, получить эмулируемое окружение, например, Xbox или Linux, и даже долбаный fork(), от которого всё никак не откажутся в пользу pthread_create() и posix_spawn(), вполне реализуем без глюков (как в Cygwin), так как внутри эмулируемого окружения расположение нулевого смещения можно выбрать так, чтобы невыгружаемые страницы не занимали место, на котором в форкаемом процессе было что–то другое. В эмуляторе Xbox LDT используется, так как форматы fs:[...] на Windows и Xbox отличаются. А ещё есть программы, которые для противодействия отладке работают на изменённых селекторах. И всё это шмяк — и не работает. В принципе нельзя сделать, чтоб работало как раньше. Только fs и gs можно программировать. Единственное решение в юзерспейсе — патчить код на лету, как это делает vx86. А ещё узнал, что для 64битной Windows нет coLinux.
#BN2E23 (1+3) / @octagram / 4479 дней назад
FUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUtex'ы КАКОЙ ВКУСНЕНЬКИЙ ДМЕСГ http://dpaste.com/541905/
#ZJE2V8 (0) / @stiletto / 4941 день назад
ipv6 ready BnW для ведрофона BnW на Реформале Викивач Котятки

Цоперайт © 2010-2016 @stiletto.