0.10.0+dev-00865-g04ebb43f
openocd -f interface/YOUR_INTERFACE_CONFIG -f raspi4.cfg
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. |
See how a minor change to your commit message style can make a difference.
Tip
Have a look at git-conventional-commits , a CLI util to ensure these conventions and generate verion and changelogs
// Capture SIGINT and SIGTERM to perform a clean shutdown | |
net::signal_set signals(ioc, SIGINT, SIGTERM); | |
signals.async_wait( | |
[&](beast::error_code const&, int) | |
{ | |
// Stop the `io_context`. This will cause `run()` | |
// to return immediately, eventually destroying the | |
// `io_context` and all of the sockets in it. | |
ioc.stop(); | |
}); |
class utf8_text_view { | |
const char *text; | |
size_t bytes_count; | |
public: | |
friend class iterator; | |
class iterator { | |
const utf8_text_view &parent; | |
size_t offset; | |
public: |