CR3 is reloaded with the current value when page table entries are removed or when their permission changes, not when switching processes. Not present pages are not cached, so adding a new entry won't require a TLB flush. CR3 is loaded with a different value when switching processes.
16:06 this question is unanswerable. The program invokes undefined behavior. You cannot say with certainty what it will do when executed, because you cannot say with certainty what the compiler will emit when it encounters the bounds violation in the while loop. What UB is, is a set of contracts made by the standard. The programmer is expected to honor these contracts with diligence, and when the programmer violates these contracts, the standard permits a compiler to do anything it wants, whether that's letting the program trigger a segmentation fault, deleting the offending code entirely resulting in wildly unexpected behavior, or going back in time and killing the programmer's parents, retroactively erasing them from existence and creating a time paradox. Also, `(type *) malloc` should be discouraged, as it is poor style; it's a retroactive C++-ism that started to be used because ignorant C++ programmers would attempt to compile ANSI C code under a C++ compiler, fail because the two languages have incompatible type systems, and then force the C code to be compatible instead of doing the sensible thing and using a C compiler. It isn't even correct in C++. void pointers are designed to be implicitly casted in C, the language's weak type system makes a specific exception for casts to and from void pointers, because they are meant to be a generic pointer type. As such, it's not idiomatic C. It's also not idiomatic C++, as if you're allocating from the heap in C++, you should use C++'s `new` and `delete` operators; not `malloc` and `free`, which are libc functions. As a rule of thumb, you should not be using C standard library functions in C++. It's poor style. C++ has its own standard library. It's called STL. To properly allocate from the heap in C: `type *var = malloc(sizeof *var * array_length);` To properly allocate from the heap in C++: `type *var = new type[array_length];` There is no situation where `type *var = (type *)malloc(sizeof *var * array_length);` is considered correct. That said, assuming naively that the compiler ignores the bounds violation and emits code to illegally jump past the end of the array, the code would allocate 1 byte of space, and enter an infinite loop where it attempts to read 1 byte and offset 4 bytes ahead on every iteration. As the program does not own the memory past the first byte, the OS will most likely kill the program with a SIGSEGV soon after it enters the loop.
The Real Mode pretend to be a 80486 or Pentium MMX, the FPU, the operand size prefix and the 64 bit streaming extension are aviable within the real mode. Intel: Instruction prefixes can be used to override the default operand size and address size of a code segment. These prefixes can be used in real-address mode as well as in protected mode and virtual-8086 mode. An operand-size or address-size prefix only changes the size for the duration of the instruction. AMD: When operating in real-address mode, the default addressing and operand size is 16 bits. An address-size override can be used in real-address mode to enable 32-bit addressing; however, the maximum allowable 32-bit linear address is still 000FFFFFH. Feel free to startup all other cores of a multicore CPU within the 16 Bit BIG-Real Mode. www.cs.usfca.edu/~cruse/cs630f08/mphello.s
![F.HERO Ft. JSPKK x ลำไย ไหทองคำ x M-PEE - ไม่สนิทบิดหมด (Thai Riders Anthem) [Official MV]](http://i.ytimg.com/vi/kPJZ0UihBfk/mqdefault.jpg)
CR3 is reloaded with the current value when page table entries are removed or when their permission changes, not when switching processes. Not present pages are not cached, so adding a new entry won't require a TLB flush. CR3 is loaded with a different value when switching processes.
Somehow this was recommended to me after my OS final. Way better than Reiss!
at least there is something interesting on youtube, thank you for this videos!
Where can I get free lectures of 80386 microprocessor?
16:06 this question is unanswerable. The program invokes undefined behavior. You cannot say with certainty what it will do when executed, because you cannot say with certainty what the compiler will emit when it encounters the bounds violation in the while loop. What UB is, is a set of contracts made by the standard. The programmer is expected to honor these contracts with diligence, and when the programmer violates these contracts, the standard permits a compiler to do anything it wants, whether that's letting the program trigger a segmentation fault, deleting the offending code entirely resulting in wildly unexpected behavior, or going back in time and killing the programmer's parents, retroactively erasing them from existence and creating a time paradox.
Also, `(type *) malloc` should be discouraged, as it is poor style; it's a retroactive C++-ism that started to be used because ignorant C++ programmers would attempt to compile ANSI C code under a C++ compiler, fail because the two languages have incompatible type systems, and then force the C code to be compatible instead of doing the sensible thing and using a C compiler. It isn't even correct in C++. void pointers are designed to be implicitly casted in C, the language's weak type system makes a specific exception for casts to and from void pointers, because they are meant to be a generic pointer type. As such, it's not idiomatic C. It's also not idiomatic C++, as if you're allocating from the heap in C++, you should use C++'s `new` and `delete` operators; not `malloc` and `free`, which are libc functions. As a rule of thumb, you should not be using C standard library functions in C++. It's poor style. C++ has its own standard library. It's called STL.
To properly allocate from the heap in C: `type *var = malloc(sizeof *var * array_length);`
To properly allocate from the heap in C++: `type *var = new type[array_length];`
There is no situation where `type *var = (type *)malloc(sizeof *var * array_length);` is considered correct.
That said, assuming naively that the compiler ignores the bounds violation and emits code to illegally jump past the end of the array, the code would allocate 1 byte of space, and enter an infinite loop where it attempts to read 1 byte and offset 4 bytes ahead on every iteration. As the program does not own the memory past the first byte, the OS will most likely kill the program with a SIGSEGV soon after it enters the loop.
i enjoy your videos, very pragmatic. thank you
The Real Mode pretend to be a 80486 or Pentium MMX, the FPU, the operand size prefix and the 64 bit streaming extension are aviable within the real mode.
Intel:
Instruction prefixes can be used to override the default operand size and address size of a code segment. These prefixes can be used in real-address mode as well as in protected mode and virtual-8086 mode. An operand-size or address-size prefix only changes the size for the duration of the instruction.
AMD:
When operating in real-address mode, the default addressing and operand size is 16 bits. An
address-size override can be used in real-address mode to enable 32-bit addressing; however, the
maximum allowable 32-bit linear address is still 000FFFFFH.
Feel free to startup all other cores of a multicore CPU within the 16 Bit BIG-Real Mode.
www.cs.usfca.edu/~cruse/cs630f08/mphello.s