search for: iapx

Am Mittwoch, den 16.04.2008, 00:05 -0700 schrieb Evan Cheng: > Hrm. Are there machines where > instructions may not be byte sized? The iAPX 432 had a bitstream format. See http://en.wikipedia.org/wiki/Intel_iAPX_432 . In a nutshell: the processor was a failure due to many reasons, the bitstream format among them though not particularly prominent. > > +static unsigned sizeGlobalAddress(bool dword) { > > + if (dword) > &...

...uld be "generic" in the sense of being > able to support multiple different languages efficiently. After having > done some work on this, I now believe that this is the case Very cool! I haven't worked on a system with good concurrent garbage collection since using the Intel iAPX-432 back in the mid-1980s. It used Dijkstra's concurrent garbage collection algorithm, which is a mark-sweep collector with three colors. The 432 architecture inherently divided the representation of all objects into two segments, of which one could only contain access descriptors (pointers),...

Comments below. On Apr 15, 2008, at 4:24 AM, Nicolas Geoffray wrote: > OK, here's a new patch that adds the infrastructure and the > implementation for X86, ARM and PPC of GetInstSize and > GetFunctionSize. Both functions are virtual functions defined in > TargetInstrInfo.h. > > For X86, I moved some commodity functions from X86CodeEmitter to > X86InstrInfo. >

OK, here's a new patch that adds the infrastructure and the implementation for X86, ARM and PPC of GetInstSize and GetFunctionSize. Both functions are virtual functions defined in TargetInstrInfo.h. For X86, I moved some commodity functions from X86CodeEmitter to X86InstrInfo. What do you think? Nicolas Evan Cheng wrote: > > I think both of these belong to TargetInstrInfo. And