Xpeccy

[Q-Master]

Всё, что было с порядком байт, находилось сугубо в z80.h, которого теперь нет - оно заменено на libz80ex. Так что проблема, судя по всему, в последней. Она у тебя самосборная или из готового пакета?

Из пакета. Должна работать, т.к. если судить по дебаггеру она там где-то блондится в ПЗУ, но на экране малевич. В случае косячного ПЗУ на экране косячный матрас.

[SAM style]

У меня вообще ничего эндиановского не осталось. Проверь либу на правильность - как inc c меняет всю пару bc. Если увеличивается на 256 - это оно, а если на 1 - хммм?..

[NovaStorm]

Дело небось не в эмуляции z80, а просто в перекидывании экрана.

[SAM style]

К моему формированию экрана тоже претензий по порядку байт нет - слой SDL 8-битный. Хотя, и это можно проверить - подождать несколько секунд, когда должно появиться 128-е меню и зажать вверх. Если начало трещать - работает, но не показывается. Если не начало - не работает.
Для информации - в git отпочковалась ветка testing, где сейчас обкатывается новая процедурина прорисовки экрана. Прирост скорости есть.

[ram_scan]

А это нужно знать? Мне достаточно знать, как давать компилятору подсказки и то, что он сгенерит код лучше, чем я.

Вот от этого мы и имеем ресурсожорких монстров которые на трехгигагерцовых пнях ворочаются медленнее чем в свое время на сотом пне летали. Компилятор не может сгенерировать код лучше программиста. Он может сгенерировать код лучше среднестатистического программиста. В большинстве случаев. И то не всегда. Поэтому если хотите получить хороший код - помогите компилятору.

Вон взять Шалаевский эмулятор. С той поры кроме нескольких недокументированных фичей и точных времянок не появилось в эмуляторах принципиально ничего нового. Толка тогда на 120-м пне оно летало со свистом, а сейчас на двухгигагерцовом каждый второй эмулятор лагает.

Потому-что "я синтаксически корректный код ему скормил, пускай оптимизирует".

Чтобы генерировать эффективный код нужно иметь представление как компилятор думает и во что примерно он скомпилирует ту или иную конструкцию. Тогда еще когда вы пишете код можно выбрать наиболее эффективную, даже если алгоритм чуть изменить придется для этого. Это называется "уметь эффективно пользоваться инструментом"

Потому-что где-то правильнее для какого-то конкретного компилятора сделать switch-case, а где-то if вложенный. Где-то надо цикл руками развернуть, а где-то компилятор сам справится. Где-то явное приведение типа в условии надо сделать, потому-что автоматическое приведение порождает функционально тот-же, но избыточный код, навроде test eax,1, and eax,eax, jz somewhat. Где-то в явном виде сделать табличный вызов функции, где-то отказаться от ООП чтобы не иметь оверхеда на цепочке inherited вызовов которые фактически nullsub-ами являются но программисту выяснять это лениво и он тупо inherited вызов делает, хуже то мол всяко не станет. Да прагму написать какую-нть иногда полезно бывает. Выравниванием поуправлять.

Я тут давеча код один ковырял. В некоторых местах оверхеда до 90% насчитал. Полмегабайта кода который реально не делае ничего, кроме передачи друг другу управления и возвращения единственного нулевого статуса. Просто потому-что две библиотеки писали разные люди которым было лень и некогда разбираться в другдружьем коде, а третий воспользовался библиотеками первых двух и тоже поленился разбираться, да еще отнаследовался не от того что надо а от того что на глаза попало. В итоге дикий оферхэд как по производительности так и по памяти (две сотни абстрактных методов еще, против десятка которые реально используются и переопределены). Это только один inherited вызов. Вложенность наследования - чуть более сотни. Единственный пустой метод. А там еще есть конструктор и деструктор как минимум. И все виртуальное. Нахрена ?

И никакой компилятор вместо программиста в таком головняке никогда не разберется. Потому-что искусственного интеллекта у него нет. А когда появится то и программист станет не нужен.

[Vitamin]

Вот от этого мы и имеем ресурсожорких монстров которые на трехгигагерцовых пнях ворочаются медленнее чем в свое время на сотом пне летали.

