Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!usc!zaphod.mps.ohio-state.edu!sdd.hp.com!decwrl!bacchus.pa.dec.com!news.crl.dec.com!shlump.nac.dec.com!tle.enet.dec.com!routley From: routley@tle.enet.dec.com Newsgroups: comp.os.msdos.programmer Subject: TC++ bugs reported to Borland Message-ID: <16797@shlump.nac.dec.com> Date: 29 Oct 90 22:20:42 GMT Sender: newsdaemon@shlump.nac.dec.com Reply-To: routley@tle.enet.dec.com () Organization: Digital Equipment Corporation Lines: 155 I have submitted the following TC++ bug report to Borland. Kevin Routley - Digital Equipment Corporation routley@tle.enet.dec.com Product: Turbo C++ Version: 1.00 OS: MS-DOS V3.2 1. Bitfield Operation Performance Bitfield operations are not optimal. See Example 1 for an example program. Testing the first bit of a multi-bit bitfield struc- ture is done in 20 (8086) cycles with the TEST instruction: TEST WORD PTR [BP-06], 0001 The third bit in a multi-bit bitfield structure is testing by performing a pair of shift instructions, requiring 25 cycles: MOV AX, WORD PTR [BP-06] SHR AX, 1 SHR AX, 1 TEST AX, 0001 Larger bitfield structures use the multiple shift instruction to test higher bits. For example, the eighth bit requires seven shifts and 61 cycles to test: MOV AX, WORD PTR [BP-06] MOV CL, 7 SHR AX, CL TEST AX, 0001 This poor optimization places severe penalties on those programs that might choose to use bitfields to store flags instead of char objects. As far as space is concerned, it is more efficient to use a bitfield structure for three or more boolean flags rather than chars. The bitwise & operator illustrates that all three tests above could have been performed with individ- ual TEST instructions (a total of 63 cycles compared to the 106 cycles required by the above tests): TEST WORD PTR [BP-06], 0001 TEST WORD PTR [BP-06], 0004 TEST WORD PTR [BP-06], 0080 In fact, a series of similar (& or |) operations on bitfield structure elements could be optimized to a single TEST instruction. Example 1: Example Bitfield Program _______________________________________________________ #include main() { struct foo { unsigned flag1 : 1; unsigned flag2 : 1; unsigned flag3 : 1; unsigned flag4 : 1; unsigned flag5 : 1; unsigned flag6 : 1; unsigned flag7 : 1; unsigned flag8 : 1; } flags; char lflag1 = 0; char lflag2 = 1; char lflag3 = 0; char lflag4 = 1; flags.flag1 = flags.flag8 = 1; if ( flags.flag1 && flags.flag8 && lflag2 && lflag4 ) printf("True\n"); else printf("False\n"); ____}__________________________________________________ 2. Macro Expansion Limit The limitation of 4096 characters for a macro ex- pansion is too small for non-toy programs. This can prevent Turbo C++ from being used as a development environment for large programs. Ideally a macro expansion should only be limited by the compiling machine's memory (if that, using memory swapping). As an example, multiple data structures can be easily and conveniently initialized from a single instance of the entered information (illustrated in Example 2. If table_data contains more than a few lines with more than a couple of items, and the author uses spaces to insure readibility, you can easily exceed the 4096 character limit. Example 2: Struct Init. from a Single Set of Data _______________________________________________________ /* setup the data to init all the structures with */ #define table_data \ X( "text1", 0, CONST1, 1, 1, 0, struct1, 1 )\ X( "text1234", 0, CONST1234, 1, 1, 0, struct2, 1 )\ . . . X( "text99", 0, CONST99, 0, 0, 0, structure99, 0 ) /* setup the macro to init table1. Only some of the fields are used. */ #define X (string, foo, bar, fum, foobar, dataptr, flag )\ { foo, bar, fum, flag } /* table1 is an array of structs, each with four int fields */ table1[MAX_TABLE] = { table_data }; #undef X /* setup a different macro to init table2. Different fields are used this time. */ #define X (string, foo, bar, fum, foobar, dataptr, flag )\ { flag, string } table2[MAX_TABLE] = { table_data }; #undef_X_______________________________________________ 3. TC.EXE Display Customization I am unable to customize the colors of the inte- grated environment so that they display reasonably on my monochrome VGA monitor. TCINST has an option "Mode for Display". No matter which option I select (e.g. Black and White, or Monochrome) to customize TC.EXE to have, I always get the same default color display mode when I invoke TC.EXE. The default mode is very difficult to read on my monochrome display.