#include<iostream>

using namespace std;

int main(){

	int a;
	int b;
	
	asm("jmp c\n\t");
	
	a=7;
	b=12;
	
	asm("d:\n\t");
	
	cout<< a<< endl<< b<< endl;
	
	return 0;
	
}

int pewp(){

	int a;
	int b;
	
	asm("c:\n\t");
	
	a = 3;
	b = 2;
	
	asm("jmp d\n\t");
	
}

this will output

3
2

what I don't get is why although it jumps to the middle of the pewp() functions, it still sets the variables properly...
does this mean that, when the rest of the code gets compiled, the a= and b= in pewp() get sent to the same spot in memory that the a= and b= in main() would have? If I name the variables in pewp() c and d it still sets a and b in main(), so are these variables put on the stack or what? I guess I have lots to learn about what happens to the data in different declarations -.-

Dani AI

Generated

Short answer: the code “works” only by accident. As suggested, the stores you see executed from inside pewp() end up targeting memory that, when executed in that particular build and on that platform, corresponds to main()’s automatic storage. That outcome is not guaranteed by the language and is undefined behavior.

How it happens: compilers generate code that accesses locals at fixed offsets (or in registers) according to the calling convention and the generated frame layout. Jumping into another function bypasses normal prologue/epilogue and any object construction, so the assembly that performs a = 3 and b = 2 runs with whatever stack/register state the program has at that moment. With simple int locals and that specific compiler/config, the addresses line up; with different types, optimization levels, or a different compiler/ABI the writes will go elsewhere or crash. For the C++ rules on object lifetime and the broader concept of undefined behavior see C++ undefined behavior and object lifetime.

A few practical notes: modern toolchains differ — GCC’s inline-asm and syntax differ from MSVC’s, and MSVC x64 does not support inline asm the same way (which explains ’s compiler trouble). See GCC extended asm and Microsoft’s inline assembler docs for details. Optimized builds often keep locals in registers or eliminate them entirely, so the behavior will change with -O levels.

If the goal is learning, inspect the generated assembly (gcc -S / objdump) and do experiments that don’t rely on jumping into another function (write a single asm function or use well-formed function calls). This preserves predictable behavior and avoids subtle, dangerous bugs.

Recommended Answers

All 5 Replies

Yes, a and b in both main() and pewp() are declared on the stack in the same way. As you have identical declarations (just a and b) for each function you can jump into pewp() and it uses the stack allocated by main(). This may be an interesting exercise, but I hope you don't need me to tell you that doing anything close to this in software you might want to use is a complete no-no. Have fun experimenting though!

Good-luck keeping your sanity that way. You should just leave that as behind the scenes stuff.

I tried compiling that with vc++ 2008 Express, and the Microsoft compiler hates it. It doesn't like the "c\n\t" part.

Didn't know this but in C++ you can use pointers or references to achieve the same as you did ...

yeah, I know it's definitely a no-no, I just thought it was kind of cool, being able to cheat the compiler. Get back at it, for all these years of yelling at me, and telling me how wrong I am. Take that!

And the inline-assembly portion of it is compiler specific, since I just use a text editor and not an IDE I had to look up how to do it with my compiler, I'm using gcc- I believe vc++ uses __asm__ either followed by an instruction or followed by several, on separate lines between braces (without the \n\t or quotes)--also, I believe gcc uses at&t assembly format while vc++ uses something else...

and yeah, it would be better done with references but I just thought it was awesome. I wonder what would happen if the a and b in pewp() were defined as strings, or something else--how that would affect the stack in main().

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.