pizlonator

This document explains how I would implement an SSA-based compiler if I was writing one today.

This document is intentionally opinionated. It just tells you how I would do it. This document is intended for anyone who has read about SSA and understands the concept, but is confused about how exactly to put it into practice. If you're that person, then I'm here to show you a way to do it that works well for me. If you're looking for a review of other ways to do it, I recommend this post.

My approach works well when implementing the compiler in any language that easily permits cyclic mutable data structures. I know from experience that it'll work great in C++, C#, or Java. The memory management of this approach is simple (and I'll explain it), so you won't have to stress about use after frees.

I like my approach because it leads to an ergonomic API by minimizing the amount of special cases you have to worry about. Most of the compiler is analyses and transformations ov

kprotty

1. Every atomic object has a timeline (TL) of writes:

   • A write is either a store or a read-modify-write (RMW): it read latest write & pushed new one.
   • A write is either tagged Relaxed, Release, or SeqCst.
   • A read observes some write on the timeline:
     • On the same thread, future reads can't go backwards on the timeline.
     • A read is either tagged Relaxed, Acquire, or SeqCst.
     • RMWs can also be tagged Acquire (or AcqRel). If so, the Acquire refers to the "read" portion of "RMW".

2. Each thread has its own view of the world:

• Shared write timelines but each thread could be reading at different points.

kprotty

const assert = @import("std").debug.assert;

fn compressBlock(writer: anytype, src: []const u8) !void {
    var table = [_]u32{0} ** 4096; // size is pow2. bump to match more. ideal = (0xffff+1) / sizeof(u32)
    var anchor: u32 = 0;
    
    if (src.len > 12) { // LZ4 spec restriction: last match must start 12b before end of block.
        var pos: u32 = 0;
        while (pos + 4 < src.len - 5) { // LZ4 spec restriction: last 5b are always literal.
            const blk: u32 = @bitCast(src[pos..][0..4].*);

ekzhang

rikkimax

Symbol Representation

Field	Value
DIP:
Author:	Richard (Rikki) Andrew Cattermole ([email protected])
Implementation:
Status:	Draft

Abstract

ocornut

Wonder Boy: The Dragon's Trap
-----------------------------

Quick Guide for programmers
Last updated October 2018
Contact: Omar Cornut <XXXXXX

===============================================
 INDEX
===============================================

lleyton

Open Source Business Challenges and Reality

Original Japanese note here.

Original Author: Rui Ueyama (creator of the mold linker)

Translated by @windowsboy111

Minimally edited by @lleyton

JustSlavic

Data oriented UI (part 1)

Some time ago I read the @lisyarus' post about his UI library. In his blog post he compares existing UI frameworks, analyses reasons why they don't work to them, and shows how he created his own library to build in-game UI.

His blog post immediately inspired me: how would I build my UI library?

Data Oriented Design vs OOP?

lithdew

const std = @import("std");

pub fn LexicographicHashMap(comptime V: type, comptime capacity: u32) type {
    const shift = @bitSizeOf(u64) - 1 - std.math.log2_int(u64, capacity) + 1;
    const overflow = capacity / 10 + (@bitSizeOf(u64) - 1 - shift + 1) << 1;
    const num_entries = capacity + overflow;

    return struct {
        pub const Entry = packed struct {
            key: u32 = 0,

lithdew

const std = @import("std");

const sparse = @This();

/// This is an implementation of a paged sparse set that stores the payload in
/// the sparse array.
//
/// A sparse set has a dense and a sparse array. The sparse array is directly
/// indexed by a 64 bit identifier. The sparse element is linked with a dense
/// element, which allows for liveliness checking. The liveliness check itself