General Coding Tricks - Revision history

WiRe: /* Need a constant? */

2024-02-15T18:44:18Z

‎Need a constant?

WiRe: /* Need a constant? */

2024-02-15T18:32:34Z

‎Need a constant?

WiRe: /* Need a constant? */

2024-02-13T17:20:38Z

‎Need a constant?

WiRe: /* Need a constant? */

2024-02-13T17:16:53Z

‎Need a constant?

WiRe: /* Need a constant? */

2024-02-13T17:04:05Z

‎Need a constant?

WiRe: /* Need a constant? */

2024-02-13T17:01:28Z

‎Need a constant?

HellMood: added pjc50s explanation

2020-04-29T07:57:00Z

added pjc50s explanation

HellMood: apparently more than a few persons reading what i wrote in a minute, tiny fixes ;)

2020-04-28T14:24:13Z

apparently more than a few persons reading what i wrote in a minute, tiny fixes ;)

Sensenstahl: /* Use the carry flag in your calculations */

2016-12-03T10:55:16Z

‎Use the carry flag in your calculations

Sensenstahl: Added "Use the carry flag in your calculations"

2016-12-03T10:44:48Z

Added "Use the carry flag in your calculations"

@@ Line 34: / Line 34: @@
 If you need more than a byte, then another method could be to create some '''literal pool''' in memory which can be addressed for constants. This technique was first used inside
