@esoterra any feedback to this thread is welcome (and appreciated) but i don't promise to answer it but if i rework on this, then i will try to address it better. thank you...

this does not disqualify wasm but it is not a design, it is evolution of asm.js. this type of agile/evolutional self-directing model is great for most of the web but for any ABI it is not how you should do it. I could bet money that if things were done from clean slate, we would have something that would not be wasm, even if the end solution would not be riscv. subsetting extensions and layers.

If one can accept that premise, the 2nd premise would be to show that RISC-V "can do it " (even if it sucked). I think this can be made to work.

So 3rd thing to show is that it would be optimal, or more look like "good enough", and objectively better than wasm.

This is roughly how I would start to break up and structure it to a more whitepaperish form....

@esoterra at this point is just a dump with no emphasis to sell it. i just wanted it written down somewhere but i do appreciate your comment because that gives input to refine it possibly in future. frankly, i don't believe this could happen because W3C is too conservative industry body so not a focus point.

i think i already gave some thoughts on some things that you asked but obviously it is my fault (not yours) if it did not get through, i.e. my comms sucks.

so yeah, sorry for dissatisfying answer. i just hate when i loose some idea and mastodon is pretty good to put unconstructive and unfinished ideas :-) I'm sorry for not liking wasm but I stick to that unforutantely without proper study for now,...

I’ve hacked on RISCV for 3,5 months, and some thoughts have developed.

I think that #WebAssembly was a wrong design choice for #web and instead #W3C should have gone with a real micro architecture. #RISCV provides answer for this.

Benefits:

1. Wider than web industry behind it.
2. Made to last decades without breaking backwards compatibility.
3. Ultra-light state transformations (context switches and alike).
4. Well-defined layering and extensions.
5. More open and appealing to open source hackers, moving power away from industry controlled WG’s.
6. Catch up game with many CPU features would stay in sync. E.g. for VM based (i.e. not like SGX which is process based) confidential computing could just map the primitives for the underlying bare-metal CPU architecture.

WebAssembly is in the end really bad implementation of a great idea overally. Forth i interpreter was cool when JVM came out.

Here if W3C and browser vendors dared to take step back, it would result a stable innovation in the web for decades forward.

Transforming RISC-V to WebAssembly is ofc possibly but I don’t see it as an end solution, as all the crappiness of #wasm gets in the way, and e.g. benefit 6 would not even exist.

#notetomyself `curl -sS https://starship.rs/install.sh | sh -s -- -h` (tested on #linux and #macos)

#remindertomyself #git:

git submodule foreach --recursive git reset --hard
git submodule foreach --recursive git clean -f -d -x

I don’t like the policy of #buildroot in that you have to subscribe to the mailing list, in order to be able to send bug fixes. Not possible, when you try to proactively limit the incoming #email flow to the minimum.

Git should probably canocalize patch always before acting on it with realpath(). That would remove such corner cases. https://man7.org/linux/man-pages/man3/realpath.3.html

or more like a corner case:

1. PWD is inside the repository.
2. The relative path starts outside.

a cosmetic #bug in #git:

suppilovahvero in keystone on  jarkkojs/spirs via △ v3.25.1
$ git add ../keystone/patches/linux/linux.vtpm.patch
fatal: ../keystone/patches/linux/linux.vtpm.patch: '../keystone/patches/linux/linux.vtpm.patch' is outside repository at '/home/jarkko/work/nisec/spirs/keystone'

#ctags and/or #cscope are tbh better options for browsing #kernel than #clangd because two former ignore kernel config/build when scanning for new tags. perhaps get_compile_commands.py could be improved a bit. #linux

testing #asciinema and #agg https://github.com/asciinema/agg

#remindertomyself when editing #email with #aerc use CTRL-j and CTRL-k to move between header fields and the message body. I’ve got stuck to the CC list a few times and have sorted it out by killing the whole process, so this is definitely an improvement :-)

The key for finding out how to fix this was man aerc-tutorial. I was cursing for a while because man aerc was not giving me the answers, until I realized that there is another man page!

