diff --git a/blog/content/edition-1/extra/naked-exceptions/02-better-exception-messages/index.md b/blog/content/edition-1/extra/naked-exceptions/02-better-exception-messages/index.md index 17289421..9f98c962 100644 --- a/blog/content/edition-1/extra/naked-exceptions/02-better-exception-messages/index.md +++ b/blog/content/edition-1/extra/naked-exceptions/02-better-exception-messages/index.md @@ -628,7 +628,7 @@ bitflags! { - When the `PROTECTION_VIOLATION` flag is set, the page fault was caused e.g. by a write to a read-only page. If it's not set, it was caused by accessing a non-present page. - The `CAUSED_BY_WRITE` flag specifies if the fault was caused by a write (if set) or a read (if not set). -- The `USER_MODE` flag is set when the fault occurred in non-priviledged mode. +- The `USER_MODE` flag is set when the fault occurred in non-privileged mode. - The `MALFORMED_TABLE` flag is set when the page table entry has a 1 in a reserved field. - When the `INSTRUCTION_FETCH` flag is set, the page fault occurred while fetching the next instruction. diff --git a/blog/content/edition-1/extra/naked-exceptions/03-returning-from-exceptions/index.md b/blog/content/edition-1/extra/naked-exceptions/03-returning-from-exceptions/index.md index 5ce204a0..b5ad8907 100644 --- a/blog/content/edition-1/extra/naked-exceptions/03-returning-from-exceptions/index.md +++ b/blog/content/edition-1/extra/naked-exceptions/03-returning-from-exceptions/index.md @@ -426,7 +426,7 @@ The page fault is gone and we see the _“It did not crash”_ message again! So the page fault occurred because our exception handler didn't preserve the scratch register `rax`. Our new `handler!` macro fixes this problem by saving all scratch registers (including `rax`) before calling exception handlers. Thus, `rax` still contains the valid memory address when `rust-main` continues execution. ## Multimedia Registers -When we discussed calling conventions above, we assummed that a x86_64 CPU only has the following 16 registers: `rax`, `rbx`, `rcx`, `rdx`, `rsi`, `rdi`, `rsp`, `rbp`, `r8`, `r9`, `r10`, `r11`.`r12`, `r13`, `r14`, and `r15`. These registers are called _general purpose registers_ since each of them can be used for arithmetic and load/store instructions. +When we discussed calling conventions above, we assumed that a x86_64 CPU only has the following 16 registers: `rax`, `rbx`, `rcx`, `rdx`, `rsi`, `rdi`, `rsp`, `rbp`, `r8`, `r9`, `r10`, `r11`.`r12`, `r13`, `r14`, and `r15`. These registers are called _general purpose registers_ since each of them can be used for arithmetic and load/store instructions. However, modern CPUs also have a set of _special purpose registers_, which can be used to improve performance in several use cases. On x86_64, the most important set of special purpose registers are the _multimedia registers_. These registers are larger than the general purpose registers and can be used to speed up audio/video processing or matrix calculations. For example, we could use them to add two 4-dimensional vectors _in a single CPU instruction_: diff --git a/blog/content/edition-1/posts/08-kernel-heap/index.md b/blog/content/edition-1/posts/08-kernel-heap/index.md index 3b3e5dbd..82686151 100644 --- a/blog/content/edition-1/posts/08-kernel-heap/index.md +++ b/blog/content/edition-1/posts/08-kernel-heap/index.md @@ -415,7 +415,7 @@ pub fn init(boot_info: &BootInformation) { We've just moved the code to a new function. However, we've sneaked some improvements in: - An additional `.filter(|s| s.is_allocated())` in the calculation of `kernel_start` and `kernel_end`. This ignores all sections that aren't loaded to memory (such as debug sections). Thus, the kernel end address is no longer artificially increased by such sections. -- We use the `start_address()` and `end_address()` methods of `boot_info` instead of calculating the adresses manually. +- We use the `start_address()` and `end_address()` methods of `boot_info` instead of calculating the addresses manually. - We use the alternate `{:#x}` form when printing kernel/multiboot addresses. Before, we used `0x{:x}`, which leads to the same result. For a complete list of these “alternate” formatting forms, check out the [std::fmt documentation]. [std::fmt documentation]: https://doc.rust-lang.org/nightly/std/fmt/index.html#sign0 diff --git a/blog/content/edition-1/posts/09-handling-exceptions/index.md b/blog/content/edition-1/posts/09-handling-exceptions/index.md index 09685ae4..e3b896ed 100644 --- a/blog/content/edition-1/posts/09-handling-exceptions/index.md +++ b/blog/content/edition-1/posts/09-handling-exceptions/index.md @@ -379,7 +379,7 @@ Note how this solution requires no `unsafe` blocks or `unwrap` calls. > ##### Aside: How does the `lazy_static!` macro work? > -> The macro generates a `static` of type `Once`. The [`Once`][spin::Once] type is provided by the `spin` crate and allows deferred one-time initialization. It is implemented using an [`AtomicUsize`] for synchronization and an [`UnsafeCell`] for storing the (possibly unitialized) value. So this solution also uses `unsafe` behind the scenes, but it is abstracted away in a safe interface. +> The macro generates a `static` of type `Once`. The [`Once`][spin::Once] type is provided by the `spin` crate and allows deferred one-time initialization. It is implemented using an [`AtomicUsize`] for synchronization and an [`UnsafeCell`] for storing the (possibly uninitialized) value. So this solution also uses `unsafe` behind the scenes, but it is abstracted away in a safe interface. [spin::Once]: https://docs.rs/spin/0.4.5/spin/struct.Once.html [`AtomicUsize`]: https://doc.rust-lang.org/nightly/core/sync/atomic/struct.AtomicUsize.html diff --git a/blog/content/edition-2/posts/07-hardware-interrupts/index.fa.md b/blog/content/edition-2/posts/07-hardware-interrupts/index.fa.md index 089c60c0..d3a91b3b 100644 --- a/blog/content/edition-2/posts/07-hardware-interrupts/index.fa.md +++ b/blog/content/edition-2/posts/07-hardware-interrupts/index.fa.md @@ -251,7 +251,7 @@ extern "x86-interrupt" fn timer_interrupt_handler( ### پیکربندی تایمر -تایمر سخت افزاری که ما از آن استفاده می کنیم ، _Progammable Interval Timer_ یا به اختصار PIT نامیده می شود. همانطور که از نام آن مشخص است ، می توان فاصله بین دو وقفه را پیکربندی کرد. ما در اینجا به جزئیات نمی پردازیم زیرا به زودی به [تایمر APIC] سوییچ خواهیم کرد، اما ویکی OSDev مقاله مفصلی درباره [پیکربندی PIT] دارد. +تایمر سخت افزاری که ما از آن استفاده می کنیم ، _Programmable Interval Timer_ یا به اختصار PIT نامیده می شود. همانطور که از نام آن مشخص است ، می توان فاصله بین دو وقفه را پیکربندی کرد. ما در اینجا به جزئیات نمی پردازیم زیرا به زودی به [تایمر APIC] سوییچ خواهیم کرد، اما ویکی OSDev مقاله مفصلی درباره [پیکربندی PIT] دارد. [تایمر APIC]: https://wiki.osdev.org/APIC_timer [پیکربندی PIT]: https://wiki.osdev.org/Programmable_Interval_Timer diff --git a/blog/content/edition-2/posts/07-hardware-interrupts/index.md b/blog/content/edition-2/posts/07-hardware-interrupts/index.md index 5d1267b5..f99cae90 100644 --- a/blog/content/edition-2/posts/07-hardware-interrupts/index.md +++ b/blog/content/edition-2/posts/07-hardware-interrupts/index.md @@ -246,7 +246,7 @@ When we now execute `cargo run` we see dots periodically appearing on the screen ### Configuring the Timer -The hardware timer that we use is called the _Progammable Interval Timer_ or PIT for short. Like the name says, it is possible to configure the interval between two interrupts. We won't go into details here because we will switch to the [APIC timer] soon, but the OSDev wiki has an extensive article about the [configuring the PIT]. +The hardware timer that we use is called the _Programmable Interval Timer_ or PIT for short. Like the name says, it is possible to configure the interval between two interrupts. We won't go into details here because we will switch to the [APIC timer] soon, but the OSDev wiki has an extensive article about the [configuring the PIT]. [APIC timer]: https://wiki.osdev.org/APIC_timer [configuring the PIT]: https://wiki.osdev.org/Programmable_Interval_Timer diff --git a/blog/content/status-update/2019-12-02.md b/blog/content/status-update/2019-12-02.md index b366c0a9..5d7e4fca 100644 --- a/blog/content/status-update/2019-12-02.md +++ b/blog/content/status-update/2019-12-02.md @@ -15,7 +15,7 @@ We also have other news: We plan to add [Experimental Support for Community Tran ## `bootloader` -- [Change the way the kernel entry point is called to honor alignement ABI](https://github.com/rust-osdev/bootloader/pull/81) by [@GuillaumeDIDIER](https://github.com/GuillaumeDIDIER) (published as version 0.8.2) +- [Change the way the kernel entry point is called to honor alignment ABI](https://github.com/rust-osdev/bootloader/pull/81) by [@GuillaumeDIDIER](https://github.com/GuillaumeDIDIER) (published as version 0.8.2) - [Add support for Github Actions](https://github.com/rust-osdev/bootloader/pull/82) - [Remove unnecessary `extern C` on panic handler to fix not-ffi-safe warning](https://github.com/rust-osdev/bootloader/pull/85) by [@cmsd2](https://github.com/cmsd2) (published as version 0.8.3) diff --git a/blog/typos.toml b/blog/typos.toml index 16e52eb3..099243e3 100644 --- a/blog/typos.toml +++ b/blog/typos.toml @@ -1,12 +1,11 @@ [files] extend-exclude = [ "*.svg", - "*.zh-CN.md", - "*.ja.md", ] [default.extend-words] IST = "IST" # Interrupt Stack Table +SEH = "SEH" # structured exception handling [default.extend-identifiers] TheBegining = "TheBegining" # GitHub user mentioned in status reports