Использование макросов pop и push на classic risc based архитектурах (mips, risc-v, lm32, ppc, etc...) есть плохая практика. Не надо так делать. Потому что код получается более громоздким, и много лишних команд. На каждую операцию будет уходить2 команды. Однако, если надо сохранить/восстановить только один регистр -- то норм. Правильно сохранять регистры в стёк надо, сперва вычесть нужное значение из sp, а потом записать относительно регистра sp. Например, сохранять s1,s2,s3 надо так: addi sp, zero, -12 sw s1, 0(sp) sw s2, 4(sp) sw s3, 8(sp) А восстанавливать так: lw s1, 0(sp) lw s2, 4(sp) lw s3, 8(sp) addi sp, zero, 12
Спасибо за видео. Хочу добавить, что на большинстве архитектур эффективнее работает последовательная запись (или чтение) в память "вперед", а не назад, в основном из-за алгоритмов кэширования. Поэтому в идеале, наверное, все-таки надо сдвигать точки символа влево, а не вправо, и проверять старший бит маски, а не младший, чтобы писать пиксели не задом наперед, а с увеличением адресов.
Вот оно что! Я ещё подумал, что это именно как-то с разрядностью связано. Это было моё первое знакомство с VGA. Теперь ещё одним пробелом в этом вопросе стало меньше. Большое спасибо за эту информацию!
Интересно. Хорошо бы подобное организовать на настоящем железе. Хоть и писал в комментарии к видео о плате что она своих денег не стоит, но кого я обманываю. Все равно куплю ту платку и буду мучить. Поскольку интересно разбираться в чем то новом для себя.
Для аргументов функций есть специальные алиасы регистров а0-а7, почему бы их не использовать, чтоб самых маленьких не путать а приучать к правильному стилю?
Не стоит удивляться странностям, типа двойного чтения при работе с оборудованием. Дело в том, что устройства -- это не память. И операции чтения/записи -- это самостоятельные события, которые могут по особому обрабатываться. Так же это может быть связано с memory barier, если он присутствует и реализован аппаратно. При симуляции, обычно, этого всего нет, и работа с периферией упрощена. А при работе с реальным железом нужно изучать документацию. Там может быть много всяких тонкостей.
Вообще, на большинстве архитектур стёк вниз растёт. И sp нужно ставить на верхнюю границу стёка. Иначе другие обработчики прерываний, либо библиотеки потрут данные. Какой смысл всё делать максимально не стандартно?
И ещё один момент. Сами макросы реализованы неправильно. Так делать нельзя. При сохранении регистра в стёк нужно сначала уменьшить sp, а уже потом туда что то записывать. При восстановлении наоборот. Дело в том, что если произойдёт прерывание -- то данные могут быть испорчены.
У вас есть Личи с hdmi, почему бы с ним не эксперементировать, вместо qemu? Ведь от того, что код под ВМ подстроен и сама ВМ под код подстроена пользы нет. Фантазировать так, можно далеко от реальности уйти. Программа на Личи не будет работать та. Тут бы понять как с uart работать, что за инициализация, что за регистры uart... Ничего ге понятно, но интересно 😊
В самых вложенных подпрограммах, которые не вызывают подпрограмм, сохранять регистр связи в стеке не надо! Теряется весь смысл лине регистра, и заметно замедляется цикл например рисования линии на экране, время исполнения сохранения/восстановления из стека составляют заметную часть от времени исполнения команд изменения пикселя, да еще помноженное на тысячи раз, для каждого пикселя.
Не очень понял про какой формат вы пишите. Формат ролика? Формат подачи информации? Но я всё-таки полагаю, что вы про формат ассемблерного исходника по сравнению с таковым для ARM. Но дело в том, что там и здесь используются разные ассемблеры (компиляторы). И если ARM ещё можно привести к похожему формату RISC-V, так как и там, и там есть GNU C, то обратно никак. Для RISC-V, увы, не написали FASM'а.
@@АнастасияМаничева-з8х А что, с вашей, точки зрения изменилось? Возможно, вам не понравилось, что я в одном ролике пытался вместить больше информации без увеличения его хронометража?
VGA - это видео графический массив (Video Graphical Array), некий стандарт. И этот стандарт теоретически может быть применён к любому устройству. Вот так и здесь, есть некая виртуальная машина к которой "подключили" VGA-адаптер, с которым мы и работаем.
@@CityAceE далеко не факт что сей девайс совместим по регистрам с классическим VGA на PC. Но назвали так для наглядности. Конечно же, правильнее было бы назвать video controller.
Очень интересно и познавательно. Главное - продолжать!
Спасибо за Ваш Труд! Вы многое объясняете верно, нынче мало спикеров в подобном ключе! Спасибо Вам!
Использование макросов pop и push на classic risc based архитектурах (mips, risc-v, lm32, ppc, etc...) есть плохая практика. Не надо так делать. Потому что код получается более громоздким, и много лишних команд. На каждую операцию будет уходить2 команды. Однако, если надо сохранить/восстановить только один регистр -- то норм. Правильно сохранять регистры в стёк надо, сперва вычесть нужное значение из sp, а потом записать относительно регистра sp.
Например, сохранять s1,s2,s3 надо так:
addi sp, zero, -12
sw s1, 0(sp)
sw s2, 4(sp)
sw s3, 8(sp)
А восстанавливать так:
lw s1, 0(sp)
lw s2, 4(sp)
lw s3, 8(sp)
addi sp, zero, 12
Спасибо за видео. Хочу добавить, что на большинстве архитектур эффективнее работает последовательная запись (или чтение) в память "вперед", а не назад, в основном из-за алгоритмов кэширования. Поэтому в идеале, наверное, все-таки надо сдвигать точки символа влево, а не вправо, и проверять старший бит маски, а не младший, чтобы писать пиксели не задом наперед, а с увеличением адресов.
21:10 - изначально у vga цап был 6 бит на канал, 8 бит появилось позже, как расширение.
Вот оно что! Я ещё подумал, что это именно как-то с разрядностью связано. Это было моё первое знакомство с VGA. Теперь ещё одним пробелом в этом вопросе стало меньше. Большое спасибо за эту информацию!
8 бит это уже SVGA
Интересно. Хорошо бы подобное организовать на настоящем железе. Хоть и писал в комментарии к видео о плате что она своих денег не стоит, но кого я обманываю. Все равно куплю ту платку и буду мучить. Поскольку интересно разбираться в чем то новом для себя.
Для аргументов функций есть специальные алиасы регистров а0-а7, почему бы их не использовать, чтоб самых маленьких не путать а приучать к правильному стилю?
Не стоит удивляться странностям, типа двойного чтения при работе с оборудованием. Дело в том, что устройства -- это не память. И операции чтения/записи -- это самостоятельные события, которые могут по особому обрабатываться. Так же это может быть связано с memory barier, если он присутствует и реализован аппаратно. При симуляции, обычно, этого всего нет, и работа с периферией упрощена. А при работе с реальным железом нужно изучать документацию. Там может быть много всяких тонкостей.
Спасибо, здорово! Если можно, хорошо бы как можно меньше двигать листинг, очень сбивает.
Принял к сведению. Постараюсь пореже перемещать листинг.
@@CityAceEСпасибо!
Вообще, на большинстве архитектур стёк вниз растёт. И sp нужно ставить на верхнюю границу стёка. Иначе другие обработчики прерываний, либо библиотеки потрут данные. Какой смысл всё делать максимально не стандартно?
И ещё один момент. Сами макросы реализованы неправильно. Так делать нельзя. При сохранении регистра в стёк нужно сначала уменьшить sp, а уже потом туда что то записывать. При восстановлении наоборот. Дело в том, что если произойдёт прерывание -- то данные могут быть испорчены.
Согласен. А макросы я взял готовые из проекта про Doom.
отлично. А в железе будет что то реализовано?
Я, увы, не железячник...
Тоже думал, что в железе попробовать будет крайне интересно и полезно.
zero где инициализируется или его возможно как то описать, это особенность транслятора?
zero - это псевдоним регистра x0 процессора RISC-V, в котором всегда 0.
У вас есть Личи с hdmi, почему бы с ним не эксперементировать, вместо qemu? Ведь от того, что код под ВМ подстроен и сама ВМ под код подстроена пользы нет. Фантазировать так, можно далеко от реальности уйти. Программа на Личи не будет работать та. Тут бы понять как с uart работать, что за инициализация, что за регистры uart...
Ничего ге понятно, но интересно 😊
Личи есть, да. А графику на нём завести пока не удалось 🤷♂️ Вот и делюсь тем опытом, которым располагаю.
В самых вложенных подпрограммах, которые не вызывают подпрограмм, сохранять регистр связи в стеке не надо! Теряется весь смысл лине регистра, и заметно замедляется цикл например рисования линии на экране, время исполнения сохранения/восстановления из стека составляют заметную часть от времени исполнения команд изменения пикселя, да еще помноженное на тысячи раз, для каждого пикселя.
Можно старый формат, пожалуйста.
Не очень понял про какой формат вы пишите. Формат ролика? Формат подачи информации? Но я всё-таки полагаю, что вы про формат ассемблерного исходника по сравнению с таковым для ARM. Но дело в том, что там и здесь используются разные ассемблеры (компиляторы). И если ARM ещё можно привести к похожему формату RISC-V, так как и там, и там есть GNU C, то обратно никак. Для RISC-V, увы, не написали FASM'а.
@@CityAceE Формат подачи информации
@@АнастасияМаничева-з8х А что, с вашей, точки зрения изменилось? Возможно, вам не понравилось, что я в одном ролике пытался вместить больше информации без увеличения его хронометража?
@@CityAceE Именно, то, что в одном ролике больше информации, без увеличения его хронометража
Я про vga непонял, вроде это стандарт для персональных компьтеров, для гаджетов какието другие графические стандарты
VGA - это видео графический массив (Video Graphical Array), некий стандарт. И этот стандарт теоретически может быть применён к любому устройству. Вот так и здесь, есть некая виртуальная машина к которой "подключили" VGA-адаптер, с которым мы и работаем.
@@CityAceE далеко не факт что сей девайс совместим по регистрам с классическим VGA на PC. Но назвали так для наглядности. Конечно же, правильнее было бы назвать video controller.
@@Alexander_Gurov_RF достаточно совместим, раз тоже умеет modeX