Оказывается, Гугл уже несколько лет развивает собственную процессорную архитектуру, которая называется Lanai. Про неё стало известно пять лет назад, когда Гугл добавил её реализацию в компилятор Clang:
"LLVM Patches Confirm Google Has Its Own In-House Processor"
Подробности архитектуры Гугл не раскрывает, и доступный хардвер не обещает. Чуть больше подробностей можно найти в статье:
"Google crafts custom networking CPU with parallel computing links"
Вроде как 32-битный процессор с 32 регистрами общего назначения. Утверждается, что идея процессора навеяна книгой:
"Parallel Computer Architecture. A Hardware / Software Approach"
В компиляторе Clang имеется поддержка этой архитектуры, если задать флажок --target=lanai. Вот как выглядит язык ассемблера:
"LLVM Patches Confirm Google Has Its Own In-House Processor"
Подробности архитектуры Гугл не раскрывает, и доступный хардвер не обещает. Чуть больше подробностей можно найти в статье:
"Google crafts custom networking CPU with parallel computing links"
Вроде как 32-битный процессор с 32 регистрами общего назначения. Утверждается, что идея процессора навеяна книгой:
"Parallel Computer Architecture. A Hardware / Software Approach"
В компиляторе Clang имеется поддержка этой архитектуры, если задать флажок --target=lanai. Вот как выглядит язык ассемблера:
Но не всё так безнадёжно. На гитхабе я обнаружил исходники симулятора архитектуры Lanai: https://github.com/TrueBitProject/lanai$ cat hello.c
int main()
{
return 0;
}
$ clang --target=lanai -S -O hello.c
$ cat hello.s
.text
.file "hello.c"
.globl main ! -- Begin function main
.p2align 2
.type main,@function
main: ! @main
! %bb.0:
st %fp, [--%sp]
add %sp, 0x8, %fp
sub %sp, 0x8, %sp
or %r0, 0x0, %rv
ld -4[%fp], %pc ! return
add %fp, 0x0, %sp
ld -8[%fp], %fp
.Lfunc_end0:
.size main, .Lfunc_end0-main
! -- End function
.ident "clang version 10.0.0-4ubuntu1 "
.section ".note.GNU-stack","",@progbits
.addrsig

ОЛЯ и ЯЛО
Date: 2021-06-18 05:26 (UTC):)
no subject
Date: 2021-06-18 05:51 (UTC)no subject
Date: 2021-06-18 07:41 (UTC)no subject
Date: 2021-06-18 08:25 (UTC)А тут наоборот.
no subject
Date: 2021-06-18 09:23 (UTC)no subject
Date: 2021-06-18 17:15 (UTC)no subject
Date: 2021-06-18 17:32 (UTC)no subject
Date: 2021-06-18 07:03 (UTC)no subject
Date: 2021-06-18 07:27 (UTC)Совсем непохоже.
К примеру, регистр PC прямо адресуется командой LD.
no subject
Date: 2021-06-18 07:34 (UTC)MOV addr, PC
исполняется быстрее чем
JMP addr
Проверил осциллоскопом. С того момента в моём коде не было джампов. Вот!
no subject
Date: 2021-06-18 08:18 (UTC)В отличие от MOV, JMP не изменяет флаги, и с его помощью можно делать relative branching на расстояние больше 128, чего с помощью MOV to PC не сделаешь.
no subject
Date: 2021-06-18 07:44 (UTC)no subject
Date: 2021-06-18 08:24 (UTC)no subject
Date: 2021-06-18 08:24 (UTC)no subject
Date: 2021-06-18 08:27 (UTC)no subject
Date: 2021-06-18 08:31 (UTC)Крутит какую-нить ThreadX и входные данные в подходящий вид преобразует и рассылает на мактрикс-мультипликаторы.
Не очень понятно почему не RISC-V в 2021-то году.
no subject
Date: 2021-06-18 17:11 (UTC)no subject
Date: 2021-06-18 17:31 (UTC)