Maximum number of operands for x86 and x64 instruction set ?
|
From: MitchAlsup on 14 Jun 2010 10:54 On Jun 14, 1:06 am, Terje Mathisen <"terje.mathisen at tmsw.no"> wrote: > MitchAlsup wrote: > > buffer that can be printed after the atomic event has transpired. It > > seems to me there is no way to correctly give the illusion of > > atomicity and allow single stepping through an atomic event.} > > Please excuse me, but DUH! {Please to excuse, but we had to explain this over and over and over.} > Are you saying that there are people who demand/require this ability? > > I thought the definition of "atomic" was "indivisible", so obviously > even single-stepping code would have to treat such a block as a single > instruction, right? Yes, the whole atomic part of the block is either performed or not. But, the sublty is that only those memory location participating in the atomic event are atomic. Other (non-participating) memory locations are not necessarily atomic. This provides the leeway to dump intermediate state to a buffer and print it to see what happened, and why the atomic event failed. Mtich
From: MitchAlsup on 14 Jun 2010 10:59 On Jun 14, 2:53 am, n...(a)cam.ac.uk wrote: > That's NOT the very old days! In those, the debugger would misbehave > horribly. Yes, I know that we seem to have warped back there :-( I remember trying to debug some messy interrupt code on a machine that was not capable of taking a second interrupt durring an interrupt. Once you develop techniques for this stuff..... Mitch
From: Terje Mathisen "terje.mathisen at on 14 Jun 2010 11:39
MitchAlsup wrote: > On Jun 14, 2:53 am, n...(a)cam.ac.uk wrote: >> That's NOT the very old days! In those, the debugger would misbehave >> horribly. Yes, I know that we seem to have warped back there :-( > > I remember trying to debug some messy interrupt code on a machine that > was not capable of taking a second interrupt durring an interrupt. > Once you develop techniques for this stuff..... I debugged IRQ handlers by first setting the display to a known text mode, with a fixed (real) address, then the IRQ code could write info directly to the frame buffer. This worked even within the initial global interrupt disable portion. You can do similar things with polled access to an RS232 port, writing trace/debug to a monitoring machine, but this is _far_ slower than the frame buffer access. OTOH it makes it easy to save the logs. :-) Terje -- - <Terje.Mathisen at tmsw.no> "almost all programming can be viewed as an exercise in caching" |