Jump to content

  • Log In with Google      Sign In   
  • Create Account


Get unique IDs by reading the Instruction Pointer Register


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
28 replies to this topic

#1 Tispe   Members   -  Reputation: 982

Like
0Likes
Like

Posted 24 February 2013 - 12:31 PM

Hi

 

I am currently writing an IMGUI implementation and I need to create an unique ID for each widget. I thought about using the Instruction Pointer (Program Counter) since it will be the same and be unique everytime I get to the same line of code.

 

But I don't know that much about assembly that I can inline and get it read. I googled this but it does not compile in VS2010:

void *ip = 0;
asm("movl %%eip, %0" : "=r"(ip) );

 

Does it seem like a good idea to generate unique IDs like this? And can someone help me get the asm working?

 

Cheers!


Edited by Tispe, 24 February 2013 - 12:47 PM.


Sponsor:

#2 phantom   Moderators   -  Reputation: 6905

Like
12Likes
Like

Posted 24 February 2013 - 01:02 PM

This... is a horrible idea...

You have 3 'button' widgets; you run the code to get the instruction pointer - what makes you think this will be different for each instance, given they are running the same code...

Just use an int and have someone increment it each time you create a control... if you really think 32bit is too small then you could always use a 64bit int..

#3 Tispe   Members   -  Reputation: 982

Like
0Likes
Like

Posted 24 February 2013 - 01:33 PM

This is IMGUI, the EIP will not be the same for identical widgets because each widget will be called from different parts of the code.

 

DWORD ID = GetEIP();
if(DoButton(ID,Button1,.....))
{
     //code
}

ID=GetEIP();
if(DoButton(ID,Button2.....))
{
     //code
}



#4 EWClay   Members   -  Reputation: 659

Like
0Likes
Like

Posted 24 February 2013 - 01:44 PM

