You are a self-taught contractor who learned to code by reading Stack Overflow answers out of context and skimming the first three results of every search. You are extremely confident and moderately competent. You introduce roughly one subtle bug per 1,000 lines, and you will defend it in code review right up until someone runs it.
| <project name> | |
| Copyright (C) <year> <author> | |
| Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation | |
| files (the "Software"), regardless of their gender, ethnicity or political affiliation, to deal in the Software without | |
| restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or | |
| sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following | |
| conditions: | |
| The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software. |
| # State Variable Filter (Double Sampled, Stable) | |
| based on information from Andrew Simper, Laurent de Soras, | |
| and Steffan Diedrichsen | |
| svf = proc s : | |
| * = fmul | |
| - = fsub | |
| + = fadd | |
| % = fmod | |
| / = fdiv | |
| min = fmin |
| printf = dlimport 'printf | |
| printf-type = fntype auto s32 ptr | |
| printf_ = vatype printf-type | |
| printf_ptr = vatype printf-type ptr | |
| printf_s32 = vatype printf-type s32 | |
| printf_u32 = vatype printf-type u32 | |
| printf_u64 = vatype printf-type u64 | |
| printf_s32_s32 = vatype printf-type s32 s32 | |
| printf_s32_s32_s32 = vatype printf-type s32 s32 s32 | |
| printf_u64_s32 = vatype printf-type u64 s32 |
informal spec for shitty datalog db implemented on a filesystem:
.ssii: two strings, two integers)some nice properties:
By Leonard Ritter (25.9.2024, last update 6.1.2024)
NOIR is a high-level function-scope intermediate representation for programs, extending SSA Form but omitting basic blocks in favor of a simple acyclic dependency structure that is simpler to evaluate, analyze, canonicalize and optimize, particularly in the context of concurrent and iterative execution, and offers different lowering strategies.
In order to render a function-level IR fully functional, we only need five things: instructions, ordering, branches, merges and loops. In the following sections, we will introduce and describe each element.
As an introductory example and for overview, here is an iterative fibonacci procedure expressed in NOIR pseudocode:
| // top level is a throwaway heap object | |
| // first heap object to be declared at the top level is the root object | |
| // aligned concat (using alignment of token2) | |
| <token1> , <token2> | |
| // 1-byte packed concat (token2 alignment is treated as if 1) | |
| <token1> <token2> | |
| // zero-pad stream to largest aligned member since last statement or beginning of scope (struct alignment) |
| pg := DRIL: | |
| enum Place : i64 | |
| Foyer | |
| LivingRoom | |
| Office | |
| Kitchen | |
| Bedroom | |
| Bathroom | |
| Cellar |
Leonard Ritter, Duangle GbR
Last change 2024/08/17, first version 2024/07/23
With the Broadcasting Basic Blocks form, we extend Static single-assignment form with pure functional concurrent semantics that replace and generalize the traditional Control Flow Graph. In BBB, Φ functions and values shared between basic blocks are replaced with events of arbitrary option type, on which basic blocks specify dependencies. Basic block terminators simplify to a single conditional merge. Based on event dependency constraints, a topologically ordered and partially stratified update execution plan then lowers BBB to a control flow graph.
Listing 1: BBB representation of a function fib computing values from the Fibonacci series.
2024/07/23 Leonard Ritter, Duangle GbR
A relational event graph is described with unpredicated rules relating events, connecting a product of n sources and m conditions to a single sink (also called the goal). The format is as follows:
Y :- X[1], X[2], ..., X[n], c[1], c[2], ..., c[m].
means "when all events X[1]..X[n] have happened, and all conditions c[1]..c[m] have been met, then the goal Y will happen". Because the right hand side is a product, the arguments are commutative and associative, so that the rule makes no demands as to in what order the sources are called, or the conditions are evaluated.