hex редактирование

0x00010000
со времен появления Z80 малость всё изменилось: память дешевая и быстрая, процессоры мегабыстрые (огромные кэши, паралельные вычисления с предсказаниями, сопроцессоры etc.), отладочных средств пруд пруди, оптимизирующие компиляторы и д.р. "Возьми в руки" мануалы по платформе для которой собираешься оптимизировать и учи мат.часть от корки до корки, выбери ОСы в которых будут выполняться твои программы, найди руководства по оптимизации под выбранные ОСы и платформу.

 

Смотря для каких задач.
Тот же Crysis на ультра-настройках с трудом тянут топовые модели.
Если бы тс отреверсил бы кризис и переписал его ядро хекскодами, с учетом оптимизации под основные модели процессоров - миллионы геймеров сказали бы ему спасибо

 

dyn
Можно проще сделать: выпускать на загрузочном DVD игру под всевозможные сочитания процесор/логика/шина/видео карта, на своей ОСе (или без оной ибо зачем нам для игры какието ненужные функции которые дает ОС) которая также будет оптимизирована под конкретную платформу, думаю работать будет мега быстро и стоить будет мега дорого но зато есть вероятность что пойдёт даже на iP133 и S3 V+ которые стоят не дорого =)
P.S.
Хороший вариант для приставок игровых =)

 

Ну ты сравнил. Машкоды в 50-х были не сложнее программируемого калькулятора. Я ж говорю - для ВМ80 я помнил все опкоды, читал дампы и писал сразу кодом... потому что ассемблер на Радио-РК очень долго с магнитофона грузить. Но что я писал? И как? Тетрис, что-то типа "питона", хекс-редактор. Сначала на бумаге алгоритмом, потом забивал опкоды, отмечая на бумаге же адреса "меток", чтобы когда до цикла дойдет, не надо было смотреть в дамп, а сразу число вставить. Часть опкодов можно было не использовать в принципе - RST, IN, OUT, HLT - "прерывания" отсутствуют, писать свои процедуры для вызова через RST смысла нет - чай не 2К пишу, а 200 байт. Порты не нужны, чтение символов и вывод на экран - есть точки входа в стандартные процедуры. Да и вывод на экран проще простого, никаких атрибутов - что записал то и увидел. В 256 байт на ВМ80 тетрис укладывался на ура (даже компактнее). И хекс-редактор тоже. А еще было бальзамом на душу обнаружить в журнале дампы "тетриса", написанные кем-то, и сказать себе "А у меня короче вышло!".
Для х86 опкодов - вдвое (втрое, а вместе с FP-MMX-SSE - раз в десять) больше. Структурированы они хуже. Переходы - те, которые оптимальные и короткие - относительные. То есть +- от перехода - считать запаришься. 256 байт написал - день пролетел незаметно.
Это может и нормальное времяпровождение для школьника старших класов, но уже в институте на такое хобби просто жалко время тратить. Учитывая, что есть более удобные способы что-то написать.

 

Это имеет смысл только в одном случае : при разработке нового процессора или модернизации старого. Машинный код сделан для машины и человеку абсолютно неудобен. Интелловский опкод несет на себе большой груз "надстроек в процессе расширения" - одни и те же коды в разных режимах означают разные команды. Но к программированию и оптимизации это никакого отношения не имеет.

Вынужден тебя огорчить, но никогда не писали. Они писали на бумажке некое подобие ассемблера и потом переводили в коды и набирали либо на перфоносителях, либо прямо на переключателях.
Действительно потом имелись наборы бинарников и их "склеивал" ассемблер(сборщик). И только потом "ленивые" люди сообразили, что можно писать на ассемблере(он кстати сначала назывался автокод !!) и не заниматься ерундой.

Это называется "деградация". Я не буду создавать ничего нового, а улучшу чужое. Дорога в никуда.
Оправдано только при ломании и отсутствии исходников. А ведь ты начал тему про разработку своего. Тебе и отвечали про это. Оптимизация в кодах не в команде(группе) и без школы - это нонсенс.

 

65536
тут правильно заметили. скачай лучше маны от Интела, включая тот мануал который про оптимизацию. я считаю, это будет куда полезнее, чем запоминать хексы

зная наизусть хексы, максимум на что ты можешь рассчитывать - это минимизация размера кода, но это вовсе не означает его эффективность. оптимизация заключается в другом.

 

0xFFFF+1

Попробуй написать (начать) что-то типа дизассемблера хотя бы для инструкций Intel "без надстроек". Практически наверняка, _я_гарантирую_это_ (c) ты забьешь на свою идею (точнее просто осознаешь место знания "HEX-кодофф" в общей базе знаний языка Машины).

После достаточной практики ты также должен понять что глубина знаний тут в _общем_ понимании - например как осуществляется обработка исключения в защищенном режиме - всех команд и т.д.

Ну а если не осознаешь то и mockery by luckysundog тоже не простебут тебя

 

Хорошо. Значит мануалы посмотрим, Оси и платформы тоже. Насчет хексовой оптимизаций игр не. Но иногда, признаюсь честно, мне приходила в голову мысль что если бы современную Ось в Microsoftе писали бы не на Си а на Асме или хекс то работала бы втрое быстрее и диск загрузочный меньше (а может и глюков поубавилось) и было бы понятно почему они гнут такую цену за "лицензионку". Вся банальность как видите упирается в "если бы". Ладно, это оставлю на далёкое будущее, а сейчас мне пока нечего больше спросить о опкодах, спрошу ещё раз, как сделать чтобы в этой теме после последнего комента справа внизу висело "Тема закрыта"? Я сам могу это сделать или это делают великие Сэнсэи из администрации?

 

--------------------------------------
И написали бы ее втрое быстрее наверно )

 

65536
это делают модеры.

 

а какие проблемы c Си ? компилятор порой оптимизирует лучше человека

тебе необходимо понять, что быстрый код начинается прежде всего с эффективных *алгоритмов*. если алгоритм тупой, то он и реализованный на асме будет работать тухло. это, я считаю, куда важнее(или первичнее), чем всякие оптимизационные трюки.

глюков, а точнее багов в коде было бы просто дофига, причем искать их пришлось бы с лупой в руках. более того, программисты бы наверняка начали юзать для удобства макросы и прочее, чтобы не писать много одинакового кода, тем самым приближаясь ко всем удобствам C

 

Жмешь кнопку "Сообщить модератору". Говорят, что там дальше все понятно.

 

я бы сказал, что порой человек оптимизирует лучше компилятора.

 

Закрыто.