วีดีโอ

❤❤❤❤

Awesome video, thanks for sharing

Amazing!!!

Highly recommend studying the pattern syntax; the answer to, "Can I get the value of this subfield in a match arm?" is yes, unless you're trying to match on the contents of a Box, in which case the answer is unfortunately no (for now). Also, naturally relocatable code that fully utilizes offsets is wonderful when you don't have a proper linker :P

Something I like doing is to not return an Error result, but rather always return a valid AST node. This could mean returning an error node. This allows me to parse the entire input and check for any errors further down. If I encounter an error, I use a diagnostic emitter to send the error either to a channel (prefer that) or if you wanna go simple just append it to a list. Works like a charm tbh

DEADBEEF < FEEDADAD

❤❤❤❤❤❤❤

Newbie question from someone relatively new to the industry: is it worth it learning vim (with all it entails) if my place of work does not mandate everyone to use the same dev setup? (other than the fact that we all get laptops with Windows installed)

Great video.

Predictive parsers are very nice to work with. My current parser is entirely predictive, and never backtracks. It has its downsides (for example, I had to change struct-initializer expressions so they wouldn't conflict with the condition of an if expression) but if you can make your grammar predictable, your parser will FLY! And, yeah, re-synchronizing the parser after an error is difficult. I think, usually, people advance until the next recognizable bit of syntax (the ending brace, bracket, parenthesis, semicolon, any kind of terminator) and skip the errored code.

Just got a simple program running in a VM im writing in zig. Gotta work on a memory iterator to make program execution smoother. I've decided not to separate registers from general memory, but it's working well so far

First of all, great video. I've started on my own implementation of an LC3-VM in Rust as well. Your repo link in the description is broken. It appears to be truncated.

😅Trying to help explain things from TH-cam comments is quite the rollercoaster, but getting up at 7am my time to catch your streams is, unfortunately, a little too much, I think.

@1:08:15 I think you can simplify that whole mess by using: options.fold(options[0], |a, b| if a.confidence > b.confidence { a } else { b }) The thing you care about is which ConfidenceError has the greater _Confidence_. Which means you care about how the Confidence values compare _not_ how or whether the ConfidenceError objects themselves can compare. (edit) Which you seem to have figured out a little bit later.

@42:59 No, no. It wants you to use the `matches` macro! The warning mentions just below the message: "try: `matches!(self, Self::Pointer(_))`. The matches macro is useful when you _only_ care about whether something is one of the specified enum variants, _not_ what's inside the variant.

@38:18 If you want to go the _full_ functional approach, you could use something like this to replace the whole for-loop (assuming I got all the syntax right): self.items .map(|item| item.run(s.clone())) // run each item lazily .find(Result::is_ok) // find the first successful item .map(|result| result.map(|(s, t)| (s, Some(t)))) // if an item was found, transform the result to the correct form .unwrap_or(Ok((s, None))) // if no item was found, use the fallback

@16:45 You mention previously you wouldn't have been able to parse "*x + 5", which presumably you can after moving expression_deref to expression_lhs. I just wanted to point out, you should probably add a test for that. ;) Also, you may want to add a test for something like "5 * *x", just to make sure your expression parsing doesn't get confused when seeing something weird like that.

1:15:00 Yup! PhantomData is the only type allowed by the compiler to have unused generics. It has special type inference shenanigans going on, iirc. It's necessary when you have a type that *represents* having ownership of some T, but doesn't actually have an instance of T. You can actually be even more explicit about the relationship between your PhantomData-containing type and T: struct HasPhantom<T> { /// I don't have a T, but I consume a T _fn_arg: PhantomData<fn(T)>, /// I don't have a T, but I construct a T _fn_ret: PhantomData<fn() -> T>, /// I contain something that represents a mutable reference to a T, but doesn't borrow-check as one (i.e. a raw pointer *mut T, or ptr::NonNull<T>) _mut_ref: PhantomData<&mut T>, // etc. } The Rust Reference and Rustnomicon have pretty good info on what, when, and where a PhantomData should be. The latter is especially useful if you're writing unsafe code. Usually it has to do with "Subtyping and Variance". In your case, you're using it as shorthand for omitting generics on every member function of that type, which I'd argue is a totally valid use.

Idiomatic read2 would be more like: fn read2(&self, addr: u16) -> Option<u16>{ let x0 = self.read(addr)?; let x1 = self.read(addr+1)?; (x0 as u16) | (x1 as u16 << 8) } The ? operator returns the None or Err type from an option or result and otherwise unwraps the Some or Ok type and continues with the expression. It's syntactic sugar for if let read(addr)=Some(x0){ <do smething> }else{ return None } or x0 = match self.read(addr){ None => return None Some(a) => a } Which is what you want to do anyway. This coincidentally is also why you don't want to return a bool for your write function. For one it's less clear what you mean, an Option<()> or a Result<(),()> shows intention better, but secondly it also gives you the ability to just ? any errors up the chain. Also, I believe an Option<_> is always preferred over a Result<_, ()>, because you're not adding anything with the empty Err type. You're saying: this failed in the only way that is possible, which is precisely what Option<_> does. On the contrary, Option<()> says: this function doesn't return anything when things go well, but it can fail in exactly one way. This is what write should return IMO. Also also, if you later need do need two error types, say for your copy function (ReadError, WriteError), you can do the following: fn copy(&mut self, from: u16, to: u16) -> Result<(),MemErr>{ let x = self.read(from).ok_or(ReadError)?; self.write(to, x).ok_or(WriteError) } Here you cast the Option<T> to a Result<T, Err>, which you then unwrap/return with ?. This type of error handling is IMO a major advantage of rust. For the final write you don't even need to add a ?, because you'll be returning nothing if write returns nothing and the error if it returns an error, so why not just return the result of the ok_or(..) directly :)

youtube won't let me post the link, but the mdn web docs have a short guide on crisp upscaling for pixel art in canvases, you basically set the canvas element's width and height to match the dimensions of the art (in this case, the virtual screen), and then in CSS you set the width/height to some multiple of the element's width/height and set image-rendering: pixelated

what is the color theme you are using?

A pronunciation proposal for 0xff "feety f" 0xF2EA = F thousand Two hundred and Eety A

Someone is watching this right now with me 👋 good stuff huh

Hello there, you are a legend first of all but the link of your git repo is not correct if were to change it for others it would be great, here it is phy1um/rust-simple-vm

hi! what's that environment you use? great video!

The `Extend` trait is a generalization of vec.append(other) that takes any IntoIterator as the other. You can *totally* pass a statically sized array! out.extend( [ Instruction::Pop(SP, BP), Instruction::Pop(SP, PC) ] ); Also, the Rust `core` library isn't allowed to allocate on the heap. Allocation happens in the `alloc` library, which has `core` as a dependency. `std` exports both `core` and `alloc`.

If rust becomes very popular, there will be people who say, "i just like to use C. it's better to prototype with".

RefCell *only* does runtime borrow checking; Rc *only* does reference-counting. Therefore, Rc<RefCell<T>> does reference-counting of a runtime borrow-checked T Regarding impl/dyn Trait: `fn example(t: impl Trait) { ... }` is equivalent to `fn example<T: Trait>(t: T) { ... }` `fn example() -> impl Trait { ... }` creates an opaque return type that the caller is not allowed to introspect (which is great if you can't name the return type) `fn example(t: Box<dyn Trait>) { ... }` and `fn example() -> Box<dyn Trait> { ... }` use a "trait object," which looks up trait methods in a vtable like an object in C++. You can only call trait methods specified in `Trait`'s contract

Got recommended your first video it seems, lots of stuff to binge nice

I also used to had long mane Subbed your channel

What programming language should I start with as a complete beginner who barely remembers how to write hello world in python

34:24 Imm A 4080 (0xffc) :P Gotta love when your expectations are tested for validity 1:44:00 YESSSSSS become one with the RISC. I love me some {pc, sp, sr, cg} action

Oh, yeah. repr(u8) disables niche optimization. That could have very minor performance impacts, and could increase the size of other enums by 1-8 bytes. That's pretty far into the weeds, though.

Collect asks the inferred return type to construct itself from an Iterator via the FromIterator trait :P The standard library, and external libraries, are full of gorgeous little gems like it! ``` Iterator::collect<Collection>(self) -> Collection where Collection: FromIterator<Iterator::Item> ``` Generic return types are one of the reasons I love Rust as much as I do: it requires good type inference. Another amazing trait is `From`, and its magic type-inference cousin `Into` I've been trying to write my own language's type system, and I can't seem to wrap my head around anything more complicated than Algorithm W.

Your accent sounds like vegan-newtown, is that correct?

OPERATOR PRECEDENNNNCCCEEEEEE For future viewers: this is why you run `cargo clippy` Also, `u8 as i8 as u8 as i8` doesn't throw away any information or do any conversion. It's a pure bit reinterpret

50:55 You can put your local function inside the function from_str, and it'll be private to within from_str fn outer () -> i32 { fn inner () -> i32 { 100 } inner() // returns 100 }

You can do almost anything with declarative macros :P (note: this is incomplete, refer to the rust reference for more info) ```rust macro_rules! instructions ( $(#[$attribute:meta])* $vis:vis enum $Name:ident { $( $variant:ident $( ($($t:tt)*) )? = $opcode:literal ),* $(,)? } ) { $(#[$attribute])* $vis enum OpCode { $( $variant = $opcode ),* } impl TryFrom<u16> for OpCode { type Error = String; fn try_from(value: u16) -> Result<Self, Self::Error> { match value & 0xff { $( $opcode => Ok(Opcode::$variant) ),* other => Err(format!("Unrecognized opcode: 0x{other:02x}")), } } } $(#[$attribute])* $vis enum $Name { $( $variant $( ($($t)*) )?),* } ... } ``` Also, the second paragraph of the quote macro docs tells you how to do the thing lmao

Rust requires explicit casts for safety and correctness; coercion of integer widths will lose data (even if that lost data is always 0x00). That said, casting unsigned integers will always truncate or extend in-place.

If you use ddg, you can search "!rust Option" and it'll take you to the rust docs for Option :P

Rust enums are implemented via tagged unions, and the tag is known as the "discriminant". Enum variants are structs + discriminant A "niche" is any bit pattern that is guaranteed to be invalid for a type. An enum whose variants all contain niches can pack into the largest size and largest alignment of its variants, by assigning invalid bit patterns as enum discriminants. References, NonZero<T>, etc. have a single niche, so Option<&T> and Result<&T, ()>/Result<(), &T> are the same size as &T (Option<&T>::None == NULL). *bool* has 254 niches, so you can have one variant which contains a bool and 254 variants which contain nothing, and it should still pack into a byte. In general, enums have the memory overhead of their largest variant + (the discriminant if niche optimization doesn't apply.) The time overhead of enums is the same as a list of constants, and matching on that kind of enum is equivalent to `switch (enum.discriminant) {}`. Moving an enum is proportional to its length. Also you were trying very hard not to put all your definitions in one place match op & 0xff { 0 => Op::Nop, 1 => Op::Push((op >> 8) as usize), _ => ... } Note: the above code will be compiled as a jump table, but the code you wrote may be compiled to an if-else chain.

My Rust is a little rusty! 😂

can I ask what font you use? It looks a lot cleaner than mine.

Great series so far! I experimenting with the vm and I'm pretty sure I found an error where jumping to PC 0 using "Imm PC 0" will cause an Invalid Instruction to be emitted instead of the first instruction of the instruction set. Not sure if it's current causing any issues but the init instructions may be hiding it by occupying the fist slots.

Absolutely loving the coding sessions till now! Learning a lot from you, Keep it up! 💯

sweet video :) really impressive ur not using rust-analyzer! lsp makes writing rust sooo much easier

4:30 Cache invalidation and naming things are the two biggest hurdles in programming

"And I can't spell" - this is why you use a GUI for git... so that you dont have to type, add manually, and spend a lot of time checking diffs.

I love this type of content

Reset b every time your a loop runs. Otherwise b loop only runs once.