Some examples related to my tweet rant https://twitter.com/dsymetweets/status/1294276915260522496
In project programming this hit me this week with a bug:
<link rel="shortcut icon" width=32px> | |
<canvas style="display: none" id="loader" width="16" height="16"></canvas> | |
<script> | |
class Loader { | |
constructor(link, canvas) { | |
this.link = link; | |
this.canvas = canvas; | |
this.context = canvas.getContext('2d'); | |
this.context.lineWidth = 2; |
Some examples related to my tweet rant https://twitter.com/dsymetweets/status/1294276915260522496
In project programming this hit me this week with a bug:
#!/bin/bash | |
### | |
### my-script — does one thing well | |
### | |
### Usage: | |
### my-script <input> <output> | |
### | |
### Options: | |
### <input> Input file to read. | |
### <output> Output file to write. Use '-' for stdout. |
// /User/keybindings.json | |
[ | |
{ | |
"key": "shift+alt+t", | |
"command": "editor.action.insertSnippet", | |
"when": "resourceLangId == typescript && editorTextFocus && !editorReadonly", | |
"args": { | |
"langId": "typescript", | |
"name": "Disable TSLint" |
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
console.log(1); | |
(_ => console.log(2))(); | |
eval('console.log(3);'); | |
console.log.call(null, 4); | |
console.log.apply(null, [5]); | |
new Function('console.log(6)')(); | |
Reflect.apply(console.log, null, [7]) | |
Reflect.construct(function(){console.log(8)}, []); | |
Function.prototype.apply.call(console.log, null, [9]); | |
Function.prototype.call.call(console.log, null, 10); |
public static class NumericHelpers | |
{ | |
// Float point maths is whack. We can't check for absolute equality as floating point numbers are imprecise | |
// and are subject to rounding issues (See: http://docs.oracle.com/cd/E19957-01/806-3568/ncg_goldberg.html) | |
// Therefore, we can't check for absolute equality, but instead we have to need to check for values being | |
// "nearly" equal, which allows a small margin of error (i.e. something known as the "Epsilon" value for | |
// the given data type for this CPU that this code is running on). | |
public static bool NearlyEqual(double a, double b, double epsilon) | |
{ | |
var absA = Math.Abs(a); |
FWIW: I (@rondy) am not the creator of the content shared here, which is an excerpt from Edmond Lau's book. I simply copied and pasted it from another location and saved it as a personal note, before it gained popularity on news.ycombinator.com. Unfortunately, I cannot recall the exact origin of the original source, nor was I able to find the author's name, so I am can't provide the appropriate credits.