#notetomyself on #macos:

defaults write -g NSWindowShouldDragOnGesture -bool true 

@cute_stuff right it is a leftover, probably there's some other options that no longer make sense. it used to vimscript, which i rewrote in lua without much thinking involved :-)

and whether it could be a reproducible ofc

i wonder if #linux #kernel could have a make target for #LSP, i.e. just for generating compile_commands.json for everything, like you had local #bootlin #elixir. in the current form i rather use git grep because it is at least more universal, whereas the json file is tied to the current .config.

While people tend to have complex #vim and #neovim configurations I just have this tiny one, less than 100 lines :-) It has served me for years with minor adjustments…

vim.cmd("filetype plugin indent on")
vim.cmd [[packadd packer.nvim]]

local function plugins(use)
  use 'wbthomason/packer.nvim'
  use 'ap/vim-buftabline'
  use {
    'nvim-lualine/lualine.nvim',
    requires = { 'kyazdani42/nvim-web-devicons', opt = true }
  }
  use 'Mofiqul/dracula.nvim'
  use 'mmarchini/bpftrace.vim'
  use 'vim-scripts/git_patch_tags.vim'
  use {
    'nvim-treesitter/nvim-treesitter',
    run = ':TSUpdate'
  }
  use {
    'VonHeikemen/lsp-zero.nvim',
    branch = 'v2.x',
    requires = {
      {'neovim/nvim-lspconfig'},
      {
        'williamboman/mason.nvim',
        run = function()
          pcall(vim.cmd, 'MasonUpdate')
        end,
      },
      {'williamboman/mason-lspconfig.nvim'},
      {'hrsh7th/nvim-cmp'},
      {'hrsh7th/cmp-nvim-lsp'},
      {'L3MON4D3/LuaSnip'},
    }
  }
end

require('packer').startup(plugins)

vim.g.mapleader = ","
vim.opt.autoindent = true
vim.opt.backspace = "indent,eol,start"
vim.opt.backup = false
vim.opt.clipboard = "unnamedplus"
vim.opt.compatible = false
vim.opt.completeopt = "menuone,noinsert,noselect"
vim.opt.hidden = true
vim.opt.history = 2000
vim.opt.hlsearch = true
vim.opt.incsearch = true
vim.opt.listchars="tab:>-,trail:·"
vim.opt.mouse = ""
vim.opt.path:append("**")
vim.opt.ruler = true
vim.opt.shortmess:append("c")
vim.opt.showmatch = true
vim.opt.swapfile = false
vim.opt.tags = "./tags;/"
vim.opt.termguicolors = true
vim.opt.wildmenu = true
vim.opt.wrap = false

if vim.g.neovide then
  vim.o.guifont = "FiraCode Nerd Font Mono:h12"
end

vim.api.nvim_create_autocmd(
  { "FocusGained", "BufEnter" },
  { pattern = "*", command = [[:checktime]],
    group = vim.api.nvim_create_augroup("BufCheck", { clear = true }) }
)

local function nmap(shortcut, command)
  local opts = { noremap = true, silent = true }
  vim.api.nvim_set_keymap('n', shortcut, command, opts)
end

nmap("<silent>", "<C-l> :nohl<CR><C-l>")
nmap("<leader>cd", ":lcd %:p:h<CR>:pwd<CR>")

vim.cmd[[colorscheme dracula]]
require('lualine').setup {
  options = {
    theme = 'dracula-nvim'
  }
}

in-kernel #keystone #driver in-progress (actually it is functioning but I need to separate from research project codebase) https://github.com/keystone-enclave/keystone/pull/328 #linux #kernel #riscv

CoVE won't fly in the upstream as a single company endeavour as it would dominate the whole ecosystem, if it would. This type of collaboration would make the whole thing factors more appealing. Leveraging is often better than replacing IMHO.

Neither is a stable hardware architecture so bottlenecks in that area are not excuse not to engineer things better.