1. «Кривуля» чаще всего функция sin. Таблицы — это всё.
2. Храни sin в таблице 256 байт, рассчитай заранее.
3. Загрузи старшую половину регистровой пары чтобы получить адрес таблицы, пусть это будет H
4. Тогда L — будет произвольный аргумент функции.
5. Крути L как угодно — будешь ходить по функции туда-сюда.
6. Читай значения sin как LD reg,(HL)
7. cos это то же самое что sin, но сдвинутый на четверть периода. И наоборот. Четверть периода это регистр L +- 64
8. Удобно вместо значений sin/cos сразу прошить таблицу адресами.
9. Значения таблиц sin можно подготовить на старте.
Посыпаю голову пеплом, мне не удалось объяснить =) Я про дебаг, не про intellisence.
Дебаггером в отладке не простепаешь по statements в строке.
Дебаг-инфа сохраняется в виде адрес->строчка исходного кода.
Я скорее о том что существуют два вектора — люди в сторону усложнения, и люди в сторону упрощения.
(Эйнштейн) «Все должно быть изложено так просто, как только возможно, но не проще.»
С этим тесно связан закон достаточного основания. Любая сложность должна быть весомо аргументирована. Но это уже из области построения систем, как таковых.
А вот с точки зрения рефакторинга — это хорошая, блестящая аргументация, которая бьет все остальное.
я кажется делал так: вводил две метки, одну на строке с командой, чтобы нельзя было ничего вписать между меткой, а вторую ставил вне строки. Т.е.
trb_play
track_pos: ld hl,0
Соответственно, первая метка это имя функции для call/jump, вторая чисто для данных. Да, ее нельзя использовать «где-то там» без контроля, и это плохо, error-prone.
Плохо уже помню, но кажется конструкций вида label equ $+1 в некоторый момент просто не было… Сейчас лучше использовать label equ $+1, еще и потому на других машинах встретится именно это.
Не вполне размышлизмы, с моей стороны это напротив, хардкорная практика, практика, практика.
Сейчас конкретно я сижу перед браузером :) А вообще, бывает, работаю с кодом открывая три и даже четыре окна параллельно рядом друг с другом. Почему окна открываются слева-направо, четырьмя столбцами окон? Почему там код в столбец? Почему они не открываются друг-под-другом? (ну ок, два окна еще можно). И почему я матюгаюсь, скроллируя окошко влево-вправо, когда какой-то деятель нафигачил длинных строк? :)
Всерьез убеждаю тебя освоить редактирование с параллельным открытием нескольких окошек рядом… Дико удобно, да и если кто-нибудь видит, немедленно оценит твою крутизну :))))
Забыл еще написать (но думал об этом), что когда мы увидим дизассемблер, то команды идущие подряд в строке будут развернуты.
А когда кто-то напишет нормальный IDE — как ставить брейкопинты и степать прям по коду?
VBI мне импонирует тем что у него упрощенный и правильный взгляд на мир. Все должно быть устроено просто.
Нет, ну в самом деле, конструкция
ololo
equ $+1
ld hl,0
вызывает кратковременное преткновение ума, необходимо пусть хоть и кратковременно, но все же понять что означает эта метка, вычислить ее значение в уме. Вместо equ $+1 для других команд там должно быть equ $+2 и даже equ $+3, а это уже error-prone.
Это основное.
Такжке для логической аргументации можно упомянуть нарушение принципа verbosity в командах которые используют эту метку.
ld (label+1),reg мне явно показывает что это само-модифицирующийся код, тогда как ld (label),reg такого не показывает, скрывает это от меня.
Вообще, это мой интерес.
Вопрос — как писать, сверху-вниз или слева-направо напрямую относится к психологии восприятия человеком, к работе ума. Тут не все так просто, не только вопрос удобства.
Логическая аргументация такова:
Ход вычислений — сверху вниз. И когда мы располагаем их слева-направо, это осложняет нам восприятие хода вычислений, так как приходится постоянно «переключаться» от сверху-вниз к слева-направо. Это может быть аргументированно там где требуется и общепринято, например при вычислении выражений, но если особой ДОСТАТОЧНОЙ на то необходимости не имеется, лучше этого избегать.
Это «удобно» до той поры, когда ты «в теме», пока тебе заранее известно что происходит в данном фрагменте текста программы. Но как только ты утеряешь это представление, и тебе надлежит РАЗБИРАТЬСЯ (вот в чем разница), подобная запись немного, но осложняет восприятие. Является маленьким препятствием, местом преткновения.
Вплоть до того что я иногда на автомате enter'ом возвращаю сложные строки обратно к представлению в столбец.
Ну и последняя аргументация. Если бежать и создавать к каждой строке комментарии отдельным столбцом, то подобные строки слишком широки и не дают нормально написать комментарии. К тому же, если будет столбец сплошных строк-комментариев, он «маскирует» такую длинную строку.
2. Храни sin в таблице 256 байт, рассчитай заранее.
3. Загрузи старшую половину регистровой пары чтобы получить адрес таблицы, пусть это будет H
4. Тогда L — будет произвольный аргумент функции.
5. Крути L как угодно — будешь ходить по функции туда-сюда.
6. Читай значения sin как LD reg,(HL)
7. cos это то же самое что sin, но сдвинутый на четверть периода. И наоборот. Четверть периода это регистр L +- 64
8. Удобно вместо значений sin/cos сразу прошить таблицу адресами.
9. Значения таблиц sin можно подготовить на старте.
Дебаггером в отладке не простепаешь по statements в строке.
Дебаг-инфа сохраняется в виде адрес->строчка исходного кода.
:)))
(шутка, shinilb0g!)
(Эйнштейн) «Все должно быть изложено так просто, как только возможно, но не проще.»
С этим тесно связан закон достаточного основания. Любая сложность должна быть весомо аргументирована. Но это уже из области построения систем, как таковых.
я кажется делал так: вводил две метки, одну на строке с командой, чтобы нельзя было ничего вписать между меткой, а вторую ставил вне строки. Т.е.
Соответственно, первая метка это имя функции для call/jump, вторая чисто для данных. Да, ее нельзя использовать «где-то там» без контроля, и это плохо, error-prone.
Плохо уже помню, но кажется конструкций вида label equ $+1 в некоторый момент просто не было… Сейчас лучше использовать label equ $+1, еще и потому на других машинах встретится именно это.
Сейчас конкретно я сижу перед браузером :) А вообще, бывает, работаю с кодом открывая три и даже четыре окна параллельно рядом друг с другом. Почему окна открываются слева-направо, четырьмя столбцами окон? Почему там код в столбец? Почему они не открываются друг-под-другом? (ну ок, два окна еще можно). И почему я матюгаюсь, скроллируя окошко влево-вправо, когда какой-то деятель нафигачил длинных строк? :)
Всерьез убеждаю тебя освоить редактирование с параллельным открытием нескольких окошек рядом… Дико удобно, да и если кто-нибудь видит, немедленно оценит твою крутизну :))))
А когда кто-то напишет нормальный IDE — как ставить брейкопинты и степать прям по коду?
Нет, ну в самом деле, конструкция
вызывает кратковременное преткновение ума, необходимо пусть хоть и кратковременно, но все же понять что означает эта метка, вычислить ее значение в уме. Вместо equ $+1 для других команд там должно быть equ $+2 и даже equ $+3, а это уже error-prone.
Это основное.
Такжке для логической аргументации можно упомянуть нарушение принципа verbosity в командах которые используют эту метку.
ld (label+1),reg мне явно показывает что это само-модифицирующийся код, тогда как ld (label),reg такого не показывает, скрывает это от меня.
Вопрос — как писать, сверху-вниз или слева-направо напрямую относится к психологии восприятия человеком, к работе ума. Тут не все так просто, не только вопрос удобства.
Логическая аргументация такова:
Ход вычислений — сверху вниз. И когда мы располагаем их слева-направо, это осложняет нам восприятие хода вычислений, так как приходится постоянно «переключаться» от сверху-вниз к слева-направо. Это может быть аргументированно там где требуется и общепринято, например при вычислении выражений, но если особой ДОСТАТОЧНОЙ на то необходимости не имеется, лучше этого избегать.
Это «удобно» до той поры, когда ты «в теме», пока тебе заранее известно что происходит в данном фрагменте текста программы. Но как только ты утеряешь это представление, и тебе надлежит РАЗБИРАТЬСЯ (вот в чем разница), подобная запись немного, но осложняет восприятие. Является маленьким препятствием, местом преткновения.
Вплоть до того что я иногда на автомате enter'ом возвращаю сложные строки обратно к представлению в столбец.
Ну и последняя аргументация. Если бежать и создавать к каждой строке комментарии отдельным столбцом, то подобные строки слишком широки и не дают нормально написать комментарии. К тому же, если будет столбец сплошных строк-комментариев, он «маскирует» такую длинную строку.
Так что… любой «выверт» имеет свою цену… :)