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:
This command will create a branch with no parent (no commit history) on a repo.
git checkout --orphan <new-branch>
Manage folders linked to others branches of your repo.
Do not confuse them with git submodules which are links to different repositories.