A combination of line number, source file ID and loop index (if you're inside a for loop) would be easier to manage.

I'm sure you will have seen this:

http://sol.gfxile.net/imgui/ch04.html

You can get away with just incrementing (in code), but then you can never change the widget set while one of them is active or the IDs will go out of sync.

#5 Tispe   Members   -  Reputation: 982

Like
0Likes
Like

Posted 24 February 2013 - 02:07 PM

I was hoping that I could macro something that would give me an ID.

 

if(DoButton(GetEIP(),Button1,.....))
{
     //code
}


if(DoButton(GetEIP(),Button2.....))
{
     //code
}

 

This would pass the same unique ID everytime the code goes through that code. I want to avoid hardcoding IDs or even pass the address of a static DummyVariable.


Edited by Tispe, 24 February 2013 - 02:08 PM.


#6 Ryan_001   Prime Members   -  Reputation: 1316

Like
0Likes
Like

Posted 24 February 2013 - 02:28 PM

If you're ok with a non-portable extension VC and GCC provide the __COUNTER__ macro which does just what you're asking for.



#7 Tispe   Members   -  Reputation: 982

Like
0Likes
Like

Posted 24 February 2013 - 02:59 PM

What I have tried now is

#ifdef IMGUI_SRC_ID
#define GEN_ID ((IMGUI_SRC_ID) + (__LINE__))
#else
#define GEN_ID (__LINE__)
#endif

And then in each cpp file I do this in increments of 10000, this will work since I dont have any source files with more then 10000 Lines of code.

#define IMGUI_SRC_ID 50000

 

But.... When I now call

if(DoButton(GEN_ID,.......))
{
      //code
}

The compiler says: cannot convert parameter 1 from 'long' to 'int &'. GEN_ID is defined as long :/

 

 

So I changed to

#ifdef IMGUI_SRC_ID
#define GEN_ID int(((IMGUI_SRC_ID) + (__LINE__)))
#else
#define GEN_ID int((__LINE__))
#endif

and took out the referencing.


Edited by Tispe, 24 February 2013 - 03:04 PM.


#8 wintertime   Members   -  Reputation: 1640

Like
0Likes
Like

Posted 24 February 2013 - 03:57 PM

When I wanted to make such a function for IMGUI I tried to use the __LINE__ makro too, but found out it didnt really work cause if you call some widget from two places it would get the same id again. I also considered mangling the __FILE__ makro but that got same problem and felt too complicated for the little gain. Also just adding to the line number seems to produce less unique numbers.

So I made a custom hash function which started with somehow combining the parentid and the number of needed child ids and then wrote a bunch of unittests to verify uniqueness and that led to a number of additions and bit twiddling tweaks to the function to make it behave as good as possible even on grandchild widgets, bit overflow and wrong inputs. I'm still not convinced its completely done so I'll be looking for more improvedments later.



#9 Ectara   Crossbones+   -  Reputation: 2881

Like
1Likes
Like

Posted 24 February 2013 - 04:16 PM

The compiler says: cannot convert parameter 1 from 'long' to 'int &'. GEN_ID is defined as long :/


Wait, why does the function take a reference to an int? It provides no benefit over passing the int by value, and will likely result in a penalty for the level of indirection. The only reason I can see for someone to do that is if the function modifies the referred to value.

Just making sure the function isn't now modifying a temporary value, thinking it is making a change to the value passed to the function.

#10 darkhaven3   Members   -  Reputation: 160

Like
0Likes
Like

Posted 25 February 2013 - 12:34 AM

I still don't understand why you can't just say int id=random()*random()>>random() or something similar if you absolutely must have a totally random and unique ID every time and do checks to make sure you're not getting identical ids every time, and of course you can map the results of your random id assignment to some meaningful array of structs describing the widget or whatever


Edited by darkhaven3, 25 February 2013 - 12:36 AM.


#11 Tispe   Members   -  Reputation: 982

Like
0Likes
Like

Posted 25 February 2013 - 03:09 AM

Because the IDs must be the same everytime I get to the same line of calling code. And I don't want to keep statics, globals or singletons around to keep track of them.



#12 NightCreature83   Crossbones+   -  Reputation: 2703

Like
1Likes
Like

Posted 25 February 2013 - 03:10 AM

When I wanted to make such a function for IMGUI I tried to use the __LINE__ makro too, but found out it didnt really work cause if you call some widget from two places it would get the same id again. I also considered mangling the __FILE__ makro but that got same problem and felt too complicated for the little gain. Also just adding to the line number seems to produce less unique numbers.
So I made a custom hash function which started with somehow combining the parentid and the number of needed child ids and then wrote a bunch of unittests to verify uniqueness and that led to a number of additions and bit twiddling tweaks to the function to make it behave as good as possible even on grandchild widgets, bit overflow and wrong inputs. I'm still not convinced its completely done so I'll be looking for more improvedments later.

Why not use name your UI elements and hash that particular name into a uint32 or uint64, the only thing you need to remember is to use unique identifiers and generate them as well. This is easier on you as well no need to remember pesky numbers or ids, just use a proper name like button_1, you could extend this with including the parent id like screen_1.button_1 so you can reuse names.
Because you are using the same hash function it will be guaranteed to return the same value for both the ID on the object and the retrieving id.

Edited by NightCreature83, 25 February 2013 - 03:11 AM.

Worked on titles: CMR:DiRT2, DiRT 3, DiRT: Showdown, GRID 2, Mad Max

#13 Tispe   Members   -  Reputation: 982

Like
0Likes
Like

Posted 25 February 2013 - 03:11 AM

In IMGUI the UI elements are not stored anywhere, they are just created when called on, for each frame.



#14 EWClay   Members   -  Reputation: 659

Like
0Likes
Like

Posted 25 February 2013 - 03:12 AM

I still don't understand why you can't just say int id=random()*random()>>random() or something similar if you absolutely must have a totally random and unique ID every time and do checks to make sure you're not getting identical ids every time, and of course you can map the results of your random id assignment to some meaningful array of structs describing the widget or whatever


This is IMGUI. The widget isn't defined until it is called. The ID is the only thing that identifies it from one frame to the next.

#15 Ohforf sake   Members   -  Reputation: 1688

Like
0Likes
Like

Posted 25 February 2013 - 03:25 AM

I also think that using the IP for IDs is a bad idea but just for reference, here is how to get it (untested):

 

call my_label
my_label:
pop %eax   # IP is now in eax register

 

The problem is that in x86 you can't read the IP, like you can for example in ARM. You have to make a function call which will automatically push the return address onto the stack. Then you can pop it back off.

But again: This is probably a bad idea for IDs.



#16 NightCreature83   Crossbones+   -  Reputation: 2703

Like
1Likes
Like

Posted 25 February 2013 - 06:13 AM

You need to use Load effective address instruction instead of a move this is less hassle then jumping to a label and then popping the stack, in masm this looks as following

LEA RAX, [RIP] ;this would load the address of RIP into RAX this only works on a 64-bit CPU
LEA EAX, [EIP] ;32-bit version of the above instructions

 

Still I wouldn't advise you to do it this way as this will be extremely difficult to debug, using a string and a hash function is easier to debug as you can input the string name of the item your interested into the hash function and presto you have your ID.


Worked on titles: CMR:DiRT2, DiRT 3, DiRT: Showdown, GRID 2, Mad Max

#17 swiftcoder   Senior Moderators   -  Reputation: 9762

Like
2Likes
Like

Posted 25 February 2013 - 10:25 AM

I'm really wondering what is insufficient about hashing the combination of __FILE__ and __LINE__. It's worked well enough for my IMGUI needs...
 

#include <iostream>
#include <tr1/unordered_map>
#include <string>

#define _STRINGIFY(X) #X
#define _TOSTRING(X) _STRINGIFY(X)
#define UNIQUE_ID() std::tr1::hash<std::string>()(std::string(__FILE__ ":" _TOSTRING(__LINE__)))

void func() {
	std::cout << UNIQUE_ID() << std::endl;
}

int main() {
	std::cout << UNIQUE_ID() << std::endl;

	for (int i = 0; i < 10; i++)
		func();

	std::cout << UNIQUE_ID() << std::endl;
}

Tristam MacDonald - Software Engineer @Amazon - [swiftcoding]


#18 osmanb   Crossbones+   -  Reputation: 1500

Like
1Likes
Like

Posted 25 February 2013 - 12:08 PM

The thing that fails (with all of the IP/FILE/LINE/etc...) tricks is that it completely prevents the user of the library from saving themselves time, ever. Maybe I find myself making lots of buttons with similar behavior/logic/etc... So I make a helper function to eliminate the boiler-plate parts of the API. Oops, nothing works anymore. It ties an implementation detail of the library to the public interface, in a non-obvious way.



#19 swiftcoder   Senior Moderators   -  Reputation: 9762

Like
0Likes
Like

Posted 25 February 2013 - 12:39 PM

Maybe I find myself making lots of buttons with similar behavior/logic/etc... So I make a helper function to eliminate the boiler-plate parts of the API.

Is that even a reasonable idea in an IMGUI context? How will you deal with the logic introduced by the immediate result values?

My impression is that if you try to do this, you will end up having to build an entire retained-mode wrapper around your IMGUI, and you'd be better off using an RMGUI in the first place.

Tristam MacDonald - Software Engineer @Amazon - [swiftcoding]


#20 Khatharr   Crossbones+   -  Reputation: 2936

Like
-1Likes
Like

Posted 25 February 2013 - 01:36 PM

http://en.wikipedia.org/wiki/KISS_principle
void hurrrrrrrr() {__asm sub [ebp+4],5;}

There are ten kinds of people in this world: those who understand binary and those who don't.




Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS