CLR
-
I already told you what goes on the stack, and why the other things don't fit on a stack. Things are the way they must be. For me the subject is closed. :)
Luc Pattyn [Forum Guidelines] [My Articles]
this weeks tips: - make Visual display line numbers: Tools/Options/TextEditor/... - show exceptions with ToString() to see all information - before you ask a question here, search CodeProject, then Google
No - let him implement the OS as well. That should be worth seeing.
Deja View - the feeling that you've seen this post before.
-
No - let him implement the OS as well. That should be worth seeing.
Deja View - the feeling that you've seen this post before.
OK, on one condition, Chris should start a separate forum for it, since I expect a couple more discussion threads before the new OS is up and running...
Luc Pattyn [Forum Guidelines] [My Articles]
this weeks tips: - make Visual display line numbers: Tools/Options/TextEditor/... - show exceptions with ToString() to see all information - before you ask a question here, search CodeProject, then Google
-
So, it's the OS that allocate space on the stack for the process?! If it's so, I think that can't exists a (new) CLR that manage stack..!? I understand that for my question, CLR would have to do the work of OS; so i would have to change OS too; is it that? Then arise one question on C#:
namespace Simple { class Program { static void Main(string[] args) { Console.WriteLine("that's the program"); int a = 0; myClass mc = new myClass(); } } }I read that every value type (int32, enumeration, and other) are on the stack; but if they're inside a class declaration they take part of object and then go on the heap. In c# even main is inside a class (in my example " Program"); with this knowledge, it seems to me that evey things goes on the heap. Could you explain to me what go on the stack ? (use my example code, please) Thanks...MarKus0 wrote:
So, it's the OS that allocate space on the stack for the process?!
No, not entirely. The processor has a stack the is allocated on a per-thread basis. Ever here of the Stack Pointer? Read[^] It's the processor that's stopping you from doing what you want, not the .NET Framework or the O/S.
A guide to posting questions on CodeProject[^]
Dave Kreskowiak Microsoft MVP Visual Developer - Visual Basic
2006, 2007 -
OK, on one condition, Chris should start a separate forum for it, since I expect a couple more discussion threads before the new OS is up and running...
Luc Pattyn [Forum Guidelines] [My Articles]
this weeks tips: - make Visual display line numbers: Tools/Options/TextEditor/... - show exceptions with ToString() to see all information - before you ask a question here, search CodeProject, then Google
Seems fair. He'll need a cool name for the project though. How about calling it "Pillock" or "Idiot"? That way we can ask people "Are you running Idiot?"
Deja View - the feeling that you've seen this post before.
-
MarKus0 wrote:
So, it's the OS that allocate space on the stack for the process?!
No, not entirely. The processor has a stack the is allocated on a per-thread basis. Ever here of the Stack Pointer? Read[^] It's the processor that's stopping you from doing what you want, not the .NET Framework or the O/S.
A guide to posting questions on CodeProject[^]
Dave Kreskowiak Microsoft MVP Visual Developer - Visual Basic
2006, 2007Dave - don't let facts get in the way of our mocking him.
Deja View - the feeling that you've seen this post before.
-
MarKus0 wrote:
So, it's the OS that allocate space on the stack for the process?!
No, not entirely. The processor has a stack the is allocated on a per-thread basis. Ever here of the Stack Pointer? Read[^] It's the processor that's stopping you from doing what you want, not the .NET Framework or the O/S.
A guide to posting questions on CodeProject[^]
Dave Kreskowiak Microsoft MVP Visual Developer - Visual Basic
2006, 2007Dave Kreskowiak wrote:
It's the processor that's stopping you from doing what you want, not the .NET Framework or the O/S.
IMO that is not entirely true; this is how I see it: - most processors don't support heaps at all, yet lots of OS need heaps, so these get implemented by software; - stack structures can be implemented by software (e.g. the Stack class in .NET); - there (still) are processors that don't provide hardware support for a stack, yet a stack-based language (and OS) can made to run on them; when they have say a shadow register for PC (into which the PC gets copied upon CALL or INT), each function must start saving the shadow PC on a software stack; - alternatively, if the CPU offers stack support (i.e. pushes the PC to a memory location thru a pointing register) and you don't like the way it works, you can undo it by software, and keep track of program flow in some other way. - IIRC Intel's IA432 architecture did not have real stack support, instead it allocated nodes (on the heap!) that got linked back and forth, resulting in a distributed structure with stack behavior. So I would say most OS really want to have hardware supporting a stack, and hence most chip vendors provide exactly that, but either one can choose to do it differently (which they seldom do). :)
Luc Pattyn [Forum Guidelines] [My Articles]
this weeks tips: - make Visual display line numbers: Tools/Options/TextEditor/... - show exceptions with ToString() to see all information - before you ask a question here, search CodeProject, then Google
-
Seems fair. He'll need a cool name for the project though. How about calling it "Pillock" or "Idiot"? That way we can ask people "Are you running Idiot?"
Deja View - the feeling that you've seen this post before.
Hmm, learning a least one new word every day now. I like that. :-D
Luc Pattyn [Forum Guidelines] [My Articles]
this weeks tips: - make Visual display line numbers: Tools/Options/TextEditor/... - show exceptions with ToString() to see all information - before you ask a question here, search CodeProject, then Google
-
Dave Kreskowiak wrote:
It's the processor that's stopping you from doing what you want, not the .NET Framework or the O/S.
IMO that is not entirely true; this is how I see it: - most processors don't support heaps at all, yet lots of OS need heaps, so these get implemented by software; - stack structures can be implemented by software (e.g. the Stack class in .NET); - there (still) are processors that don't provide hardware support for a stack, yet a stack-based language (and OS) can made to run on them; when they have say a shadow register for PC (into which the PC gets copied upon CALL or INT), each function must start saving the shadow PC on a software stack; - alternatively, if the CPU offers stack support (i.e. pushes the PC to a memory location thru a pointing register) and you don't like the way it works, you can undo it by software, and keep track of program flow in some other way. - IIRC Intel's IA432 architecture did not have real stack support, instead it allocated nodes (on the heap!) that got linked back and forth, resulting in a distributed structure with stack behavior. So I would say most OS really want to have hardware supporting a stack, and hence most chip vendors provide exactly that, but either one can choose to do it differently (which they seldom do). :)
Luc Pattyn [Forum Guidelines] [My Articles]
this weeks tips: - make Visual display line numbers: Tools/Options/TextEditor/... - show exceptions with ToString() to see all information - before you ask a question here, search CodeProject, then Google
I was speaking from the Intel/AMD perspective, which does support execution stacks.
Luc Pattyn wrote:
- alternatively, if the CPU offers stack support (i.e. pushes the PC to a memory location thru a pointing register) and you don't like the way it works, you can undo it by software, and keep track of program flow in some other way.
I don't think he's up to the task of re-writing the O/S just yet! :-D
A guide to posting questions on CodeProject[^]
Dave Kreskowiak Microsoft MVP Visual Developer - Visual Basic
2006, 2007 -
Dave - don't let facts get in the way of our mocking him.
Deja View - the feeling that you've seen this post before.
My bad! :-> Please, proceed. I love a good show! :laugh:
A guide to posting questions on CodeProject[^]
Dave Kreskowiak Microsoft MVP Visual Developer - Visual Basic
2006, 2007 -
MarKus0 wrote:
So, it's the OS that allocate space on the stack for the process?!
No, not entirely. The processor has a stack the is allocated on a per-thread basis. Ever here of the Stack Pointer? Read[^] It's the processor that's stopping you from doing what you want, not the .NET Framework or the O/S.
A guide to posting questions on CodeProject[^]
Dave Kreskowiak Microsoft MVP Visual Developer - Visual Basic
2006, 2007Guys please answer this..Why value type instances are int stack?
M.Sendilkumar
-
Guys please answer this..Why value type instances are int stack?
M.Sendilkumar
I thought we answered this already. Because access to it is much faster than allocating memory on the heap for it, handling the pointer math, copying the values back and forth between memory and a register. On the stack, all that happens to get/set the value is the stack pointer is moved.
A guide to posting questions on CodeProject[^]
Dave Kreskowiak Microsoft MVP Visual Developer - Visual Basic
2006, 2007 -
MarKus0 wrote:
but will it be possible?
No it won't. For the reasons Luc gave. This is a fundamental principle of the way stacks work in computer programs, and it has been pretty much since the first tiem a computer programmer created a subroutine.
Upcoming FREE developer events: * Glasgow: Agile in the Enterprise Vs. ISVs, Mock Objects, SQL Server CLR Integration, Reporting Services, db4o, Dependency Injection with Spring ... * Reading: SQL Bits My website
Hi, I found that code around. Is it possible with managed c++ extension create oblects on the stack???? Does anyone explaim me that? Is this below true? In positive case, what does CLR do to allocate bHeap and bStack (I mean the difference)? thanks
value class classB { private: int value; }; classeB^ bHeap = gcnew classeB(); //on managed heap classeB bStack; //on managed stack -
Hi, I found that code around. Is it possible with managed c++ extension create oblects on the stack???? Does anyone explaim me that? Is this below true? In positive case, what does CLR do to allocate bHeap and bStack (I mean the difference)? thanks
value class classB { private: int value; }; classeB^ bHeap = gcnew classeB(); //on managed heap classeB bStack; //on managed stackMarKus0 wrote:
what does CLR do to allocate bHeap and bStack (I mean the difference)?
Why not see for yourself. Why not compile the code then look at the compiled IL through ILDASM (comes with the .NET SDK) or with a tool such as Lutz Roeder's Reflector (a quick google away)
Upcoming FREE developer events: * Glasgow: Agile in the Enterprise Vs. ISVs, db4o: An Embeddable Database Engine for Object-Oriented Environments, Mock Objects, SQL Server CLR Integration, Reporting Services ... My website