flaviusb

https://duriansoftware.com/joe/type-erased-generic-functions-for-c:-a-modest-non-proposal
https://yosefk.com/blog/i-want-a-struct-linker.html

Build time vs run time
- Macros via staging (at build time)

the struct linker idea can be taken further
fixup directives and fixup locations, to allow for more than just 'add cases to a struct or enum'.
Should be able to use it for 'semi-generic' functions etc as well - like, a kind of semi-monomorphisation when added to some complicated lto / linker scripts
dlopen become difficult though - maybe do something with 'late initialisation' or something, so you can mark sections to be linked and runnable after some stuff has been done, and then instead of dlopen you can use 'add link' and then 'make into executable image, and potentially bring into address space etc', with some kind of 'here is how we fixup symbols for that, and where we throw a condition if trying to jump into an unrealised sub-image'

flaviusb

type ip = u16;

#[derive(Copy,Clone,Eq,PartialEq,Debug)]
pub enum Instruction {
    Nop,
    Jmp { loc: ip },
    Not { length: u8, start: ip, out: ip },
    Copy { length: u8, start: ip, out: ip },
}

flaviusb

#!/bin/bash

export XDG_CACHE_HOME="/data/${USER}/.cache"
export PIP_CACHE_DIR="/data/${USER}/.cache"

flaviusb

array
  q?
     length {...}
     ith get $n {...}
     ith set $n {} {...}
     ith insert $n {} {...}
     ith pop $n {...}
     ith remove $n {...}
     slice get $n $n {...}
     slice set {...} $n {...}

flaviusb

// This version imagines a define_chip macro that has been enhanced with do_with_in; I'm looking at how to do this through providing an annotation macro to wrap other proc macros

define_chip! {
  $(fn stall(name, args: {}, check: []) {
      CheckStall <- 0 (instruction @ super::super::Instruction::$name::(super::super::Instructions::$name($args)), mems) => {
        $(if $check is not empty {
          let ($(for $j in $check { stalled_$j, })) = ($(for $j in $check { get_stalled($j, mems) }));
          if !($(for $k in $check { $k | }) false) {
            return super::super::Work::Computing { progress: 0, instruction, mem: mems };
          } else {

flaviusb

#
# Automatically generated file; DO NOT EDIT.
# Linux/x86 4.14.65-gentoo Kernel Configuration
#

#
# Gentoo Linux
#
CONFIG_GENTOO_LINUX=y
CONFIG_GENTOO_LINUX_UDEV=y

flaviusb

Foreward

This document was originally written several years ago. At the time I was working as an execution core verification engineer at Arm. The following points are coloured heavily by working in and around the execution cores of various processors. Apply a pinch of salt; points contain varying degrees of opinion.

It is still my opinion that RISC-V could be much better designed; though I will also say that if I was building a 32 or 64-bit CPU today I'd likely implement the architecture to benefit from the existing tooling.

Mostly based upon the RISC-V ISA spec v2.0. Some updates have been made for v2.2

Original Foreword: Some Opinion

The RISC-V ISA has pursued minimalism to a fault. There is a large emphasis on minimizing instruction count, normalizing encoding, etc. This pursuit of minimalism has resulted in false orthogonalities (such as reusing the same instruction for branches, calls and returns) and a requirement for superfluous instructions which impacts code density both in terms of size and

flaviusb

More democracy
- Elections (for public offices, yes, but what kinds? Eg I don't really want elected judges or elected bureaucrats)
- Reasonably frequent elections
- Biproportional allotment, as close to PR as possible etc
- Clean elections
- Public funding
- Automatic enrollment
- Auditable results
- Private voting
- No gerrymandering

flaviusb

desc 'Generate tags page'
task :tags do
  puts "Generating tags..."
  require 'rubygems'
  require 'jekyll'
  include Jekyll::Filters
  
  options = Jekyll.configuration({})
  site = Jekyll::Site.new(options)
  site.read_posts('')