|
| Your simulator should be interpreting and simulating 8086 instructions, not MSIL. Your compiler should not generate MSIL for such a product, unless the microprocessor also runs the .NET Framework (which I doubt). txtspeak is the realm of 9 year old children, not developers. Christian Graus
|
|
|
|
|
Are you 'compiling' x86 machine code to MSIL? (why?)
If so, what's the problem? The registers should probably not go on the stack, but in local variable slots - that's not really a problem though
edit: Oh I see now, I misunderstood your intentionsmodified on Monday, March 15, 2010 10:54 AM
|
|
|
|
|
Hi,
now I'm getting the picture of what it is you are trying to do.
I've created lots of microprocessor simulators over the years, using all kinds of languages, from Fortran4 to C#. And I have ran hundreds of millions of simulated instructions on them! I assume you are looking for logic simulation at the user level (i.e. executing the programming model correctly in user mode, but not getting accurate timing as to number of cycles per instruction, and probably not modeling all the protection levels); and I assume you want maximum performance.
You seem set out to generate some IL code to accomplish that. Well, I haven't done so (at least not for simulation), and I am not inclined to do it any time soon. It is perfectly feasible, but I don't believe it leads to best performance.
Functions/methods in most, if not all, languages have one dominant characteristic: they use a stack model, however the stack before and after the execution is in the same state. The same is true in IL; a method may push a few items, it is bound to pop exactly the same number of items before it can return. IL validators will even check for that. So there should really not be any problem in creating an IL method that simulates one (or a series of) microprocessor instruction(s). The only thing is, I don't want to call a method for every instruction simulated.
My latest simulators (assuming a simple RISC processor for a minute) contain one huge switch statement, with lots of cases, one for each instruction type. On a CISC, that might be 256 cases, one per byte value. And each case holds one or a few lines simulating the instruction. Beware, the most code often is required for getting all the flags right (zero, negative, carry, etc). And the other design decision that needs careful analysis is how and where to keep the procoessor state; you can organize it very OO-like, but then you will pay the price for each access. Keeping one array of registers often is a fair approach.
|
|
|
|
|
Semi-hijacking here Luc...
I've often thought about writing a version of C# that can be used for higher level programming of PICs - the actual code entered by the user would be compiled down to either .asm/.s and use the free PIC compiler(s) or directly to .hex.
There are various versions of Basic( say no more) around for the PIC, and then either C (their versions are a nightmare IMO) or assembly. I use assembly but a nice C# type language would be very nice to have!
I did make a tentative start on this a few months ago but shelved it as I found myself writing a lot of inline code or one to one methods that weren't very reusable so I figured I needed a rethink. Maybe I had the right aproach? I keep meaning to take a look at F# as it seems like it may be better suited - any opinion?Dave
Binging is like googling, it just feels dirtier. (Pete O'Hanlon)
BTW, in software, hope and pray is not a viable strategy. (Luc Pattyn)
Why are you using VB6? Do you hate yourself? (Christian Graus)
|
|
|
|
|
I've done my share of PIC stuff too, all using assembly on a miniature PIC (16F84); it does serial port (9600baud), CAN-like network(around 10Kbps), 32 digital inputs, 32 digital outputs, and then some; 5 such nodes plus two Macs is what controls my model railroad. I don't have a UART, I don't have CAN hardware, I don't use timers, I don't use interrupts; they are all costing too much; I have a multi-tasking kernel and very cooperative tasks, running slices of less than 60 cycles (dictated by bit sampling on serial input and CAN input).
With very limited resources (68B of RAM IIRC), a high-level language doesn't make sense to me. I rather have a good development environment with simulator. The C# language has its shortcomings for embedded stuff; I want bit variables, bit fields, unions, etc. Things C offers and C# does not. Needing every cycle and every byte, I didn't use C either. Haven't looked into F#, if its strictly functional, I can't use it. I'm an imperative kind of guy!
I did lots of Basic pseudo-interpreters long ago. I made my own Basic computer (hardware and software) before PCs were available. When they were, I started using Macs, not being impressed by DOS and early Windows. The Stamp stuff looks nice, I haven't used it though. I did analyze its performance once (based on an early AVR chip), and decided it was near optimal.
|
|
|
|
|
My only direct µC experience is with PICs. I started with a 16F628 and a couple of 16F84s. Nowadays I tend to use the dsPIC30F series as they are pretty quick (30MIPS), have a good peripheral selection and are available in DIP so useful for prototyping. The asm is very different from the 16F and 18F (which I also dabbled with for a while) but pretty easy once you get your head around it. I design a fair bit of MIDI hardware (you know my interest in MIDI from our PInvoke discussions) and many of the dsPIC30Fs have 2 EUSARTs making them very useful!
Luc Pattyn wrote: With very limited resources (68B of RAM IIRC), a high-level language doesn't make sense to me.
The PICs I use have more than that but still limited compared to a PC, if it were an issue I could add external RAM when needed.
If I was embedding an interpreter in the µC then I would agree. What I meant, but didn't express clearly, was designing an IDE (in C# or F#) along with a language that has C# like syntax and feel, along with a Sim etc...
That's all doable, the problem comes with the compiler to convert the 'C#' like user code to either asm or directly to hex. This seemed to create very long methods full of switch blocks or if elses and I couldn't figure out a sensible way of avoiding it, but it felt very wrong!Dave
Binging is like googling, it just feels dirtier. (Pete O'Hanlon)
BTW, in software, hope and pray is not a viable strategy. (Luc Pattyn)
Why are you using VB6? Do you hate yourself? (Christian Graus)
|
|
|
|
|
DaveyM69 wrote: the problem comes with the compiler to convert the 'C#' like user code to either asm or directly to hex.
If you haven't read it yet, the Dragon book (Aho,Seti,Ullman) is a must. It will tell you you need an internal representation of the source code, optimize it at the abstract level, emit assembly code, and perform local optimizations. Some architectures have general-purpose registers that can hold data or pointers all the same; others (I'm afraid they include all kinds of PIC), are rather weak at using pointers and that makes thorough optimization crucial, otherwise the CPU is spending the majority of its time handling pointers instead of data.
Most commercially available compilers that claim to perform all kinds of optimizations only do so in very simple cases, sometimes because C isn't allowing one to express conditions that allow for optimization (invariants), most often because the vendors don't want to invest heavily in it. So I did several attempts at creating a really optimizing C compiler, not always for the same CPU family. It ain't simple; one easily gets code that clearly can be improved, however all the strategies, tactics and tricks involved are difficult to program and coordinate. So I developed some postprocessors that replace suboptimal instruction sequences by better ones.
OTOH I'm not convinced a high-level language is what a lot of microprocessor applications need; a lot of them are better served with assembly, so I would focus on providing a maximum of comfort to assembly language programming.
I developed my IDE in C# (started in .NET 1.0; then 1.1; now 2.0), after doing a partial implementation in Java. I use it as a workbench for most of my software activities, including all embedded stuff; it allows me to share source code and project files across microprocessor families. However I still use Visual Studio for .NET languages on PC.
I'll put reading up on F# on my TODO list.
|
|
|
|
|
Luc Pattyn wrote: If you haven't read it yet, the Dragon book (Aho,Seti,Ullman) is a must.
It's my birthday in a fortnight - added to the 'really need and want list' at index 0!Dave
Binging is like googling, it just feels dirtier. (Pete O'Hanlon)
BTW, in software, hope and pray is not a viable strategy. (Luc Pattyn)
Why are you using VB6? Do you hate yourself? (Christian Graus)
|
|
|
|
|
A really powerful tool for writing a compiler (not for the IDE) is ANTLR [^] (beware: it is Java based).
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
[My articles]
|
|
|
|
|
CPallini wrote: it is Java based
Ouch! I had a play with Java when I first got my Blackberry, it reminds you of just how lucky we are to have an IDE such as VS - unless you know a really good one that I missed?Dave
Binging is like googling, it just feels dirtier. (Pete O'Hanlon)
BTW, in software, hope and pray is not a viable strategy. (Luc Pattyn)
Why are you using VB6? Do you hate yourself? (Christian Graus)
|
|
|
|
|
It's not that much Java based, it can generate parsers in many languages (including C#)
But you need to have Java installed to run it 
Anyway I started using Coco/R recently, it even has Visual Studio integration
|
|
|
|
|
harold aptroot wrote: It's not that much Java based, it can generate parsers in many languages (including C#)
But you need to have Java installed to run it
Is is Java based. However, as you correctly pointed out may generate parsers for many target languages [^].
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
[My articles]
|
|
|
|
|
For grammars there is a beautiful IDE (until it, eventually, hangs...), ANTLRWorks [^]. I really don't know a good Java IDE, I liked more NetBeans than Eclipse, because the latter was, in my experience, deadly slow.
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
[My articles]
|
|
|
|
|
Let me explain in a more detail way.
I'm creating my own language and compiler for.NET framework for the purpose of simulating microprocessor specifally 8086.
so what my user going to do is to write a code in my new language grammer and compile the result by my compiler to see what a real processor will resposed for that code. just like emu8086 software if u see it.
to this end I have to go through all the steps of compiler construction. that's why I got through MSIL and then to registers which actually uses machine language.
my problem is i can't get machine code through MSIL which uses stack based execuition but i need register based execuition for getting these machine code.
or if u have any other options please suggest me?
thank you!
|
|
|
|
|
You cannot use the .NET enviornment, compilers, ..., .NET anything to generate your code. The .NET Framework will not run on a 8086 machine.
You can write your own x86 compiler in C#, you just cannot use the .NET Frameworks CodeDom to create your compiler.
|
|
|
|
|
This exact same quetsion came up last week. Again, .NET's compiler and the fact that it's exection is stack based has absolutely no bearing on your compiler or simulator. The only way it could was if you were using the .NET compilers in your own "compiler" to do all of the work for you. In that case, you're not writing your own compiler, just wrapping the .NET compilers. This won't work for you since the .NET compilers do not generate native x86 code.
|
|
|
|
|
now i'm figuring out something
just to forget about MSIL and continue with functions and arrays to get 8086 code and return the same way
|
|
|
|
|
| Yes! That's the idea! You should never use standby on an elephant. It always crashes when you lift the ears. - Mark Wallace
C/C++ (I dont see a huge difference between them, and the 'benefits' of C++ are questionable, who needs inheritance when you have copy and paste) - fat_boy
|
|
|
|
|
thank u very much
I'll try to do it this way
and we will contact if anything goes wrong
thanks
|
|
|
|
|
Hi All,
I want to be able to create an instance of a COM object dynamically, given it's GUID. Having created an instance of the COM object I would like to use reflection to show in a list control the functions that this object exports. I don't want to import the COM object at design time and create a class from it - the COM object is changing regularly, it's a test harness that's being developed concurrently by a set of users.
Is this possible? If so, how do I create the COM object from the GUID only?
Thanks in advance,
Dave Kerr
|
|
|
|
|
| Creating the COM object is no problem, but such objects do not support reflection. The only way to get the information you need is through the object's type library. There are a number of COM articles here on CodeProject that include suggestions as to how to proceed with this. txtspeak is the realm of 9 year old children, not developers. Christian Graus
|
|
|
|
|
You can use GetTypeFromCLSID to get a COM Type give its GUID.
Then you can use Activator.CreateInstance to create an object instance from that Type.
|
|
|
|
|
Mirko1980 wrote: Then you can use Activator.CreateInstance to create an object instance from that Type. "Opinions are neither right nor wrong. I cannot change your opinion. I can, however, change what influences your opinion." - David Crow
Never mind - my own stupidity is the source of every "problem" - Mixture
cheers,
Alok Gupta
VC Forum Q&A :- I/IV
Support CRY- Child Relief and You
|
|
|
|
|
Refer also to Richard's answer: I fear you can't get full Reflection information from a COM object.
|
|
|
|
|
Thanks for the info, so as I understand it, I can use Activator.CreateInstance to get the COM object, but I cannot use reflection.
However, can I programmatically load the type library and get the function names from that? Again, I don't want to create a class from the type library, but dynamically retrieve the function names and parameters they take from a type library at runtime...
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
