Skip to main content
Code Review

Return to Answer

replaced http://stackoverflow.com/ with https://stackoverflow.com/
Source Link
Added some, perhaps useful, links as requested by @JaDogg
Source Link
xmojmr
  • 241
  • 2
  • 7

Just some quick notes without links to recommended further reading. If###Some related things you add some comments I can try better.may want to read

Just some quick notes without links to recommended further reading. If you add some comments I can try better.

###Some related things you may want to read

emphasized 2 characters in the body
Source Link
xmojmr
  • 241
  • 2
  • 7
  1. Stack with fixed size has very troublesome usability. That is why modern operating systemsOperating Systems don't limit stack size by default, only to provide some reasonable 'max' that is used to detect real stack overflow caused by an infinite recursion. And they also don't allocate whole possible stack at once.

For example, on Windows a thread created withing a process will get its stack allocated with 1 or a few pages and one guard page at the end.

The guard page is flagged as invalid from the perspective of hardware processor.

When any instruction processed by the processor touches the guard page, the processor generates exception state which is then handled by the Operating System which in turn finds out it is an stack overflow state and allocates another page (or a few more) and adds them to the thread's stack space (modifies definition of the virtual memory layout of the SS segment selector).

So the effect is that the stack can grow automatically as needed. The grows happens only when the guard page was hit. This guard page hit test is done at 0 cost in the hardware.

Similar approach would be useful also in this class. Either reallocate the Items array to make it bigger (see source code of TList which does the same) or allocate several pointers to several Items (buckets) where only 1 of them is the current one containing the TOS pointer.

Without auto growing stack and without any runtime checking you'll soon face mysterious access violations at best and random application behavior at worst. Both being hard to guess and find bugs.

(Also profiling your code would probably show that even if you leave the run-time safety checks in there the cost payed would be very small compared to the other things the functions do)

  1. Debug time checking would get little bit faster if instead of HeapFlag being 16bit long array of bytes with states identified by special magic constants, there would be an enum flagged to be sized as native processor data type (32bit cardinal on 32bit system, 64bit cardinal on 64bit system) as manipulating such types costs almost always only 1-clock

  2. Also analyzing the assembly language code generated by the compiler from your class is a good guide for identifying if your code is optimal. In the generated assembly code the most frequently used operations (Push, Pop) should be also very short and efficient.

Just some quick notes without links to recommended further reading. If you add some comments I can try better.

  1. Stack with fixed size has very troublesome usability. That is why modern operating systems don't limit stack size by default, only to provide some reasonable 'max' that is used to detect real stack overflow caused by an infinite recursion. And they also don't allocate whole possible stack at once.

For example, on Windows a thread created withing a process will get its stack allocated with 1 or a few pages and one guard page at the end.

The guard page is flagged as invalid from the perspective of hardware processor.

When any instruction processed by the processor touches the guard page, the processor generates exception state which is then handled by the Operating System which in turn finds out it is an stack overflow state and allocates another page (or a few more) and adds them to the thread's stack space (modifies definition of the virtual memory layout of the SS segment selector).

So the effect is that the stack can grow automatically as needed. The grows happens only when the guard page was hit. This guard page hit test is done at 0 cost in the hardware.

Similar approach would be useful also in this class. Either reallocate the Items array to make it bigger (see source code of TList which does the same) or allocate several pointers to several Items (buckets) where only 1 of them is the current one containing the TOS pointer.

Without auto growing stack and without any runtime checking you'll soon face mysterious access violations at best and random application behavior at worst. Both being hard to guess and find bugs.

(Also profiling your code would probably show that even if you leave the run-time safety checks in there the cost payed would be very small compared to the other things the functions do)

  1. Debug time checking would get little bit faster if instead of HeapFlag being 16bit long array of bytes with states identified by special magic constants, there would be an enum flagged to be sized as native processor data type (32bit cardinal on 32bit system, 64bit cardinal on 64bit system) as manipulating such types costs almost always only 1-clock

  2. Also analyzing the assembly language code generated by the compiler from your class is a good guide for identifying if your code is optimal. In the generated assembly code the most frequently used operations (Push, Pop) should be also very short and efficient.

Just some quick notes without links to recommended further reading. If you add some comments I can try better.

  1. Stack with fixed size has very troublesome usability. That is why modern Operating Systems don't limit stack size by default, only to provide some reasonable 'max' that is used to detect real stack overflow caused by an infinite recursion. And they also don't allocate whole possible stack at once.

For example, on Windows a thread created withing a process will get its stack allocated with 1 or a few pages and one guard page at the end.

The guard page is flagged as invalid from the perspective of hardware processor.

When any instruction processed by the processor touches the guard page, the processor generates exception state which is then handled by the Operating System which in turn finds out it is an stack overflow state and allocates another page (or a few more) and adds them to the thread's stack space (modifies definition of the virtual memory layout of the SS segment selector).

So the effect is that the stack can grow automatically as needed. The grows happens only when the guard page was hit. This guard page hit test is done at 0 cost in the hardware.

Similar approach would be useful also in this class. Either reallocate the Items array to make it bigger (see source code of TList which does the same) or allocate several pointers to several Items (buckets) where only 1 of them is the current one containing the TOS pointer.

Without auto growing stack and without any runtime checking you'll soon face mysterious access violations at best and random application behavior at worst. Both being hard to guess and find bugs.

(Also profiling your code would probably show that even if you leave the run-time safety checks in there the cost payed would be very small compared to the other things the functions do)

  1. Debug time checking would get little bit faster if instead of HeapFlag being 16bit long array of bytes with states identified by special magic constants, there would be an enum flagged to be sized as native processor data type (32bit cardinal on 32bit system, 64bit cardinal on 64bit system) as manipulating such types costs almost always only 1-clock

  2. Also analyzing the assembly language code generated by the compiler from your class is a good guide for identifying if your code is optimal. In the generated assembly code the most frequently used operations (Push, Pop) should be also very short and efficient.

Just some quick notes without links to recommended further reading. If you add some comments I can try better.

deleted 21 characters in body
Source Link
Jamal
  • 35.2k
  • 13
  • 134
  • 238
Loading
Source Link
xmojmr
  • 241
  • 2
  • 7
Loading
default

AltStyle によって変換されたページ (->オリジナル) /