Комментарии 27
Спасибо, очень интересно.
А я правильно понимаю, что в этом режиме Go работает без GC и нельзя использовать ничего, что вызвало бы выделение памяти в куче? Или GC включается в образ ядра как часть среды исполнения? Хотя тогда, конечно, интересно, как он без виртуальной памяти будет работать.
А я правильно понимаю, что в этом режиме Go работает без GC и нельзя использовать ничего, что вызвало бы выделение памяти в куче? Или GC включается в образ ядра как часть среды исполнения? Хотя тогда, конечно, интересно, как он без виртуальной памяти будет работать.
Да, насколько мне известно, понимаете правильно, Garbage Collector отключен, так-же как и весь рантайм, т.е. при такой разработке надо вручную заботится о памяти. Если будет продолжение, то будет описанно и управление памятью в том числе.
del
НЛО прилетело и опубликовало эту надпись здесь
От языка тут одно название.
Неплохой таймкиллер по моему мнению, в исследовательских целях применить язык в другом амплуа всегда весело)
P.S. Кто-нибудь расскажет про файл link.ld, а конкретно строчки вида:
Значения различаются только подчеркиванием, в чем смысл?
P.S. Кто-нибудь расскажет про файл link.ld, а конкретно строчки вида:
code = .; _code = .; __code = .;
Значения различаются только подчеркиванием, в чем смысл?
Если будет PM, виртуальная память, многозадачность и POSIX, то да. А если нет, то подобных hello world'ов полно, и Go не настолько отличается от C, чтобы повторять.
В начале файлы с исходниками, но кто объяснить что код в них означает?
Весь код на Go вроде бы понятен, даже если б не было комментариев ввиду предельной простоты синстаксиса. Makefile и link.ld — тема не для данной статьи, слишком объемно выйдет. Что касается кода на асме — это немного модифицированный пример из доков multiboot, все изменения указаны. Второй кусок кода на асме описывается под ним.
//Ниже мы создаем обертку для Go над нашей функцией __unsafe_get_addr
//extern __unsafe_get_addr
func getAddr(addr uint32) *[totalMax]uint16
Я так и не понял как связаны __unsafe_get_addr и getAddr. Это манглинг имён такой или как?
У нас есть функция на asm __unsafe_get_addr
В указанном нами коде мы говорим линкеру и компилятору, что когда происходит вызов getAddr нужно вызывать __unsafe_get_addr
В указанном нами коде мы говорим линкеру и компилятору, что когда происходит вызов getAddr нужно вызывать __unsafe_get_addr
Как-то мы неявно это говорим, если getAddr упоминается только в одном месте, и никакой видимой связи с __unsafe_get_addr нет
В C мы говорим почти так-же, только имена функций должны совпадать.
P.S. абстрактный пример в вакуме
extern int __unsafe_get_addr(int);
P.S. абстрактный пример в вакуме
«Почти также», «совпадать». Вот про совпадение имён я и говорю. getAddr сворачивается Go в __unsafe_get_addr, значит.
В указанном нами коде мы говорим линкеру и компилятору, что когда происходит вызов getAddr нужно вызывать __unsafe_get_addr
Если написать в общем виде то
//extern <external_func_name>
func internal_name(...arg) ...res
Приводит к сворачиванию функции internal_name, в функцию external_name. При этом internal_name может быть множество на единственную external_name
Не понял, эта связь устанавливается комментарием?
Прикольно, так, наверное, не трудно будет и на армовском контроллере завести go.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Разработка OS на Go+asm Part 0x00