FWIW: I didn't produce the content presented here (the outline from Edmond Lau's book). I've just copy-pasted it from somewhere over the Internet, but I cannot remember what exactly the original source is. I was also not able to find the author's name, so I cannot give him/her the proper credits.
| const { importSchema } = require('graphql-tools') | |
| const { makeExecutableSchema } = require('graphql-tools') | |
| const gql = require('graphql-tag') | |
| const proxy = require('express-http-proxy'); | |
| const app = require('express')() | |
| const http = require('http') | |
| const { graphqlHTTP } = require('express-graphql'); | |
| const typeDefs = gql` |
Alan J. Perlis, Yale University
This text has been published in SIGPLAN Notices Vol. 17, No. 9, September 1982, pages 7 - 13. I'm offering it here online until ACM stops me.
The phenomena surrounding computers are diverse and yield a surprisingly rich base for launching metaphors at individual and group activities. Conversely, classical human endeavors provide an inexhaustible source of metaphor for those of us who are in labor within computation. Such relationships between society and device are not new, but the incredible growth of the computer's influence (both real and implied) lends this symbiotic dependency a vitality like a gangly youth growing out of his clothes within an endless puberty.
The epigrams that follow attempt to capture some of the dimensions of this traffic in imagery that sharpens, focuses, clarifies, enlarges and beclouds our view of this most remarkable of all mans' artifacts, the computer.
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
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
My notes from attempting to read the Dynamo paper ( Dynamo: Amazon's Highly Available Key-value Store)
Buzzwords: Key-Value store, primary key, eventual consistency, CAP theorem, hinted handoff, consistent hashing, virtual nodes.
| //This uses char* pointers. The same thing can be done using character arrays as well. | |
| #include<stdio.h> | |
| #include<stdlib.h> | |
| void mystrcpy(char* first, char* second){ | |
| while(*first != '\0'){ | |
| *second = *first; | |
| first++; | |
| second++; | |
| } |
| *C function* | |
| int fact(int n){ | |
| if (n <= 1) return 1; | |
| return n * fact(n-1); | |
| } | |
| -- | |
| *NASM code* | |
| default rel | |
| global _main | |
| section .data |
The Linux kernel is written in C, so you should have at least a basic understanding of C before diving into kernel work. You don't need expert level C knowledge, since you can always pick some things up underway, but it certainly helps to know the language and to have written some userspace C programs already.
It will also help to be a Linux user. If you have never used Linux before, it's probably a good idea to download a distro and get comfortable with it before you start doing kernel work.
Lastly, knowing git is not actually required, but can really help you (since you can dig through changelogs and search for information you'll need). At a minimum you should probably be able to clone the git repository to a local directory.
