0.10.0+dev-00865-g04ebb43f
openocd -f interface/YOUR_INTERFACE_CONFIG -f raspi4.cfg
use criterion::{criterion_group, criterion_main, Criterion}; | |
use std::sync::Arc; | |
fn criterion_benchmark(c: &mut Criterion) { | |
c.bench_function("arc", |b| { | |
let arc = Arc::new(String::from("Some string")); | |
b.iter(|| { | |
let clone = Arc::clone(&arc); | |
clone | |
}) |
import SwiftUI | |
import UIKit | |
protocol ASTextFieldDelegate { | |
func didBeginEditing(textField : UITextField) | |
func didEndEditing(textField : UITextField) | |
func didLeftItemtapped(_ button : UIButton) | |
} |
use std::{ | |
borrow::{Borrow, ToOwned}, | |
marker::PhantomData, | |
ops::{Deref, Drop}, | |
ptr::{self, NonNull}, | |
}; | |
pub unsafe trait Cursed<T: ?Sized>: Borrow<T> + Sized { | |
fn borrowed(borowed: &T) -> Option<NonNull<T>>; | |
fn owned(self) -> Option<NonNull<T>>; |
use byteorder::{BigEndian, ByteOrder}; | |
use eeprom24x::{ic, Eeprom24x, SlaveAddr}; | |
use hal::hal::blocking::delay::DelayMs; | |
use hal::hal::blocking::i2c::{Write, WriteRead}; | |
use hash32::{Hasher, Murmur3Hasher}; | |
// EEPROM: 512 pages * 32 bytes = 16,384 bytes | |
// Index size: 32 pages * 8 refs = 256 slots | |
// Max key size: 12 bytes | |
// Max record size: 4095 bytes |
Type | Emoji | code |
---|---|---|
feat | ✨ | :sparkles: |
fix | 🐛 | :bug: |
docs | 📚 | :books: |
style | 💎 | :gem: |
refactor | 🔨 | :hammer: |
perf | 🚀 | :rocket: |
test | 🚨 | :rotating_light: |
build | 📦 | :package: |
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
I've been fiddling about with an idea lately, looking at how higher-kinded types can be represented in such a way that we can reason with them in Rust here and now, without having to wait a couple years for what would be a significant change to the language and compiler.
There have been multiple discussions on introducing higher-ranked polymorphism into Rust, using Haskell-style Higher-Kinded Types (HKTs) or Scala-looking Generalised Associated Types (GATs). The benefit of higher-ranked polymorphism is to allow higher-level, richer abstractions and pattern expression than just the rank-1 polymorphism we have today.
As an example, currently we can express this type:
# RemoteSubl | |
RemoteSubl starts as a fork of [rsub](https://github.com/henrikpersson/rsub) to bring `rmate` feature of TextMate to Sublime Text. It transfers files to be edited from remote server using SSH port forward and transfers the files back when they are saved. | |
Comparing to rsub, the followings are enhanced: | |
- support multiple files via `rmate foo bar`. | |
- use the same view when opening the same file twice. | |
- notify when connection lost. | |
- resume previous connection when it was lost. |