почему? Я слышал, что он уже почти не используется

Я имею ввиду учить, чтобы использовать на практике, а не просто потому что надо)

Я имею ввиду учить, чтобы использовать на практике, а не просто потому что надо)

когда ты учился читать в детстве, ты использовал букварь или словарь Даля?

когда ты учился читать в детстве, ты использовал букварь или словарь Даля?

С такой точки зрения лучше вообще с ДОС начинать

тогда можно ожидать еще большее недовольство

Я имею ввиду учить, чтобы использовать на практике, а не просто потому что надо)

На практике скорей всего x86-64. Просто для обучения лучше arm или risc-v

Какой именно - Thumb, Thumb-2, Jazelle? А может AArch64?

А если ARM не поддерживает AArch64?

Значит не нужно учить ассемблер

почему? Я слышал, что он уже почти не используется

Используется, потому что более совместим со старыми ПК, а ещё вес меньше на выходе. В настоящий момент лучше писать на 32-х битную систему, чем на 64-х битную. Минусов от этого практически никаких.

Регистров больше на х64 зато, писать удобнее если программа не состоит из чисто вызовов функций

Надо учиться использовать как можно меньше регистров. И, в любом случае, есть память ещё. Так что не вижу ярких причин писать на x64.

🤔😳 Привет КТ315! Точно меньше? Наоборот же -> больше информации распихивать по регистрам - это хорошо

А что хорошего?

Надо учиться использовать как можно меньше регистров. И, в любом случае, есть память ещё. Так что не вижу ярких причин писать на x64.

скорость доступа

Регистры быстрее памяти

А где я писал "использовать меньше регистров, и больше памяти"? Я написал "использовать меньше регистров", я на x86 справляюсь и с EAX/EDX/ECX/EBX/ESI/EDI/EBP, даже не сохраняя их. Всё дело в продуманности алгоритма и его последовательности. Например, при обработке данных с файла - ты можешь, например, писать в тот же файл, и держать на дескриптор один регистр, а можешь в конце открыть файл ещё раз, либо писать в новый файл - и вот у тебя один свободный регистр. Скорость от этого особо не пострадает.

я такого не говорил... просто нет ничего плохого в использовании всех доступных регистров и учиться их использовать в меньшем количестве - зачем? не понятно...

я такого не говорил... просто нет ничего плохого в использовании всех доступных регистров и учиться их использовать в меньшем количестве - зачем? не понятно...

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

Не, ну скорость исполнения тоже не надо задвигать в дальний угол.

Чтобы хеловорлд не раздуть до 1.5 гигов.

1,5 гига чего? статической памяти?😄

Ты тоже не понял.

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

Экзешник

запакуй UPX'ом )

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

Ох как же после такого скорость исполнения упадёт))) атя-тя.

с чего она упадёт? он же распакуется и будет работать как и незапакованный

Нахера? Я не настолько говнокодер, чтобы получать хеловолд в гиг :-)

распакуется.

т.е. вы пользуетесь специально не всем набором регистров? )

2 секунды распаковка 10 минут работы несущественно

2 секунды распаковка 10 минут работы несущественно

чтобы вывести в консоль Hello, world

? что за бред

Нахера? Я не настолько говнокодер, чтобы получать хеловолд в гиг :-)

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

https://t.me/proasm/79017

ещё раз 2 секунды распаковки и 10 минут работы 10*60= 600секунд 2/600 = 0,3% времени работы вы ж сами говорите за алгоритмы, лучше улучшить алгоритм и получить +10% чем бодаться с 0.3% не так ли?

К слову, а у UPX есть вообще проверка на выходной размер? Если я скормлю ему 1 килобайтную программку на ассемблере, которая будет ЯВНО меньше кода распаковщика UPX - он выдаст мне на выходе "упаковнную" программу размером в 2-10 кб?))

Скажет, что исполняемый файл не сжимается.

К слову, а у UPX есть вообще проверка на выходной размер? Если я скормлю ему 1 килобайтную программку на ассемблере, которая будет ЯВНО меньше кода распаковщика UPX - он выдаст мне на выходе "упаковнную" программу размером в 2-10 кб?))

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

это лишь ответ был барону что он так печётся за 1,5 гиговые хеллоу ворлды ) а так-то зачем паковать, согласен

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

а вот какие алгоритмы ты уже писал?

сортировка пузырьком

не понял, что это

не понял, что это

алгоритм сортировки )

он тяжелый?

только регистров лишних не заюзайте! а то потом экзешники раздуваются!

Если это была попытка в шутку, то весьма хилая.

😆 учусь у вас )

Вопрос по поводу размеров: почему простенькая программка на nasm после ld весит 9 с лишним килобайт? Она не делает практически ничего. Внутри только объявлен и инициализирован массив на 25 dd.

что значит "практически"? где исходник?

Вопрос по поводу размеров: почему простенькая программка на nasm после ld весит 9 с лишним килобайт? Она не делает практически ничего. Внутри только объявлен и инициализирован массив на 25 dd.

соедини bss и data, будет меньше