Comments 15
насколько реально сейчас проводить разработку на ассемблере? Почему после декомпиляции межделмашевского компилятора (и в процессе доработки получения опыта) его не перевели на что-то более удобное (С там, или что). Как много людей могут этот компилятор развивать/поддерживать и с какими трудозатратами? что будет когда вы ум^w выйдете на пенсию?
А почему Вы привязались именно к «межделмашевскому» (кстати, что это?) компилятору?
А сколько вообще людей в мире могут компиляторы поддерживать/развивать и с какими трудозатратами? На мой взгляд, ассемблер здесь не самое сложное препятствие. И потеря энтузиастов для любого проекта грозит гибелью. Краткая история этого компилятора изложена здесь
вы зря на меня ээ обиделись что-ли. просто я писал когда-то на ассемблере и предстовляю себе сложность разработки и поддержки чего либо нетривиального на асме. я могу понять почему пишут драйвер на асме, почему добавляют в библиотеку вставки на асме, которые могут SSE наиболее эффективно использовать (или сложение с переносом, где перенос во флаге переполнения что-ли). а вот почему люди пишут компилятор (да, это достаточно сложная программа, которую не все осилят) на ассемблере - немного не понятно. где-же счас взять энтузиастов писать всё на ассемблере :-) В общем, не сердитесь, сложный проект, который развивается и приносит пользу - большой плюс автору(ам). межделмаш - была такая калька с IBM.
В своё время я был энтузиастом ассемблера, и даже уже зная и используя высокоуровневые языки и среды разработки пытался поддерживать и маленькое и уютное рабочее окружение хакера и кракера :). Писал довольно комплексные многооконные утилитки с помощьюи RadAsm в качестве IDE и MASM32 (выковырянном из MS VC++) и FASM в качестве компиляторов. Компиляторы, к слову, обладали довольно жирными возможностями написания макросов, и облегчали рутину не только вызова функций (со всеми этими проталкиваниями аргументов в стек), но даже позволяли писать конструкции типа IF или FOR :). В целом по степени выразительности они уже мало отличались от языка C (без плюсов, который, собственно, и был/есть эдаким «кроссплатформенным ассемблером»). Но сейчас, конечно, комплексность прикладных программ такова, что средства управления сложностью в ассемблере остаются уместными только для очень системного и «локального» программирования :).
Хм. Если б я, в эпоху активного программирования на ассемблере, сподобился сделать свой компилятор с мало-мальски удобного языка, то и развивал бы его, и дальше все писал только на этом языке. :)
Поэтому сокращение кода сейчас больше влияет на скорость работы, чем раньше.
Всё-таки меньше, ибо это всё будет читаться из многоуровневого кэша (на поведение которого в многопроцессных окружениях вообще невозможно контролируемо вилять из одного пользовательского потока исполнения), куда данные черпаются такими объёмами, что подобные оптимизации выглядят попыткой стереть пылинку с самосвала, чтобы он стал легче и поехал быстрее :). ИМХО.
Если в далекие времена процессора 8086 чтение команд из памяти занимало тактов 25, а выполнение команды – тактов 10, то сейчас выполнение команды может занимать 1-2 такта, а чтение кода из памяти – тактов 200 (если не все 400). Поэтому сокращение кода сейчас больше влияет на скорость работы, чем раньше.
не совсем корректное сравнение. скорость чтения/записи в память очень высокая, например:
Twelve 64-bit DDR5 memory channels would theoretically increase the memory bandwidth available to Genoa processors to a whopping 460.8 GB/s per socket
а вот задержка уже лет двадцать остаётся в диапазоне 10-20 нс, то есть десятки тактов процессора.
сомневаюсь, что подобные оптимизации окажут насколько-либо измеримое влияние на производительность, они не изменят число промахов кэша, а само по себе уменьшение размера кода даст гомеопатический прирост производительности.
но почитать было интересно )
Интересная находка. А другие компиляторы точно это не используют?
Если производительность не поднялась, то есть ли толк?
Замечу как раз такие "оптимизации" может делать только компилятор, при программировании непосредственно на ассемблере я бы предпочел не делать такие "оптимизации" руками. Код легко может стать невалидным при малейшем изменении взаимных смешений.
И еще насколько я помню комманда lea edx,[rbx]-8 должна быть записана как lea edx,[rbx - 8] (смещение внутри скобок), тоже самое насчет mov rbx,[rdx]+0ffffff80h.
Совершенно верно. Это не для программирования вручную. Ведь пришлось даже оставить вывод псевдоассемблера без оптимизации, иначе бывает непонятно, что вообще за команды лепятся ))
Запись адресации на ассемблере - это дело вкуса. На мой взгляд, в скобках должен быть только регистр или пара регистров с масштабным коэффициентом. Это и ближе к замыслу системы кодировки команд x86.
А кроме того, так изначально было принято в трансляторе с ассемблера, который я тоже имею честь сопровождать ))
Наример,
mov eax, ebxпротив
mov eax, [ebx]Хотя наверное ваша запись имеет происхождение от си-шного синтаксиса
array1[i]:mov eax, array1[ebx]которое потом как-то превратилось в
mov eax, [ebx]+array1
Когда разница адресов имеет значение