>[оверквотинг удален]
>> fn syscall_entry() {
>>  asm volatile amd64 {
>>   swapgs // Save user stack
>> // и усе - более платформ там нема
>>
>> а то на вид это "любое железо, если это amd64"
>>> V работает на любом железе, где есть libc.
>> Ссылку давай со списком __протестированных__ платформ, а то в теории у тебя
>> "и Vinix работают на ___любом___ железе, где есть libc".
> Ты бы хоть удосужился прочитать тот тикет, который ты приводил как "доказательство"

Ты опять срулил с темы Vinix и ссылок c пояснениями не будет? Ну, ожидаемо.

> того, что V не платформонезависим: *** You can always use v
> -o new_file_name.c v_file_name.v to produce a c file that can be
> used with an existing C compiler for your platform. ***
> Перевожу на русский, раз ты не знаешь английского? растоман: компилируй V в
> C и запускай, где угодно, лишь бы там была libc.

Ты бы удосужился прочитать ответ, Воен:
>> It will not help a lot, you also need some .s & .ld files for this platform, eg. stm32
>> But i am most concerned about a lot of mallocs under the hood.
> Ya, it sounds like the freestanding flag would be more what you were looking for. As I said, it did/will remove almost all of the v overhead, no libc linked to by default, and requires the dev to manage memory themselves.

(ага, freestanding, который "уже совсем почти, но еще нет")
> Can you elaborate @MarkuBu ? What are you missing? Custom allocations? They will be allowed.
> The plan is to make V a first class citizen for embedded.
>