Fix grammar and typos

README.md

@@ -17,7 +17,7 @@ cpufetch currently supports x86 CPUs (both Intel and AMD CPUs)
 #### Linux
 There is a cpufetch package available in Arch Linux ([cpufetch-git](https://aur.archlinux.org/packages/cpufetch-git)).
 
-If you are in other distro, you can build `cpufetch` from source (see below)
+If you are in another distro, you can build `cpufetch` from source (see below)
 
 #### Windows
 In the [releases](https://github.com/Dr-Noob/cpufetch/releases) section you will find some cpufetch executables compiled for Windows. Just download and run it from Windows CMD.
@@ -59,7 +59,7 @@ In the case of setting the colors using RGB, 4 colors must be given in with the
 See [cpufetch programming documentation](https://github.com/Dr-Noob/cpufetch/blob/master/doc/README.md).
 
 ### Bugs or improvements
-There are many open issues in github (see [issues](https://github.com/Dr-Noob/cpufetch/issues)). Feel free to open a new one report a issue or propose any improvement in `cpufetch`
+There are many open issues in github (see [issues](https://github.com/Dr-Noob/cpufetch/issues)). Feel free to open a new one report an issue or propose any improvement in `cpufetch`
 
 ### Testers
 I would like to thank [Gonzalocl](https://github.com/Gonzalocl) and [OdnetninI](https://github.com/OdnetninI) for their help, running `cpufetch` in many different CPUs they have access to, which makes it easier to debug and check the correctness of `cpufetch`.

doc/DOCUMENTATION_ARM.md

@@ -6,23 +6,23 @@ __Involved code: [get_midr_from_cpuinfo (udev.c)](https://github.com/Dr-Noob/cpu
 
 Microarchitecture information is acquired from the Main ID Register (MIDR) [[2](#references)]. Currently, cpufetch rebuilds this register using `/proc/cpuinfo` file. While this file does not contain the value of the register per se, it contains the following fields:
 - `CPU implementer`,
-- `CPU archiecture`
+- `CPU architecture`
 - `CPU variant`
 - `CPU part`
 - `CPU revision`
 
 The MIDR register can be built with this information. Another posible approach is to read MIDR directly from `/sys/devices/system/cpu/cpu*/regs/identification/midr_el1`
 
-With the MIDR available, the approach is the same as the one used in x86_64 archiectures. cpufetch has a file which acts like a database that tries to match the MIDR register with the specific CPU microarchitecture.
+With the MIDR available, the approach is the same as the one used in x86_64 architectures. cpufetch has a file that acts like a database that tries to match the MIDR register with the specific CPU microarchitecture.
 
 ### 4. How to get CPU topology?
 __Involved code: [get_ncores_from_cpuinfo (udev.c)](https://github.com/Dr-Noob/cpufetch/blob/master/src/arm/udev.c), [midr.c](https://github.com/Dr-Noob/cpufetch/blob/master/src/arm/midr.c)__
 
-ARM provides a new interesting archiecture feature: big.LITTLE architectures [[4](#references)]. An ARM CPU can be organized like a typycal x86_64 CPU, where all cores share the same microarchitecture. However, ARM big.LITTLE archiecture break this schema. In a big.LITTLE CPU, two or more CPUs microarchitecture live in the same chip.
+ARM provides a new interesting architecture feature: big.LITTLE architectures [[4](#references)]. An ARM CPU can be organized like a typical x86_64 CPU, where all cores share the same microarchitecture. However, ARM big.LITTLE architecture breaks this schema. In a big.LITTLE CPU, two or more CPUs microarchitecture live in the same chip.
 
 This means that cpufetch can't just read which microarchitecture is the first core and assume that the rest of them shares the same microarchitecture. To get the CPU topology, cpufetch first reads the number of CPU cores. This can be obtained from `/sys/devices/system/cpu/present`
 
-Then, for each core, cpufetch reads the MIDR and also the frequency (see section 5). Then, cpufetch assumes that two cores are different when their MIDR are different. This idea allows cpufetch do detect big.LITTLE architectures, and to know how many cores of each archiecture the running CPU has.
+Then, for each core, cpufetch reads the MIDR and also the frequency (see section 5). Then, cpufetch assumes that two cores are different when their MIDR are different. This idea allows cpufetch to detect big.LITTLE architectures, and to know how many cores of each architecture the running CPU has.
 
 ### 5. How to get the frequency?
 Frequency is read directly from `/sys/devices/system/cpu/cpu*/cpufreq/cpuinfo_max_freq`
@@ -32,7 +32,7 @@ __Involved code: [soc.c](https://github.com/Dr-Noob/cpufetch/blob/master/src/arm
 
 System on chip (SoC) model is obtained using the same idea as the microarchitecture. First, SoC string is read. Then, the string has to be matched against a database-like function (__parse_soc_from_string__). The SoC string of the running CPU can be obtained using two different approaches:
 
-- Using `/proc/cpuinfo`. This is the first thing to try. Linux kernel usally provides the string under the `Hardware` keyword. However, it may happend that Linux kernel is unable of providing this information, or it may happen that this string is not found in the database-like function.
+- Using `/proc/cpuinfo`. This is the first thing to try. Linux kernel usually provides the string under the `Hardware` keyword. However, the Linux kernel may be unable to provide this information, or this string may not be found in the database-like function.
 - Using Android properties: This only works on Android systems. Android properties can be read using `__system_property_get` function. cpufetch tries to read two properties:
   - `ro.mediatek.platform`
   - `ro.product.board`
@@ -41,13 +41,13 @@ System on chip (SoC) model is obtained using the same idea as the microarchitect
 
 The expected strings have to be hardcoded. I found two ways of knowing which string should correspond to which SoC:
 
-  - Searching on the internet. Manufacturers __usually__ provide this information. For example, Qualcomm usually publish the chip name along with other characteristics (under the `Part` or `Part number` keyword [[6](#references)]).
+  - Searching on the internet. Manufacturers __usually__ provide this information. For example, Qualcomm usually publishes the chip name along with other characteristics (under the `Part` or `Part number` keyword [[6](#references)]).
   - "Hunting" for the strings. For example, finding smartphones with a given SoC and manually reading the `/proc/cpuinfo` or the `build.prop` file. A very good resource to do this is the SpecDevice webpage [[7](#references)]).
 
 ### 7. How to get cache size and topology?
-ARM archiecture supports reading the cache information via some registers (for example, the CCSIDR register  [[3](#references)]). As mentioned earlier, user level applications are not able to read these registers directly. The remaining option is to ask the operating system for this information. However, at the moment, __Linux kernel does not provide cache information__. Therefore, cpufetch does not print any cache information on ARM CPUs at the moment. There is, however, other approaches to be explored:
+ARM architecture supports reading the cache information via some registers (for example, the CCSIDR register  [[3](#references)]). As mentioned earlier, user level applications are not able to read these registers directly. The remaining option is to ask the operating system for this information. However, at the moment, the __Linux kernel does not provide cache information__. Therefore, cpufetch does not print any cache information on ARM CPUs at the moment. There are, however, other approaches to be explored:
 
-- Read the registers in kernel mode. This can be accomplished by running a kernel module [[4](#references)]. Unfortunately, running a custom kernel module is tricky, and sometimes imposible to do in a reasonable way (for example, in Android devices). In any case, my decision is to run cpufetch on user level only.
+- Read the registers in kernel mode. This can be accomplished by running a kernel module [[4](#references)]. Unfortunately, running a custom kernel module is tricky, and sometimes impossible to do reasonably (for example, in Android devices). In any case, my decision is to run cpufetch on user level only.
 - Hardcode the cache information for each SoC: Sometimes, manufacturers publish technical information about the chips, where cache topology and size are shown. This method is impractical, since this kind of information is very hard (or impossible) to find online, and the number of SoC is huge.
 
 #### References

doc/DOCUMENTATION_X86.md

@@ -1,5 +1,5 @@
 ### 2. Why differences between Intel and AMD?
-There are many different CPUID leaves [[1](#references)]. In some caseses, a given leaf does the same thing in Intel and AMD processors, but the majority of them, they don't. For example, leaf 0x4 gives you the caches information, but in AMD is a reserved (invalid) leaf! In the case of AMD, is more common to fetch information using extended levels than using the standard levels (the other way around with Intel).
+There are many different CPUID leaves [[1](#references)]. In some cases, a given leaf does the same thing in Intel and AMD processors, but in the majority of them, they don't. For example, leaf 0x4 gives you the caches information, but in AMD is a reserved (invalid) leaf! In the case of AMD, is more common to fetch information using extended levels than using the standard levels (the other way around with Intel).
 
 ### 3. How to get the frequency?
 __Involved code: [get_frequency_info (cpuid.c)](https://github.com/Dr-Noob/cpufetch/blob/master/src/x86/cpuid.c)__
@@ -13,8 +13,8 @@ If the CPU does not support supports such level:
 ### 4. How to get cache sizes?
 __Involved code: [get_cache_info (cpuid.c)](https://github.com/Dr-Noob/cpufetch/blob/master/src/x86/cpuid.c)__
 
-- Intel: CPUID leaf 0x4 is used (using __get_cache_info_general__). If CPU does not support it, cpufetch can't get this information.
+- Intel: CPUID leaf 0x4 is used (using __get_cache_info_general__). If the CPU does not support it, cpufetch can't get this information.
-- AMD: Extended CPUID leaf 0x1D is used (using __get_cache_info_general__). If CPU does not support this level, cpufetch uses a fallback method, which uses extended leaves 0x5 and 0x6. This fallback method uses __get_cache_info_amd_fallback__.
+- AMD: Extended CPUID leaf 0x1D is used (using __get_cache_info_general__). If the CPU does not support this level, cpufetch uses a fallback method, which uses extended leaves 0x5 and 0x6. This fallback method uses __get_cache_info_amd_fallback__.
 
 
 ### 5. How to get CPU microarchitecture?
@@ -27,12 +27,12 @@ CPUID leaf 0x1 is used. From there, we get:
 - Extended Family
 - Stepping
 
-Knowing this information, we can distinguish any CPU microarchitecture. Inside __uarch.c__ there is a function that behaves as a database or a lookup table. The function of this database is to find a match between the information obtained from 0x1 and what kind of microarchitecture the current CPU is. I got the data using and adapting the code form Todd Allen's cpuid program [[5](#references)]. Knowing the microarchitecture, we can obtain the manufacturing process (or technology, the size in nm of the transistors).
+Knowing this information, we can distinguish any CPU microarchitecture. Inside __uarch.c__ there is a function that behaves like a database or a lookup table. The function of this database is to find a match between the information obtained from 0x1 and what kind of microarchitecture the current CPU is. I got the data using and adapting the code from Todd Allen's cpuid program [[5](#references)]. Knowing the microarchitecture, we can obtain the manufacturing process (or technology, the size in nm of the transistors).
 
 ### 6. How to get CPU topology?
 __Involved code: [cpuid.h](https://github.com/Dr-Noob/cpufetch/blob/master/src/x86/cpuid.h), [get_topology_info (cpuid.c)](https://github.com/Dr-Noob/cpufetch/blob/master/src/x86/cpuid.c), [apic.c](https://github.com/Dr-Noob/cpufetch/blob/master/src/x86/apic.c)__
 
-cpufetch aims to support the most complex systems, so it supports multi socket CPUs and a detailed SMT (Intel HyperThreading) information. The CPU topology is stored in the following struct:
+cpufetch aims to support the most complex systems, so it supports multi-socket CPUs and detailed SMT (Intel HyperThreading) information. The CPU topology is stored in the following struct:
 
 ```
 struct topology {
@@ -50,7 +50,7 @@ This structure needs a bit of explanation, to know what are we looking for:
 - `logical_cores`: Number of logical cores. In a multi socket system, this field stores the number of logical cores for just one socket.
 - `total_cores`: Total number of logical cores. In a multi socket system, this field stores the number of logical cores for the entire system.
 - `sockets`: How many sockets the system has.
-- `smt_supported`: Stores if SMT (or Intel HT) is supported in the CPU, storing the number of threads per core. So, if `smt_supported == 1`, it means that there is 1 thread per core, and SMT is not supported. If SMT is supported, then `smt_supported >= 1`. Note this field tells if CPU if supports it, but not if SMT is activated or not.
+- `smt_supported`: Stores if SMT (or Intel HT) is supported in the CPU, storing the number of threads per core. So, if `smt_supported == 1`, it means that there is 1 thread per core, and SMT is not supported. If SMT is supported, then `smt_supported >= 1`. Note this field tells if the CPU if supports it, but not if SMT is activated or not.
 - `smt_available`: The same idea as `smt_supported`, but it stores if SMT is available. If SMT is not supported, then `smt_available` is always `1`. The differentiation between supported and available lets cpufetch distinguish when a CPU has SMT capabilities, but are disabled (probably in the BIOS).
 
 Let's give two CPU examples and the values that `struct topology` would have in these CPUs.
@@ -102,11 +102,11 @@ The topology of a cache gives us information about how many caches we have at a
 - L2: If L2 is the last level cache, one L2. If not, the same as the number of cores (one L2 per core).
 - L3: One L3 cache per socket (shared among all cores).
 
-These assumptions are generally (but not always) true. For example, for the AMD Zen generation, or the Intel Xeon Phi KNL. Thus, cpufetch does not assume the topology, but obtains it instead.
+These assumptions are generally (but not always) true. For example, for the AMD Zen generation, or the Intel Xeon Phi KNL. Thus, cpufetch does not assume the topology but obtains it instead.
 
 - __Intel__: The idea is similar to the mentioned in CPU topology [[2](#references)](it also covers how to get cache topology using APIC id).
 
-- __AMD__: Again, we have to look another path for AMD. This time, the way to do it is easier and (I think) more solid and future proof. The idea is to use extended CPUID leaf 0x1D. If the CPU does not support it, we can still guess the topology of the caches (as mentioned earlier). If it does, CPUID can give us how many cores shares a given level of cache. So, if we have the number of cores, we can guess how many caches are there for any given level (see __get_cache_topology_amd__).
+- __AMD__: Again, we have to look for another path for AMD. This time, the way to do it is easier and (I think) more solid and future proof. The idea is to use extended CPUID leaf 0x1D. If the CPU does not support it, we can still guess the topology of the caches (as mentioned earlier). If it does, CPUID can give us how many cores shares a given level of cache. So, if we have the number of cores, we can guess how many caches are there for any given level (see __get_cache_topology_amd__).
 
 #### References
 - [1] [sandpile CPUID webpage](https://www.sandpile.org/x86/cpuid.htm)
@@ -117,4 +117,4 @@ These assumptions are generally (but not always) true. For example, for the AMD
 - [6] [AMD specific CPUID specification](https://www.amd.com/system/files/TechDocs/25481.pdf)
 - [7] [Intel vs AMD CPU Architectural Differences: Chips and Chiplets](https://c.mi.com/thread-2585048-1-0.html)
 
-In addition to all these resources, I found very interesting to search in the Linux kernel source code (for example, the directory [`arch/x86/kernel/cpu/`](https://elixir.bootlin.com/linux/latest/source/arch/x86/kernel/cpu)), because sometetimes you can find ideas that cannot be found anywhere else!
+In addition to all these resources, I found it very interesting to search in the Linux kernel source code (for example, the directory [`arch/x86/kernel/cpu/`](https://elixir.bootlin.com/linux/latest/source/arch/x86/kernel/cpu)), because sometimes you can find ideas that cannot be found anywhere else!

doc/README.md

@@ -1,12 +1,15 @@
 # cpufetch programming documentation (v0.94)
-This documentation explains how cpufetch works internally and all the design decisions I made. The intention of this documentation is to be useful for me in the future, for everyone interested in the project, and for anyone who is trying to obtain any specific information from the CPU. In this way, this can be used as a manual or a page which collects interesting material in this area.
+This documentation explains how cpufetch works internally and all the design decisions I made. This document intends to be useful for me in the future, for everyone interested in the project, and for anyone who is trying to obtain any specific information from the CPU. In this way, this can be used as a manual or a page that collects interesting material in this area.
 
 ### 1. Basics
 cpufetch works for __x86_64__ (Intel and AMD) and  __ARM__ CPUs. However, cpufetch is expected to work better on x86_64, because the codebase is older and has been tested much more than the ARM version. Other kinds of x86_64 CPU are not supported (I don't think supporting other CPUs may pay off). Depending on the architecture, cpufetch choose certain files to be compiled. A summarized tree of the source code of cpufetch is shown below.
 
 ```
 cpufetch/
-├── DOCUMENTATION.md
+├── doc
+│   ├── DOCUMENTATION_ARM.md
+│   ├── DOCUMENTATION_X86.md
+│   └── README.md
 ├── Makefile
 ├── README.md
 └── src/
@@ -22,9 +25,9 @@ cpufetch/
         └── other files ...
 ```
 
-Source code is divided in three directories:
+Source code is divided into three directories:
 
-- `common/`: Source code shared beteen x86 and ARM
+- `common/`: Source code shared between x86 and ARM
 - `arm/`: ARM dependant source code
 - `x86/`: x86_64 dependant source code
 
@@ -44,13 +47,13 @@ struct cpuInfo {
 };
 ```
 
-To use any CPUID leaf, cpufetch always need to check that it is supported in the current CPU.
+To use any CPUID leaf, cpufetch always needs to check that it is supported in the current CPU.
 
 ##### 1.2 Basics (ARM)
-In ARM, __cpufetch works using the MIDR register and Linux filesystem__. MIDR (Main ID Register) is read from `/proc/cpuinfo`. It allows the detection of the microarchitecture of the cores. Furthermore, Linux filesystem `/sys/devices/system/cpu/` is used to fetch the number of cores, and other information. This is the main reason to explain __why `cpufetch` only works on Linux kernel based systems.__
+In ARM, __cpufetch works using the MIDR register and Linux filesystem__. MIDR (Main ID Register) is read from `/proc/cpuinfo`. It allows the detection of the microarchitecture of the cores. Furthermore, Linux filesystem `/sys/devices/system/cpu/` is used to fetch the number of cores and other information. This is the main reason to explain __why `cpufetch` only works on Linux kernel based systems.__
 
 ##### 1.3 Documentation organization
-The rest of the documentation is divided into x86 and ARM architectures, since each one need different implementations:
+The rest of the documentation is divided into x86 and ARM architectures since each one needs different implementations:
 
 - [DOCUMENTATION_X86.md](https://github.com/Dr-Noob/cpufetch/blob/master/doc/DOCUMENTATION_X86.md)
 - [DOCUMENTATION_ARM.md](https://github.com/Dr-Noob/cpufetch/blob/master/doc/DOCUMENTATION_ARM.md)