chore: fix some typos (bluealloy#1189)

Signed-off-by: kaifulee <[email protected]>

crates/precompile/src/modexp.rs

@@ -117,7 +117,7 @@ where
 }
 
 fn byzantium_gas_calc(base_len: u64, exp_len: u64, mod_len: u64, exp_highp: &U256) -> u64 {
-    // ouput of this function is bounded by 2^128
+    // output of this function is bounded by 2^128
     fn mul_complexity(x: u64) -> U256 {
         if x <= 64 {
             U256::from(x * x)

crates/primitives/CHANGELOG.md

@@ -200,7 +200,7 @@ One change:
 # v1.1.0
 date: 04.04.2023
 
-Mosty utility functions, addional checks and convenience changes.
+Mosty utility functions, additional checks and convenience changes.
 Old bytecode that supported gas block was replaced with jumpmap only bitvec.
 
 Changelog: 

crates/revm/src/journaled_state.rs

@@ -442,7 +442,7 @@ impl JournaledState {
         self.journal.truncate(checkpoint.journal_i);
     }
 
-    /// Performans selfdestruct action.
+    /// Performances selfdestruct action.
     /// Transfers balance from address to target. Check if target exist/is_cold
     ///
     /// Note: balance will be lost if address and target are the same BUT when

documentation/src/crates/interpreter/memory.md

@@ -2,11 +2,11 @@
 
 Is a memory localized to the current Interpreter context. Interpreter context is a call or create frame. It is used by opcodes to store or format data that are more then 32 bytes long, for example calls to format input, return output or for logs data. Revm has a shared memory between all the Interpreters but Interpreter loop only see the part it is allocated to it.
 
-Extending memory is paid by the gas. It consumes 3 gas per word plus square of the number of words added devided by `512` (`3*N+ N^2/512`). There is no limit on the size of the memory, but it is limited by logaritmic growth of the gas cost. For 30M there is a calculated max memory of 32MB (Blog post by ramco: [Upper bound for transaction memory](https://xn--2-umb.com/22/eth-max-mem/)).
+Extending memory is paid by the gas. It consumes 3 gas per word plus square of the number of words added divided by `512` (`3*N+ N^2/512`). There is no limit on the size of the memory, but it is limited by logaritmic growth of the gas cost. For 30M there is a calculated max memory of 32MB (Blog post by ramco: [Upper bound for transaction memory](https://xn--2-umb.com/22/eth-max-mem/)).
 
 ## Opcodes
 
-Here is a list of all opcodes that are reading or writing to the memory. All read on memory can still change the memory size by extending it with zeroes. Call opcodes are specific as they read input before the call but also write their output after the call (if call is okay and there is a ouput to write) to the memory.
+Here is a list of all opcodes that are reading or writing to the memory. All read on memory can still change the memory size by extending it with zeroes. Call opcodes are specific as they read input before the call but also write their output after the call (if call is okay and there is an output to write) to the memory.
 
 These opcodes read from the memory:
 * RETURN

documentation/src/crates/revm.md

@@ -2,7 +2,7 @@
 
 The `crate` is focused on the implementation of Ethereum Virtual Machine (EVM) including call loop and host implementation, database handling, state journaling and powerful logic handlers that can be overwritten. This crate pulls Primitives, Interpreter and Precompiles together to deliver the rust evm.
 
-Starting point of the documentation should be a [`Evm`](./revm/evm.md) that is main structure of EVM. Then i would recomend reading about the `EvmBuilder` that is used to create the `Evm` and modify. After that you can read about the `Handler` that is used to modify the logic of the Evm and it will tie with how introspection of Evm can be done. And lastly you can read about the `Inspector` that is legacy interface for inspecting execution that is repurposed as one of example of handler registers.
+Starting point of the documentation should be a [`Evm`](./revm/evm.md) that is main structure of EVM. Then i would recommend reading about the `EvmBuilder` that is used to create the `Evm` and modify. After that you can read about the `Handler` that is used to modify the logic of the Evm and it will tie with how introspection of Evm can be done. And lastly you can read about the `Inspector` that is legacy interface for inspecting execution that is repurposed as one of example of handler registers.
 
 Modules:
 - `evm`: This is main module that executed EVM calls.