-[https://www.pouet.net/prod.php?which=94080 TERRA256] (please update if there are earlier examples) and is especially useful if [[Floating-point_Opcodes]] are used, since those can not address byte integer constants in memory but only word and dword. Different to byte constants, it is very unlikely to find word or dword constants inside the opcodes.
+[https://www.pouet.net/prod.php?which=94080 TERRA256] (please update if there are earlier examples) and is especially useful if [[Floating-point_Opcodes]] are used, since those can not address byte integer constants in memory but only word and dword. Different to byte constants, it is less likely to find word or dword constants inside the opcodes where hi- or lo-byte must be zero. Chances are higher if the lower byte of the searched constant word does not matter that much and can be ignored. Else, the literal pool is a very nice technique and simplifies the search for constants a lot.
 The construction of the literal pool can look like this:

@@ Line 34: / Line 34: @@
 If you need more than a byte, then another method could be to create some '''literal pool''' in memory which can be addressed for constants. This technique was first used inside
-[https://www.pouet.net/prod.php?which=94080 TERRA256] (please update if there are earlier examples) and is especially useful if FPU instructions are used, since those can not address byte integer constants in memory but only word and dword. Different to byte constants, it is very unlikely to find word or dword constants inside the opcodes.
+[https://www.pouet.net/prod.php?which=94080 TERRA256] (please update if there are earlier examples) and is especially useful if [[Floating-point_Opcodes]] are used, since those can not address byte integer constants in memory but only word and dword. Different to byte constants, it is very unlikely to find word or dword constants inside the opcodes.
 The construction of the literal pool can look like this:

@@ Line 56: / Line 56: @@
 </syntaxhighlight>
-To address larger values, some tricks can be used to keep size low:
+To address larger values, some further tricks can be used to keep size low:
 <syntaxhighlight lang=nasm>
          fild word [bx+0x087*2]  ;take care that this instruction is 1 byte larger than the others

@@ Line 44: / Line 44: @@
          push cx ;optionally push final zero constant, if required
 </syntaxhighlight>
-This example will construct a literal pool of 256 words on the stack, starting with 0x00FF and ending with 0x0000. The additional "push cx" after the loop is used to add a final zero constant, if required. The final zero also allows to exit from a COM executable using the "ret" instruction.
+This example will construct a literal pool of 256 words on the stack, starting with 0x00FF and ending with 0x0000. The additional "push cx" after the loop will add a final zero constant, if required. The final zero also allows to exit from a COM executable using the "ret" instruction.
 Practically almost any existing initialization loop can be used to setup such a pool, why this construction in the best case only costs a single additional byte for the "push cx" instruction.

@@ Line 61: / Line 61: @@
          fild word [bx+si+0x087*2-0x100] ;but this trick could help: load integer value 0x0087 into FPU register, assuming SI is 0x0100
          fild word [bx+0x03*2-1] ;load integer value 0x0300 into FPU register
 </syntaxhighlight>

← Older revision		Revision as of 17:01, 13 February 2024
Line 32:		Line 32:

	If you need a constant value but you're out of space, search your assembled code for a byte value you can use.		If you need a constant value but you're out of space, search your assembled code for a byte value you can use.
		+
		+	If you need more than a byte, then another method could be to create some '''literal pool''' in memory which can be addressed for constants. This technique was first used inside
		+	[https://www.pouet.net/prod.php?which=94080 TERRA256] (please update if there are earlier examples) and is especially useful if FPU instructions are used, since those can not address byte integer constants in memory but only word and dword. Different to byte constants, it is very unlikely to find word or dword constants inside the opcodes.
		+
		+	The construction of the literal pool can look like this:
		+	<syntaxhighlight lang=nasm>
		+	mov cx, 255 ;very likely this can be replaced by a shorter version or even skipped; value of CX can also be larger than 255
		+	initlp: ;very likely there are other things to initialize, like i.e. setting the DAC color palette
		+	push cx ;push 16-bit word to the stack with the current counter value
		+	loop initlp
		+	push cx ;optionally push final zero constant, if required
		+	</syntaxhighlight>
		+	This example will construct a literal pool of 256 words on the stack, starting with 0x00FF and ending with 0x0000. The additional "push cx" after the loop is used to add a final zero constant, if required. The final zero also allows to exit from a COM executable using the "ret" instruction.
		+
		+	Practically almost any existing initialization loop can be used to setup such a pool, why this construction in the best case only costs a single additional byte for the "push cx" instruction.
		+
		+	To use the literal pool, some index register like SI, DI, BX or BP should be initialized to point to the literal pool. The init value can be the content of the stack pointer (SP) but also a fixed offset, since the position of the literal pool and the current stack position is typically well known. Also the initial value of DI (0xFFFE) or a zero offset may work. Accessing the literal pool can look like this:
		+
		+	<syntaxhighlight lang=nasm>
		+	mov bx, sp ;point index register to literal pool
		+	fild word [bx+0x13*2] ;load integer value 0x0013 into FPU register
		+	fild word [bx+0x31*2] ;load integer value 0x0031 into FPU register
		+	</syntaxhighlight>
		+
		+	To address larger values, some tricks can be used to keep size low:
		+	<syntaxhighlight lang=nasm>
		+	fild word [bx+0x087*2] ;take care that this instruction is 1 byte larger than the others
		+	fild word [bx+si+0x087*2-0x100] ;but this trick could help: load integer value 0x0087 into FPU register, assuming SI is 0x0100
		+	fild word [bx+0x03*2-1] ;load integer value 0x0300 into FPU register
		+	</syntaxhighlight>

	== A smaller way to point to Mode 13's screen segment ==		== A smaller way to point to Mode 13's screen segment ==

← Older revision		Revision as of 07:57, 29 April 2020
Line 78:		Line 78:

	This is adapted from [http://www.pouet.net/prod.php?which=53816 "Puls" by Rrrola] where X and Y are directly modified on the stack by performing <code>add dword[di],0000CCCDh</code> on each pixel iteration, which requires 7 bytes of code. The vertical alignment correction is solved with a good starting value on said DWORD on the stack before each frame, which requires 2 additional bytes. Both approaches are too different to directly compare, but share the core idea of [http://www.pouet.net/topic.php?which=8791&page=8#c411796 multiplying with <code>0xCCCD</code>], so "Rrrolas trick" is an appropriate term to use.		This is adapted from [http://www.pouet.net/prod.php?which=53816 "Puls" by Rrrola] where X and Y are directly modified on the stack by performing <code>add dword[di],0000CCCDh</code> on each pixel iteration, which requires 7 bytes of code. The vertical alignment correction is solved with a good starting value on said DWORD on the stack before each frame, which requires 2 additional bytes. Both approaches are too different to directly compare, but share the core idea of [http://www.pouet.net/topic.php?which=8791&page=8#c411796 multiplying with <code>0xCCCD</code>], so "Rrrolas trick" is an appropriate term to use.
		+
		+	=== Alternative explanation by [https://news.ycombinator.com/user?id=pjc50 pjc50]===
		+	[https://gistpreview.github.io/?9b252f267cd1fdf9754059bb73a18487 Interactive snippet]
		+	More clearly: DI = (y * 320) + x
		+
		+	Multiply by 0xCCCD => (y * 0x1000040) + (x * 0xcccd)
		+
		+	Take top byte is equivalent to divide by 0x1000000. So that gives you Y.
		+	The next lower (third) byte is then (x * 0xcccd / 0x10000) == (x * 52429 / 65536) =~ (x * 256/320).
		+	And the lower two bytes are noise.

	== Use the entire register for a smaller opcode form ==		== Use the entire register for a smaller opcode form ==

@@ Line 75: / Line 75: @@
 == Obtaining X and Y without DIV (The Rrrola Trick) ==
-In [[Output#Outputting_in_mode_13h_.28320x200.29|320x200 mode]], instead of constructing X and Y from the screen pointer DI with DIV, you can get a decent estimation with multiplying the screen pointer with 0xCCCD and read X and Y from the 8bit registers DH (+DL as 16bit value) and DL (+AH as 16bit value). The idea is to interpret DI as a kind of 16 bit float in the range [0,1], from start to end. Multiplying this number in [0,1] with 65536 / 320 = 204,8 results in the row before the comma, and again as a kind of a float, the column after the comma. The representation 0xCCCD is the nearest rounding of 204,8 * 256 ( = 52428,8 ~ 52429 = 0xCCCD). As long as the 16 bit representations are used, there is no precision loss.
+In [[Output#Outputting_in_mode_13h_.28320x200.29|320x200 mode]], instead of constructing X and Y from the screen pointer DI with DIV, you can get a decent estimation with multiplying the screen pointer with 0xCCCD and read X and Y from the 8bit registers DH (+DL as 16bit value) and DL (+AH as 16bit value). The idea is to interpret DI as a kind of 16 bit fixed point in the range [0,1], from start to end. Multiplying this number in [0,1] with 65536 / 320 = 204,8 results in the row before the comma, and again as a kind of a fixed point, the column after the comma. The representation 0xCCCD is the nearest rounding of 204,8 * 256 ( = 52428,8 ~ 52429 = 0xCCCD). As long as the 16 bit representations are used, there is no precision loss.
 This is adapted from [http://www.pouet.net/prod.php?which=53816 "Puls" by Rrrola] where X and Y are directly modified on the stack by performing <code>add dword[di],0000CCCDh</code> on each pixel iteration, which requires 7 bytes of code. The vertical alignment correction is solved with a good starting value on said DWORD on the stack before each frame, which requires 2 additional bytes. Both approaches are too different to directly compare, but share the core idea of [http://www.pouet.net/topic.php?which=8791&page=8#c411796 multiplying with <code>0xCCCD</code>], so "Rrrolas trick" is an appropriate term to use.

← Older revision		Revision as of 10:55, 3 December 2016
Line 85:		Line 85:
	== Use the carry flag in your calculations ==		== Use the carry flag in your calculations ==

−	Let's say you have to <code>add si,128</code>. Unfortunately this takes 1 Byte more than <code>add si,127</code>. But you can add 128 without that extra Byte. If your previous code sets the carry flag simply include it into your calculation and <code>adc si,127</code>.	+	Let's say you have to <code>add si,128</code>. Unfortunately this takes 1 Byte more than <code>add si,127</code>. But you can add 128 without that extra Byte. If your previous code sets the carry flag simply include it into your calculation and <code>adc si,127</code>. The same goes for <code>sub si,128</code> vs <code>sbb si,127</code>.

← Older revision		Revision as of 10:44, 3 December 2016
Line 82:		Line 82:

	As you know e.g. <code>add cl,1</code> produces 3 Bytes of code while <code>inc cl</code> compiles to 2 Bytes. If ch does not matter (or you know that it won't be affected) use <code>inc cx</code> instead and get the most out of that 1 Byte. This is no real trick but sometimes such things can be overlooked - while the 2 saved Bytes could be invested wisely.		As you know e.g. <code>add cl,1</code> produces 3 Bytes of code while <code>inc cl</code> compiles to 2 Bytes. If ch does not matter (or you know that it won't be affected) use <code>inc cx</code> instead and get the most out of that 1 Byte. This is no real trick but sometimes such things can be overlooked - while the 2 saved Bytes could be invested wisely.
		+
		+	== Use the carry flag in your calculations ==
		+
		+	Let's say you have to <code>add si,128</code>. Unfortunately this takes 1 Byte more than <code>add si,127</code>. But you can add 128 without that extra Byte. If your previous code sets the carry flag simply include it into your calculation and <code>adc si,127</code>.