|
Your query does nothing, in a very expensive fashion, with a typo in your post.
You have joined on Table_A.Column_1 = Table_B.Column_2 and so they already match and the set clause just overwrites the pre-existing value with the same value.
Best to move this to the SQL forum as has been said, however, if the aim is that you have already updated table_A and now want to update the matching records in Table_B this ain't gonna work.
Step 1. Update Table_A, retaining the original IDs in a separate column.
Step 2. Update Table_B, joining on the original IDs and setting the values to the new IDs from Table_A
|
|
|
|
|
|
Hello Everybody,
Form1 has a dataGridView, Form2 is opened for editing specific record after double-clicking on Form1 dataGridView (while Form1 is still open). After editing, Form2 closed and data successfully saved to underlying DataSet.
Question: how to update dataGridView on Form1 that is still opened, after Form2 is closed?
Thanks in advance for any help.
|
|
|
|
|
subscribe to FormClosed event of Form2 in Form1 and in the handler, reassign the DataGridView's DataSource.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)
|
|
|
|
|
Similar to DaveyM69 but I would create an event specifically for the update. FormClose is ok but it doesn't allow you differentiate between by a cancel action or a save action.
I know the language. I've read a book. - _Madmatt
|
|
|
|
|
I agree - I normally use the Form's Dialogresult property for thisDave
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 seems subscription for events makes sense. Thanks to both of you!
|
|
|
|
|
I'm trying to make a 8086 microprocessor simulator in c# which will simulate the code written by the user on hypotetical microprocessor and give the same ideal result as real microprocessor. just like other compilers the architecture of my compiler is the same until Microsoft Intermediate language (MSIL). Specifically in my code generator phase of the compiler I face one problem which may actually be conceptual problem. It is the fact that MSIL uses the stack based archiceture which is confusing me because i'm expecting it to be register based, which i thought it would be easy for implementation. I think that this stack based execuition is not suitable for making such kind of compiler or is there any other way of implementing my needs in .NET please help.
thank you!
|
|
|
|
|
You seem a little confused: why are you producing a compiler to msil for a 8086 microprocessor simulator?
I would expect a µprocessor simulator to take a binary file full of (in this case 8086) machine instructions, and execute them. Not to produce any output file.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
|
|
|
|
|
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!
|
|
|
|
|
Djtech01 wrote: my problem is i can't get machine code through MSIL
The reason you can't get machine code through MSIL is that MSIL is the machine code for a virtual processor: the MSIL is interpreted at run time, not converted in any way to instructions that are directly machine executable. For that reason, it is stack based - because the languages it will support are stack based.
If you want to simulate what a real processor would do with an instruction, then you need to generate that instruction, and then execute that on the simulator - effectively interpreting the 8086 instruction set at run time.
Why are you re-inventing the wheel and developing your own language and compiler, when there are various 8086 compilers out there, and also meta-compilers where you feed them the language description and they give you the compiler?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
|
|
|
|
|
OriginalGriff wrote: the MSIL is interpreted at run time, not converted in any way to instructions that are directly machine executable
Uhhh, not exactly true. MSIL is converted to the processors native machine code upon execution. Remember the Just-In-Time compiler? That's what it does. MSIL is not interpreted at runtime. It's compiled down to native code for the processor it's running on. If you take the exact same MSIL code and execute it on two different processors, say a AMD Athlon 2600 and an Intel Core 2 Duo, you'll get different native code images.
But, since he's simulating an 8086, he can't use the .NET compilers, nor NGEN, to generate his native code since the JIT does not work with such an old processor.
|
|
|
|
|
 My bad!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
|
|
|
|
|
| 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]
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