А еще раньше трава зеленее была и небо голубее.

Компилятор не может сгенерировать код лучше программиста. Он может сгенерировать код лучше среднестатистического программиста. В большинстве случаев. И то не всегда.

Компилятор- это всего лишь инструмент. Правильное применение снимает головную боль, неправильное- добавляет.

Поэтому если хотите получить хороший код - помогите компилятору.

Я про это и говорил.

Вон взять Шалаевский эмулятор. С той поры кроме нескольких недокументированных фичей и точных времянок не появилось в эмуляторах принципиально ничего нового. Толка тогда на 120-м пне оно летало со свистом, а сейчас на двухгигагерцовом каждый второй эмулятор лагает.

И где он теперь этот эмулятор Шалаева? Почему он не развивается? Может потому, что написан был для оптимизации по скорости под имеющееся на то время оборудование. Что привело к
а) абсолютной неподдерживаемости
б) абсолютной некроссплатформенности
в) далеко не оптимальной работе на современных платформах, ибо правила выполнения даже машинных кодов поменялись, а пересборка ассемблерного кода (в отличие от ЯВУ) бессмысленна

Потому-что "я синтаксически корректный код ему скормил, пускай оптимизирует".

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

Чтобы генерировать эффективный код нужно иметь представление как компилятор думает и во что примерно он скомпилирует ту или иную конструкцию. Тогда еще когда вы пишете код можно выбрать наиболее эффективную, даже если алгоритм чуть изменить придется для этого. Это называется "уметь эффективно пользоваться инструментом"

Потому-что где-то правильнее для какого-то конкретного компилятора сделать switch-case, а где-то if вложенный. Где-то надо цикл руками развернуть, а где-то компилятор сам справится. Где-то явное приведение типа в условии надо сделать, потому-что автоматическое приведение порождает функционально тот-же, но избыточный код, навроде test eax,1, and eax,eax, jz somewhat.

Существуют платформы, отличные от x86 (Всегда ваш, Капитан Очевидность).
Или ты можешь изглаголить универсальные рецепты по оптимизации под все возможные платформы?

Где-то в явном виде сделать табличный вызов функции, где-то отказаться от ООП чтобы не иметь оверхеда на цепочке inherited вызовов которые фактически nullsub-ами являются но программисту выяснять это лениво и он тупо inherited вызов делает, хуже то мол всяко не станет. Да прагму написать какую-нть иногда полезно бывает. Выравниванием поуправлять.

"Написать код, понятный компьютеру может каждый. Написать код, понятный человеку- далеко не каждый".

Я тут давеча код один ковырял. В некоторых местах оверхеда до 90% насчитал. Полмегабайта кода который реально не делае ничего, кроме передачи друг другу управления и возвращения единственного нулевого статуса. Просто потому-что две библиотеки писали разные люди которым было лень и некогда разбираться в другдружьем коде, а третий воспользовался библиотеками первых двух и тоже поленился разбираться, да еще отнаследовался не от того что надо а от того что на глаза попало. В итоге дикий оферхэд как по производительности так и по памяти (две сотни абстрактных методов еще, против десятка которые реально используются и переопределены). Это только один inherited вызов. Вложенность наследования - чуть более сотни. Единственный пустой метод. А там еще есть конструктор и деструктор как минимум. И все виртуальное. Нахрена ?

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

Я вот тоже видел программу, "оптимизированную по скорости", и располагающуюся в одном(!) файле размером в 600кб(!). Внутри километровые функции по тысяче строк. Сопровождению не поддается.

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

[Advertiser]

[NovaStorm]

А разве Шалаевский потактово эмулировал? С бордюром, лучом, и прочим?

[Vitamin]

А разве Шалаевский потактово эмулировал? С бордюром, лучом, и прочим?

Ага. И AY там круто на FM-синтезаторе сделан. И LDIR одной командой выполнялся.
Плагинная система- это да, круто, без вопросов.

[NovaStorm]

Гм, да. Сам же когда-то на нём мультиколоры смотрел.
>>И LDIR одной командой выполнялся.
Как это? А если прерывание?

[Vitamin]

Как это? А если прерывание?

Значит не судьба
Запусти тест из интро Iris Megademo. Там именно так тест тактов делается.