Code size

[jj2007]

This is a simple routine to calculate the size of the generated code. This is 32-bit code compiled with GAS - try the same with GCC-32!
See also what changes when you define num1 and num2 as doubles.

Code: Select all

Dim shared globalvar as integer=1000
Dim shared CodeSize as integer

Function foo( num1 as integer, num2 as integer ) as integer
  asm lea edx, $				' start of function
  asm mov [CodeSize], edx
  dim a as integer
  a = globalvar+num1*num2	' do some meaningless calculations
  asm lea edx, $				' end of function
  asm sub edx, [CodeSize]	' subtract start
  asm mov [CodeSize], edx
  return a
end function

Print "The returned number is"; foo(123, 456)
Print "Code size="; CodeSize; " bytes"
sleep

[deltarho[1859]]

Hi jj.

I also looked at gcc using -Wc -O3.

Your post has had 64 views but no response. I wonder if others are struggling as I am in that the knowledge gained by your code has little, if any use, in practice.

I am reminded of the last few lines of the opening to 'The Picture of Dorian Gray' by Oscar Wilde.

We can forgive a man for making a useful thing as long as he does not admire it. The only excuse for making a useless thing is that one admires it intensely.

All art is quite useless.

<smile>

[jj2007]

your code has little, if any use, in practice.

I was curious if there was any difference between these two ways to open a file and get a pointer to its content:

Code: Select all

	Dim as long flen=Lof(f)
	#define version 0
	#if version
		Dim as ubyte ptr pContent = Allocate(Lof(f)), CurPos=pContent, CrPos
		Get #f, 1, *pContent, Lof(f) 
  	#else
		Dim as string content=Input(flen, #f)
		Dim as ubyte ptr pContent = StrPtr(content), CurPos=pContent, CrPos
  	#endif
	Close #f
....
	#if version
		DeAllocate(pContent)
  	#else
		content=""	' release the input string
  	#endif

It turns out the lower one is 6 bytes shorter, and equally fast.

Code: Select all

pContent = @content[0]
pContent = StrPtr(content)

are absolutely equivalent, which is not surprising.

All art is quite useless.
<smile>

Exactly ;-)

FB developers are not as obsessed about code size as the demo scene or assembler programmers in general. I code my libraries with code size in mind but I don't exaggerate. If there are two equivalent ways to perform a task, I pick the shorter one because the longer one may pollute the instruction cache; if, however, the longer one is faster and is part of a significant loop, it will be chosen.

[badidea]

"FB developers are not as obsessed ..."

I would say "Most FB developers don't give a *** about ..."

Data memory size and code speed are often more important, but the (frequently observed) obsession here is often a waste of time as well.

Area's where code size can be important:
* Cache prefetching
* Old hardware or OS
* Embedded uProcessors
* FPGA programming

[Tourist Trap]

Area's where code size can be important:
* Cache prefetching
* Old hardware or OS
* Embedded uProcessors
* FPGA programming

Sometimes programs themselves may become a kind of data like in genetic programming. If you are about to generate a million of variants of a program, even small by nature, you may find it interesting to know that it wont result into oversized stuff.
The other categories mentionned above are also of importance. It simply depends on context then as usual.

[TheRaven]

here's something to think about when considering useless apps assessing code sizes --precursor to file management systems (think like file descriptors written on the fly by stupid stuff like file managers and operating systems)!

And to be fare, the only useless creation is the one that was never sought, but known to be possible, ignored out of consideration for the veiled arrogant fools downsizing other's work cause they are pleased with their efforts.

While file sizes do matter to assembler developers, the real focus & importance is the atomic breakdown of an idea into rational communication (in this case visually represented text in the form of asm syntax) while trying to conceal the algebraic dependencies maintaining the appeal with math haters like me! I like Fasm myself (assembler), but based on past events will not let go of my infatuation with C & BASIC and find the experience with each in addition to Asm meaningful and while size does matter (smaller being better regarding file sizes and benchmarks) speed can be an inaccurate measurement of the real importance behind any project --remember develop, maintenance then optimize --wash, rinse, repeat.