Some function call could be removed by their value

Got an idea for enhancing PureBasic? New command(s) you'd like to see?
Dräc
Enthusiast
Enthusiast
Posts: 150
Joined: Sat Oct 09, 2004 12:10 am
Location: Toulouse (France)
Contact:

Some function call could be removed by their value

Post by Dräc »

I try to express a think shared by several people.
Some function call could be removed by their value.

For example:
RGB(255,0,0) is equivalent in #FF0000

Even if RGB() is a function, given x,y,z (means x,y and z are constants) RGB(x,y,z) is a given value too.

So, a possible optimisation could be removing a function call by its value according to:
- the entries are constants
- the value retrieved by the function is a constant too.
Dräc
PB
PureBasic Expert
PureBasic Expert
Posts: 7581
Joined: Fri Apr 25, 2003 5:24 pm

Re: Some function call could be removed by their value

Post by PB »

I don't know what you mean? But when the compiler sees RGB(255,0,0) in
your source, it's replaced by #FF0000 in the executable; in other words,
putting RGB(255,0,0) in your code is the same as putting a constant in
your code with the value #FF0000.
Dräc
Enthusiast
Enthusiast
Posts: 150
Joined: Sat Oct 09, 2004 12:10 am
Location: Toulouse (France)
Contact:

Post by Dräc »

Sure? :)

Code: Select all

; a = RGB(255,0,0)
	PUSH	 dword 0
	PUSH	 dword 0
	MOV	 eax,255
	CALL	 PB_RGB
	MOV	 dword [v_a],eax
Dräc
Dräc
Enthusiast
Enthusiast
Posts: 150
Joined: Sat Oct 09, 2004 12:10 am
Location: Toulouse (France)
Contact:

Post by Dräc »

correction: RGB(255,0,0) <-> #FF
Dräc
PB
PureBasic Expert
PureBasic Expert
Posts: 7581
Joined: Fri Apr 25, 2003 5:24 pm

Post by PB »

I was going by something Fred once told me about Chr(), that using Chr('a')
would just put 65 in the code directly like a constant, but maybe I didn't
understand him correctly.
User avatar
tinman
PureBasic Expert
PureBasic Expert
Posts: 1102
Joined: Sat Apr 26, 2003 4:56 pm
Location: Level 5 of Robot Hell
Contact:

Post by tinman »

That's if you do something like

Code: Select all

b.s = "Foo"+Chr(65)+"wibble"
Then it will generate the string in the executable rather than have to perform string concatenation.

Similarly,

Code: Select all

b.s = Chr(65)
by itself will create an "A" in your executable so there is no call to a Chr() function and b will take a copy of the string from your exe.
If you paint your butt blue and glue the hole shut you just themed your ass but lost the functionality.
(WinXPhSP3 PB5.20b14)
freak
PureBasic Team
PureBasic Team
Posts: 5940
Joined: Fri Apr 25, 2003 5:21 pm
Location: Germany

Post by freak »

PB:
That is correct, but it only applies to the Chr() function because this is very
frequently used with constant values as input.

Dräc:
Just overwrite the PB function with a macro...

Code: Select all

Macro RGB(r, g, b)
 (((b) << 16) | ((g) << 8) | (r))
EndMacro

; a = RGB(255,0,0)
  MOV    dword [v_a],255
quidquid Latine dictum sit altum videtur
PB
PureBasic Expert
PureBasic Expert
Posts: 7581
Joined: Fri Apr 25, 2003 5:24 pm

Post by PB »

Ah, so I did understand it right, but it's just for Chr(). I thought all commands
would do it, too. So I guess that's what Dräc is wishing for, then?
Dräc
Enthusiast
Enthusiast
Posts: 150
Joined: Sat Oct 09, 2004 12:10 am
Location: Toulouse (France)
Contact:

Post by Dräc »

@PB: right

@freak : of course it is one solution for RGB(). But my naive suggestion is for a systematic approach of the compiler applicable to most functions of the PB standard library…
Dräc
Post Reply