Как стать автором
Обновить

Комментарии 27

Спасибо, очень интересно.

А я правильно понимаю, что в этом режиме Go работает без GC и нельзя использовать ничего, что вызвало бы выделение памяти в куче? Или GC включается в образ ядра как часть среды исполнения? Хотя тогда, конечно, интересно, как он без виртуальной памяти будет работать.
Да, насколько мне известно, понимаете правильно, Garbage Collector отключен, так-же как и весь рантайм, т.е. при такой разработке надо вручную заботится о памяти. Если будет продолжение, то будет описанно и управление памятью в том числе.
А как будет выглядеть попытка выделения в куче в текущем состоянии? Скажем, попытаюсь я какой-то вектор создать, Go выдаст ошибку компиляции?
НЛО прилетело и опубликовало эту надпись здесь
От языка тут одно название.
По большому счету на данный момент Вы правы. Однако не забывайте, на данный момент код работает на той стадии, когда рантайм Go просто не применим, по причине его отсутсвия. Даже если бы разработка велась на C, то на данном этапе и от него были бы лишь только название да немного синтаксиса.
Неплохой таймкиллер по моему мнению, в исследовательских целях применить язык в другом амплуа всегда весело)

P.S. Кто-нибудь расскажет про файл link.ld, а конкретно строчки вида:
code = .; _code = .; __code = .;

Значения различаются только подчеркиванием, в чем смысл?
Честно говоря, link.ld был мной взят с одного из руководств и особо я с ним не разбирался, так что не могу ответть на Ваш вопрос
Если будет 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 нет
В C мы говорим почти так-же, только имена функций должны совпадать.
 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
Не понял, эта связь устанавливается комментарием?
Да. Только в данном случае это не комментарий, а дирректива
Откуда это следует? Потому что он подходит под регулярное выражение?

Жесть какая-то, по-моему.
Вы ужаснетесь, когда столкнетесь с cgo =)
Язык, практически, только появился, а костыляки уже присутствуют. Или это «расширение» gccgo?
Прикольно, так, наверное, не трудно будет и на армовском контроллере завести go.
Да, когда доберусь до юзерспейса планирую сделать порт на arm
Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации