Issue #56: 22 April, 1997

  • Prev: Upfront #55
  • Curr: Upfront #56
  • Next: Upfront #57 

    • Is the MMX Scare Legitimate?

    Reader Bob Elman reports: I've done a bit more digging into the MMX Scare issue and I'm 
    convinced that there's not much to it. As far back as I've been able to track the origins of the scare are an InfoWorld  
    article, which in turn references an Intel spec on the MMX instruction set. Here are relevant quotations, first from the 
    InfoWorld article and then from the Intel spec: 

    "Performance may turn out to be the least of Intel's problems ... running multiple applications can lead to 
    incorrect floating-point calculations. 

    "Here's how it can happen. Suppose you're browsing a graphics site on the World Wide Web while doing work on a 
    spreadsheet. The spreadsheet happens to be in the middle of a floating-point calculation when the browser jumps in and 
    switches the P55C processor into MMX mode. But it forgets to switch it out. Your spreadsheet, which is a legacy program 
    that doesn't know anything about MMX mode, assumes that the data in the floating-point registers is, well, floating- 
    point data. But it's not. It's graphics data." 

    From Intel's spec: 

    "When an MMX technology instruction executes, the floating-point tag word is marked valid (00s). Subsequent floating- 
    point instructions that will be executed may produce unexpected results because the floating-point stack seems to 
    contain valid data. The EMMS instruction marks the floating-point tag word as empty. Therefore, it is 
    imperative to use the EMMS instruction at the end of every MMX technology routine. The EMMS instruction must be used in 
    each of the following cases:  What this looks (to me) to be saying at a surface reading is that failure to use an EMMS instruction at the right time 
    can cause interference among applications. When I dig a bit deeper in the sections of the specification devoted to task 
    switching within operating systems, it's pretty clear that, at least according to the design, the problem can't happen 
    within existing standard operating systems and environments. (I can't rule out bugs in either the MMX silicon 
    implementation or the operating system task switcher, but it's highly likely that any such bugs would have been 
    quickly found and fixed by now.) 

    For those of you who are a bit more "into the bits" in orientation, here's what's really going on as best as I can 
    tell from the various specs I've read: 

    MMX and FP operations appear to use the same registers and therefore cannot (meaningfully) be intermixed. There is NO 
    accessible state bit indicating whether the processor is in MMX or FPU mode, although, given the timing of the 
    instructions, it would seem that the CPU must have such a state bit internally. When the FP/MMX register set is 
    allocated to a running task by the operating system, that task may freely use them in any way it sees fit. It doesn't 
    matter to the operating system whether the task thinks the processor is in MMX or FP mode since that switch is 
    automatic, albeit slow, upon the execution of an instruction from either set. 

    Consequently, any operating system or environment which correctly switches tasks now with tasks executing floating 
    point operations will also switch correctly with tasks using MMX and/or floating point instructions. 

    The EMMS instruction is used WITHIN a task to clean up the register set CONTENTS after using MMX instructions so 
    that meaningful results can be had from following floating point instructions. The more detailed documentation makes it 
    fairly clear that there is no obligation to use the EMMS instruction, just that it's the quickest/easiest way to get 
    the shared FP/MMX register contents looking about like they would after a reset. 

    As pure speculation, the root of the misunderstanding may have been the last sentence I quoted from the Intel spec 
    above: 

    "The EMMS instruction must be used in each ... switch between MMX technology code in a task/thread and other 
    tasks/threads in cooperative operating systems." 

    What (I think) they are talking about here is a system in which task switches are performed within what would be 
    considered to be a single application in Windows terminology. An embedded system in which resources were 
    shared among co-operating tasks rather than saved and restored by part of the operating system itself would be 
    another such example. The key word is "cooperative." (I defy anyone to categorize any Windows or MS-DOS based system as 
    "cooperative". :-) 

    Any system such as Windows (3.x, NT, '95, etc.) must of necessity save and restore the floating point state on task 
    switches. There is a mechanism which allows the system to delay the reload portion of the task switch until the 
    switched-to task actually attempts to use an FP or MMX instruction set, but logically the results are equivalent. 

    About the only way I can think where it might be possible to get into some trouble would be if the floating 
    point capability were turned off within some operating system (or for specific tasks). 

    An example would be if you had an older Pentium processor with the floating-point division bug and you had 
    instructed the operating system to disable floating-point operations out of paranoia. In such a case, the operating 
    system might not save and restore floating-point state at all. The result would be that you would also effectively 
    disable the MMX instruction set. 

    Note that while you get an interrupt that allows emulation of floating-point instructions when the floating- 
    point processor is disabled, you only get an illegal operation interrupt if you execute an MMX instruction under 
    those conditions. You still wouldn't see inter-application interference, however. You'd just have all applications that 
    tried to use the MMX instruction set fail hard. 

    Of course, the true test is in the correct operation of systems deploying MMX technology and not in interpretations 
    of the specifications. If anyone has any hard contrary evidence to my conclusions above, I'd be most interested in 
    hearing about it. 

    Top 10 Most Forgotten - Answered

    Chris Bradshaw Dir, Product Marketing and Design, AutoCAD Market Group, replied to the list of 
    Top 10 Most Forgotten Improvements to R14: 

    > 10. Some commands that used to present command-line prompts -- such as Layer and Linetype -- have been converted to 
    > display dialog boxes by default. Why not others, such Rename and the particularly yucky Units command? 

    This is something we struggle with every release. There are now more than 1.6 million (legal) AutoCAD users in the 
    world. We always have to balance maintaining the user interface for those user against evolving and modernizing 
    for new paradigms. We believe that the right strategy for AutoCAD is to evolve the UI over a couple of releases rather 
    than changing the entire thing at once. We believe that dialog boxes, icons, etc. (more of a graphical user 
    interface) is the right direction for AutoCAD, but we do not want to minimize disruption to our long time customers. We 
    will continue to evolve and the specific items you have indicated will be modernized in the future. 

    > 9. You can fillet a 3D solid model but not a 2D multiline. Most editing commands -- including useful ones, like Trim,  
    > Extend, Chamfer, and Fillet -- still don't work with multilines. 

    True. We have not enhanced multilines in R14 beyond their capability in R13. Because multilines are most used by 
    Architecture/Engineering/Construction (AEC) customers we have shifted the focus of development of this feature from 
    core AutoCAD to our AEC group. Look for more on this capability in the future. 

    > 8. Although display-list processing now works in paper space, you get a regen every time you switch to a viewport,  
    > then change the view (such as zoom). And you still can't start the Zoom command, then switch viewports. 

     The first issue you raise is a limitation of our display system. We will work to improve this in the future 
    (just as we greatly improved display performance in paper space in R14). On the second issue, what is the use scenario 
    where you would want to start a zoom command and then switch viewports? 

    > 7. SlideLib.Exe is still busted -- after all these years, you still cannot append SLD slide files to a SLB slide 
    > library file. 

     This capability never existed, but I think that is your point. This is something we will look at. 

    > 6. This Windows 95/NT-only app still ships with DOS-based utilities programs, including SlideLib.Exe, Mc.Exe, and 
    > Dxfix.Exe. 

    Again, this a part of our evolutionary approach to updating AutoCAD. These DOS-based utility programs will 
    disappear in the next release. 

    > 5. You need to double-click to change a toggle -- such as SNAP and TILE -- on the status line. Why not a single click,  
    > like all other clicks in AutoCAD? 

    This is as designed. The reason for it is that this is the convention that Microsoft has established for status- 
    type toggles. I invite you to try the status-type buttons at the bottom of Word. They also require a double click. 

    > 4. No changes to the 12-year-old PEdit command. 

     What changes would you like to see? [Some ideas include: ability to work with more than one polyline and  
    ability to join polylines not touching. -- Ed.] 

    > 3. No multiline styles. It would one Autodesk employee one hour to create a dozen or so standard wall styles, like 
    > brick-wood-gyproc. 

    Again, I'll defer this to the AEC add-on products (both from Autodesk and 3rd party developers) that include this 
    type of functionality. 

    > 2. No wizards to help you create, place, edit, and extract -- especially extract! -- attributes. 

     This is a great suggestion. We will definitely look at doing this. 

    > 1. No new 3D tools (other than rendering). 

    We recognize that there are many additional editing operations users want and we will be enhancing this area 
    significantly in the future. Also, there are very strong products that 3rd party developers and other Market Groups 
    at Autodesk have built on top of R14 that include great editing of solids (e.g. Mechanical Desktop). Again, you will 
    see some exciting new 3D capability coming from Autodesk Market Groups and 3rd Party developers. 

    CAD and Internet News Headlines

    ++ 
    Merge Mania: Oracle CEO Larry Ellison says he'll decide in a couple of weeks whether to launch a takeover bid for Apple  
    Computer. Once in control, he would abandon high-end Macs and make low-cost NCs (network computers) instead. 
        Meanwhile, America Online has said it is interested in buying portions of CompuServe and not all of it. Microsoft 
    is also interested in buying CompuServe. 

    Autodesk: Autodesk commissioned an independent test of reading, writing and exchanging AutoCAD DWG drawing files, 
    which showed AutoCAD LT to be the only low-cost CAD package "capable of maintaining visual and data integrity and 
    offering acceptable performance." The competition included Corel Visual CADD, Intergraph Imagineer Technical, TurboCAD  
    2D, and Visio Technical. 

    Bentley Systems: Market research firm Dataquest found that in 1996 Bentley sold US$52.4 million of MicroStation for 
    Windows NT, while Autodesk sold US$13.9 million of AutoCAD for Windows NT in the three vertical markets of AEC, GIS and 
    mechanical. Bentley also outsold ESRI in the GIS market. 

    DataCAD: Has moved to 20 Tower Lane, Second Floor, Avon Park South, Avon, CT 06001 USA. New phone numbers: Main + 1 (860) 
    677-4004, Sales +1 (800) 394-2231, Tech +1 (860) 677-2829, Sales Fax +1 (860) 677-2610, Tech Fax +1 (860) 677-2883, 
    BBS +1 (860) 677-2968. 
        DC Viewer is an architectural view manipulation and image processing program with VRML 2.0 output. It is 
    DataCAD's first 32-bit CODe-based Windows 95/NT software for architectural CAD users. 

    Intergraph: Reporting a net loss for the first quarter ended March 31, 1997 of US$0.55 per share on revenues totaling 
    US$253 million. Orders for new systems totaled US$159 million, up 10%. 

    Netscape: Netcaster is a software client to enable "push" delivery of content to the desktop. including ABC News and 
    CNNfn. Formerly code-named "Constellation," Netcaster is due to be available in Communicator within 30 days. 

    SimpleCAD: Simple Symbol System is a simple solution for AutoCAD symbols. Download the working demo from 
    http://www.simplecad.com 

    Steptools: Improved version of the Windows EXPRESS-G Viewer v2.0 beta 1 is available free at 
    http://www.steptools.com/expg-view/   

    Visio: Reporting revenues for 1Q97 were US$23.5 million, up 62%. Profits more than doubled. 
        Visio unveiled developer services, including: (1) new developer-focused Web site at http://www.visio.com/devweb/ ; 
    (2) expanded developer training; and (3) content from the recent Visio Solutions Conference published on CD-ROM. 

    Jargon Watch 

    JNI -- "Java native interface," Sun's Java to native-code interface; Netscape plans to support JNI. 

    Spin Doctor of the Moment 

    "This huge delay among other vendors to support AutoCAD Release 13 means that customers of non-Autodesk products 
    will not be able to read any of the drawing files created by AutoCAD Release 13 since its introduction, more than two 
    years ago." 
        -- Autodesk press release, which failed to mention that the R13 DWG file format changed several times in that two- 
    year period with the 11 different versions of R13. 

    Contact! 

    All contents copyright XYZ Publishing, Ltd. Inc., 1997 and all rights are reserved. No material may be reproduced electronically or in print without written permission from XYZ Publishing, PO Box 3053, Sumas WA, 98295-3053, unless otherwise noted.