Closed Bug 28817 Opened 25 years ago Closed 25 years ago

Solaris/Intel/WS5.0: missing xptcinvoke_asm_x86_soalris.s

Categories

(Core :: XPConnect, defect, P3)

Product:
Core
Component:
XPConnect
Platform:
Sun
Solaris
Type:
defect

Tracking

()

Status:
RESOLVED FIXED

People

(Reporter: amarzec, Assigned: shaver)

Details

Attachments

(5 files)

.tar.gz of two modified (incomplete) assembler files for Solaris Intel platform with Sun compilers.
3.32 KB, application/octet-stream
Details
Diffs to get the two files containing the inline Solaris Intel assembler to build/run for both Gnu and Sun native compilers.
9.43 KB, patch
Details | Diff | Splinter Review
CVS diffs to get Mozilla to build/run on the Solaris Intel platform with the native Sun compilers
11.82 KB, patch
Details | Diff | Splinter Review
Small adjustment to the config/build diffs as suggested by cls.
11.82 KB, patch
Details | Diff | Splinter Review
Added in suggestions from mccabe and brendan
12.21 KB, patch
Details | Diff | Splinter Review
xptcinvoke_asm_x86_soalris.s is missing xptcstubs_asm_X86_solaris.s is missing Can you just use ansi c for this functionality??? I use a sun workshop compiler 5.0 for X86 and dont have a clue how to manipulate the program stack as you do with gcc. Would it not carry you a lot further in to find a good way of producing this code in ansi C. I applaud the cleverness of the writers on makeing this code only were does it leave the rest of us not so bright ones. Even if you know its slower if it at least works thats all anyone would ask. Thanks for your kind attention
porting issue. jband, i really hate to dump this on you, but, i'm not sure where else to put it.
Assignee: waterson → jband
Component: XP Miscellany → XPConnect
QA Contact: brendan → rginda
If it could be done in C then we would have _very_ happily done it that way. See: http://www.mozilla.org/scriptable/xptcall-faq.html Shaver is still the man for xptcall on 'nix porting issues (until he says otherwise). I'm also cc'ing mcafee and rogerl because I think this may have come up before and I have no idea what the resolution was.
Assignee: jband → shaver
Better summary. We probably just need some makefile magic to pull in the assembly for this compiler case. I think egcs intel build is working.?
Summary: Solaris X86 using sun compiler cant make mozilla. → Solaris/Intel/WS5.0: missing xptcinvoke_asm_x86_soalris.s
Status: UNCONFIRMED → NEW
Ever confirmed: true
[richb - 5/4/00] Mozilla (M15 - the one I tried) compiles and runs happily on Solaris Intel 2.6 (the O/S I tried) when built with the Gnu compilers. When you try to compile with Sun Workshop compilers, you will get something like: "xptc_platforms_unixish_x86.h", line 85: Warning: #error "need a platform define if using unixish x86 code". "xptc_platforms_unixish_x86.h", line 91: Warning: #error "need to define 'this' adjust scheme". "xptcinvoke_unixish_x86.cpp", line 121: Error: __asm__ is not defined. "xptcinvoke_unixish_x86.cpp", line 148: Error: Unexpected ":" found. "xptcinvoke_unixish_x86.cpp", line 161: Warning: The variable result has not yet been assigned a value. 2 Error(s) and 3 Warning(s) detected. There are similar errors with the assembly code in xptcstubs_unixish_x86.cpp "__asm__" is a gcc keyword. For Sun's native compilers you should use "asm" keyword instead of "__asm__". gcc manual recommends to check __GNUC__ macro to determine if gcc compiler used: #ifndef __GNUC__ #define __asm__ asm #endif "__volatile__" is also gcc keyword. It means the same as Sun's native compilers "volatile". Files xptcinvoke_unixish_x86.cpp and xptcstubs_unixish_x86.cpp are good examples of using gcc compiler's "extended asm" feature but Sun's compilers do not support it. These two files need to be rewritten so that they will work with either compiler. If common assembler cannot be written, then we will need to do the same Makefile trickery that the SPARC assembly files need for Gnu vs SW 5.0 compilers.
Actually, I think GCC accepts the underscore-less (``asm'' and ``volatile'') variants as well, so that much at least can be shared. I don't know enough about either GCC or SunW assembly syntax to help with developing shared code beyond that, unfortunately.
Status: NEW → ASSIGNED
[richb - 5/4/00] We've got a Russian engineer attempting to build M15 (and the three other libraries that it needs). He hopefully will be able to evaluate how hard this is to fix. As the ways of the lizard are unknown to him at the moment this might take a few more days. I'll update this bug when I have more info.
[richb - 5/12/00] Looks like there is another problem in getting a Solaris Intel version working with Sun Workshop compilers. In .../mozilla/configure.in, at line 887, there is: NS_USE_NATIVE=1 and in .../mozilla/js/src/Makefile.in, at line 153, there is: ifdef NS_USE_NATIVE ASFILES = $(notdir $(wildcard $(srcdir)/*_$(OS_ARCH).s)) endif Unfortunately the assembly code in lock_SunOS.s in that directory is SPARC specific.
Can you report another bug for the js/src problem, so that it can be properly assigned?
[richb - 5/14/00] Mike, just get bug 4575 reopened.
[richb - 5/16/00] I (and the Russian engineer) are not going to have time to work on this again for a while, so I'm going to pass on what we've got. Note that at present, if you compile Mozilla on the Solaris Intel platform with the Gnu compilers, everything works fine. This is an attempt to try to get the Solaris Intel version of Mozilla to work with both the Gnu and Sun native compilers. The previous .tar.gz attachment contains two files: xptcinvoke_unixish_x86.cpp xptcstubs_unixish_x86.cpp If you look at them, you will see that there is an #if 1 around the assembler code. According to the Russian engineer, this version of the assembly code ( as opposed to the previous Gnu specific code which is in the #else part of the #if/#endif statement), "should" work with both compilers (Gnu and Sun). It certainly compiles with both (I was building the M15 milestone). When the version build with Sun Workshop 5.0 compilers is run, here is the output (no existing ~/.mozilla directory): jmqpc1[203] ./mozilla .//run-mozilla.sh ./mozilla-bin MOZILLA_FIVE_HOME=/net/portal/export1/ENG_WORKSPACES/richb/M15-intel/mozilla/dist/bin LD_LIBRARY_PATH=/net/portal/export1/ENG_WORKSPACES/richb/M15-intel/mozilla/dist/bin:/net/portal/export1/ENG_WORKSPACES/richb/M15-intel/dist/lib:/usr/openwin/lib:/usr/motif/lib SHLIB_PATH=/net/portal/export1/ENG_WORKSPACES/richb/M15-intel/mozilla/dist/bin LIBPATH=/net/portal/export1/ENG_WORKSPACES/richb/M15-intel/mozilla/dist/bin MOZ_PROGRAM=./mozilla-bin MOZ_TOOLKIT= moz_debug=0 moz_debugger= Segmentation Fault - core dumped jmqpc1[204] dbx mozilla-bin core Reading mozilla-bin core file header read successfully Reading ld.so.1 Reading libraptorgfx.so Reading libmozjs.so Reading libxpcom.so Reading libjsj.so Reading libplds4.so Reading libplc4.so Reading libnspr4.so Reading libpthread.so.1 Reading libraptorwebwidget.so Reading libdocshell.so Reading libjsdom.so Reading libw.so.1 Reading libposix4.so.1 Reading libintl.so.1 Reading libelf.so.1 Reading libnsl.so.1 Reading libsocket.so.1 Reading libresolv.so.2 Reading libCrun.so.1 Reading libdl.so.1 Reading libm.so.1 Reading libthread.so.1 Reading libc.so.1 Reading libaio.so.1 Reading libmp.so.2 Reading libxpinstall.so detected a multithreaded program t@0 (l@1) terminated by signal SEGV (no mapping at the fault address) Current function is nsServiceManagerImpl::GetService 306 NS_ADDREF(service); // Released in service manager destructor (dbx) where [1] 0xdfbe45fa(0x80631f8), at 0xdfbe45f9 =>[2] nsServiceManagerImpl::GetService(this = 0x80631f8, aClass = STRUCT, aIID = STRUCT, result = 0x80474f4, shutdownListener = (nil)), line 306 in "nsServiceManager.cpp" [3] nsServiceManager::GetService(aClass = STRUCT, aIID = STRUCT, result = 0x80474f4, shutdownListener = (nil)), line 499 in "nsServiceManager.cpp" [4] nsGetServiceByCID::operator()(this = 0x80475b4, aIID = STRUCT, aInstancePtr = 0x80474f4), line 43 in "nsServiceManager.cpp" [5] nsCOMPtr_base::assign_from_helper(this = 0x80475c4, helper = CLASS, iid = STRUCT), line 65 in "nsCOMPtr.cpp" [6] nsCOMPtr<nsISoftwareUpdate>::nsCOMPtr(this = 0x80475c4, helper = CLASS), line 527 in "nsCOMPtr.h" [7] main1(argc = 1, argv = 0x80476f4, splashScreen = (nil)), line 652 in "nsAppRunner.cpp" [8] main(argc = 1, argv = 0x80476f4), line 879 in "nsAppRunner.cpp" (dbx) When I build the M15 milestone with the Gnu compilers, and with these two new files containing the modified assembler code, and then run it, I get: jmqpc1[152] ./mozilla .//run-mozilla.sh ./mozilla-bin MOZILLA_FIVE_HOME=/net/portal/export1/ENG_WORKSPACES/richb/M15-intel-gcc/mozilla/dist/bin LD_LIBRARY_PATH=/net/portal/export1/ENG_WORKSPACES/richb/M15-intel-gcc/mozilla/dist/bin:/net/portal/export1/ENG_WORKSPACES/richb/local-i386/lib:/net/portal/export1/ENG_WORKSPACES/richb/M15-intel-gcc/dist/lib:/usr/openwin/lib:/usr/motif/lib SHLIB_PATH=/net/portal/export1/ENG_WORKSPACES/richb/M15-intel-gcc/mozilla/dist/bin LIBPATH=/net/portal/export1/ENG_WORKSPACES/richb/M15-intel-gcc/mozilla/dist/bin MOZ_PROGRAM=./mozilla-bin MOZ_TOOLKIT= moz_debug=0 moz_debugger= nsNativeComponentLoader: autoregistering begins. *** Registering nsTimeBomb components (all right -- a generic module!) nsNativeComponentLoader: autoregistering succeeded nNCL: registering deferred (0) nsUnixToolkitService: Using 'gtk' for the Widget Toolkit. nsUnixToolkitService: Using 'gtk' for the Gfx Toolkit. NS_SetupRegistry() MOZ_TOOLKIT=gtk, WIDGET_DLL=libwidget_gtk.so, GFX_DLL=libgfx_gtk.so initialized appshell Profile Manager : Profile Wizard and Manager activites : Begin Profile Manager : Command Line Options : Begin DEBUG BUILDS ONLY: we are forcing you to use the profile manager to help smoke test it. Profile Manager : Command Line Options : End GFX: dpi=96 t2p=0.0666667 p2t=15 depth=24 WEBSHELL+ = 1 Segmentation Fault - core dumped Would you believe that I've been unable to find a version of gdb compiled for the Solaris Intel platform (for Solaris 2.6 anyway). There is one more thing to note about the assembly code. The Russian engineer introduce an #ifdef for position independent code (#if POSITION_INDEPENDENT_CODE) which I don't believe exists. If/when this ever works, then this might need to be propagated through the configure.in file. Perhaps someone more knowledgeable in x386 assembler can take this further.
[richb - 5/18/00] I've just found bug 16114 (filed under Windows NT, so I'd missed it), that included yet another set of assembler code that might work for both compilers. Something more to try.
We have a fix for this, but at the moment it's in two hacked up files (xptcstubs_unixish_x86.cpp xptcinvoke_unixish_x86.cpp) that are Sun compiler specific. I need to merge these changes with the existing versions of these files. Probably early next week... All the kudo's should go to Bill Taylor, who works for Sun in L.A. It's nice to know there is now one more person in the world who understands this code. ;-)
I've just attached diffs to xptcinvoke_unixish_x86.cpp and xptcstubs_unixish_x86.cpp that build/run with both the Gnu compiler and the Sun Workshop 5.0 compiler (in optimized mode). I'm being explicit about the compiler status, because I still need to determine if the files will work correctly with debug turned on. I'm going to try this next week. Comments from Bill Taylor (included below) suggest that they might not work with the 5.0 compiler, but will work with 5.1 (aka Workshop 6, aka Forte). "> Would you expect your asm changes to work if Mozilla was compiled with > debug on, or without optimization (ie. no -g and no -O)? My first thought was "sure". After more thinking, I'm not confident. There is one tricky thing about the call to invoke_copy_to_stack(). After it returns, we might have to explicitly set %esp. Since that function is declared static, the generated code need not follow the standard ABI calling conventions. And, it does NOT do so in this case (callee pops args). This could be different with -g, and that could break. The more I think about this, it might be difficult to code set %esp properly if this does vary. This is the only problem I can think of might happen." Note also that Bill dramatically simplified the invoke_count_words() and invoke_copy_to_stack() routines in xptcinvoke_unixish_x86.cpp. I'd appreciate comments on this. It seems to run okay, and the code looks okay, but I wonder why this simplication wasn't in the original code. Same for the switch statement near the end of the PrepareAndDispatch() method in xptcstubs_unixish_x86.cpp
As an experiment, I decided to see what would happen if I compiled up everything with -g. The Gnu version (v2.95.2) works fine, and as expected from Bill Taylor's last comments, the Sun Workshop 5.0 one has problems. It segv's at: t@1 (l@1) signal SEGV (no mapping at the fault address) in (unknown) at 0xdfbe428a 0xdfbe428a: __RTTI__1CpknKnsObserver_+0x066e: imull $0x636e692f,%fs:116(%ebx),%esi Current function is nsServiceManagerImpl::GetService 306 NS_ADDREF(service); // Released in service manager destructor (/usr/dist/share/devpro_i386,v5.0/5.x-i386/bin/dbx) where current thread: t@1 [1] 0xdfbe428a(0x80631f8), at 0xdfbe4289 =>[2] nsServiceManagerImpl::GetService(this = 0x80631f8, aClass = STRUCT, aIID = STRUCT, result = 0x8047444, shutdownListener = (nil)), line 306 in "nsServiceManager.cpp" [3] nsServiceManager::GetService(aClass = STRUCT, aIID = STRUCT, result = 0x8047444, shutdownListener = (nil)), line 499 in "nsServiceManager.cpp" [4] nsGetServiceByCID::operator()(this = 0x8047504, aIID = STRUCT, aInstancePtr = 0x8047444), line 43 in "nsServiceManager.cpp" [5] nsCOMPtr_base::assign_from_helper(this = 0x8047514, helper = CLASS, iid = STRUCT), line 65 in "nsCOMPtr.cpp" [6] nsCOMPtr<nsISoftwareUpdate>::nsCOMPtr(this = 0x8047514, helper = CLASS), line 527 in "nsCOMPtr.h" [7] main1(argc = 1, argv = 0x8047644, splashScreen = (nil)), line 652 in "nsAppRunner.cpp" [8] main(argc = 1, argv = 0x8047644), line 879 in "nsAppRunner.cpp" This was expected, and is due to a compiler bug in the SC5.0 Intel compiler. Here's some comments that Bill sent me earlier in the week: "With Mike Walker's help, we have identified a C++ compiler bug. This code was built with "-g". The first thing to do is try "-O". Also, it may be worth considering the use of newer/better compilers that Workshop 5.0. (Rich is rebuilding with -O now). The first problem we ran into and identfied is in libxpinstall.so. A thunk within it has been called by a function in a different shared object, namely libxpcom.so. The thunk computes the GOT for libxpinstall, then restores ebx with the GOT for libxpcom prior to branching to the PLT. That is the problem." What I now need to do is find out if it's still a problem with -g with the latest version of the compiler (ie SC5.1, Workshop 6, Forte).
Those diffs to xptcinvoke_unixish_x86.cpp and xptcstubs_unixish_x86.cpp work fine with Workshop 6 on Solaris Intel (compiled with -O). I've also successfully build the M16 source tarball on Linux (which also uses these two files). I'm now about to try Workshop 6 on Solaris Intel (compiled with -g). Could somebody review the diffs please? I'd like to see if they can be checked in this week if I can get an r= and an a=. Thanks.
The other part of this problem is the fact that configure.in is setting NS_USE_NATIVE incorrectly for the Solaris Intel platform if the Sun native compiler is being used. NS_USE_NATIVE seems to only be used in .../mozilla/js/src/Makefile.in (and therefore in .../mozilla/js/src/Makefile when it's created). Here's a diff that fixes that problem. stard[305] diff -c configure.in.orig configure.in *** configure.in.orig Tue Jun 20 09:18:05 2000 --- configure.in Tue Jun 20 09:18:36 2000 *************** *** 901,909 **** AR_FLAGS='-o $@' AS='/usr/ccs/bin/as' AS_DASH_C_FLAG='' - NS_USE_NATIVE=1 case $OS_TEST in sun4u) ASFLAGS='-xarch=v8plus -DULTRA_SPARC -P -L -D_ASM -D__STDC__=0 -K PIC' AC_DEFINE(ULTRA_SPARC) ;; --- 901,909 ---- AR_FLAGS='-o $@' AS='/usr/ccs/bin/as' AS_DASH_C_FLAG='' case $OS_TEST in sun4u) + NS_USE_NATIVE=1 ASFLAGS='-xarch=v8plus -DULTRA_SPARC -P -L -D_ASM -D__STDC__=0 -K PIC' AC_DEFINE(ULTRA_SPARC) ;; stard[306] It will now only set NS_USE_NATIVE if we are on the sun4u Solaris platform, (ie. SPARC platform,) and we are not using the Gnu compiler.
I tested the patch on a SunOS 5.8_x86 with Workshop/Forte 6.0; the build works fine.
I now have a set of diffs that work. They apply to four files: .../mozilla/configure.in This change only sets NS_USE_NATIVE=1 if we are using the native compiler on the Solaris SPARC platform, not the Solaris Intel platform. This is used by the Makefile in ...mozilla/js/src/ , to add the assembler file lock_SunOS.s to the build targets. This file is SPARC assembly code so shouldn't be used on the Solaris Intel builds. .../mozilla/xpcom/reflect/xptcall/src/md/unix/Makefile.in This change forces the following two platform specific files to always be built with -O. The assembly code in those files, when used with the Sun native compilers on the Solaris Intel platform, will only work when compiled optimized. .../mozilla/xpcom/reflect/xptcall/src/md/unix/xptcinvoke_unixish_x86.cpp .../mozilla/xpcom/reflect/xptcall/src/md/unix/xptcstubse_unixish_x86.cpp These changes now allow Mozilla to be built and run with both the Gnu compilers and the Sun native compilers on the Solaris Intel platform. #ifdef __GNUC__ clauses have been added to differentiate the two cases. This has been tested with both SC5.0 and SC5.1 (aka Workshop 6, aka Forte) Sun compilers. The patch has also been tested on RedHat Linux 6.1 with the Gnu compilers to make sure Gnu support on other platforms hadn't been broken.
Patch appears to compile fine on FreeBSD 5.0 w/ autoconf 2.14 and gmake 3.79
I've made a small adjustment to the diffs as suggested by cls. It now uses: ifndef GNU_CC OS_CXXFLAGS += -O endif rather than: ifneq ($(CC),gcc) OS_CXXFLAGS += -O endif so that it still works when CC is set using a full path. Thanks cls!
I've just added another attachment with the following refinements suggested by mccabe and brendan: * In xptcinvoke_unixish_x86.cpp, I've added the following XXX: comment block: /* XXX: the following line is here (rather than as the default clause in * the following switch statement) so that the Sun native compiler * will generate the correct assembly code on the Solaris Intel * platform. See the comments in bug #28817 for more details. */ * In xptcinvoke_unixish_x86.cpp, and in xptcstubs_unixish_x86.cpp, the assembler for the Sun compiler is now inside a #else if defined(__SUNPRO_CC) block, and there is also a #else block also with an #error directive. I've retested these changes on Solaris Intel with SC5.0 and on RedHat 6.1 Linux with the Gnu compilers, and they build and run just fine.
Fix checked in; r=mccabe@netscape.com a=brendan@mozilla.org
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
Is that only valid for M15? I'm getting (strange) errors with the tip of the tree: CC -library=iostream -o nsDirectoryIndexStream.o -c -DOSTYPE=\"SunOS5\" -DOJI - I../../../dist/include -I../../../include -KPIC -mt -O -DNDEBUG -DTRIMM ED -DMOZILLA_CLIENT -DBROKEN_QSORT=1 -DNSCAP_DISABLE_DEBUG_PTR_TYPES=1 -DD_INO=d _ino -DMOZ_WIDGET_GTK=1 -DMOZ_DEFAULT_TOOLKIT=\"gtk\" -DSTDC_HEADERS=1 -DHAVE_ST _BLKSIZE=1 -DHAVE_INT16_T=1 -DHAVE_INT32_T=1 -DHAVE_INT64_T=1 -DHAVE_UINT=1 -DHA VE_UINT_T=1 -DHAVE_UINT16_T=1 -DHAVE_DIRENT_H=1 -DHAVE_SYS_BYTEORDER_H=1 -DHAVE_ MEMORY_H=1 -DHAVE_UNISTD_H=1 -DHAVE_SYS_FILIO_H=1 -DHAVE_SYS_IPC_H=1 -DHAVE_SYS_ SHM_H=1 -DHAVE_X11_EXTENSIONS_XSHM_H=1 -DHAVE_SYS_STATVFS_H=1 -DHAVE_SYS_STATFS_ H=1 -DHAVE_SYS_VFS_H=1 -DHAVE_SYS_MOUNT_H=1 -DHAVE_LIBM=1 -DHAVE_LIBDL=1 -DHAVE_ LIBRESOLV=1 -DHAVE_LIBSOCKET=1 -DHAVE_LIBNSL=1 -DHAVE_LIBELF=1 -DHAVE_LIBINTL=1 -DHAVE_LIBPOSIX4=1 -DHAVE_LIBW=1 -D_REENTRANT=1 -DHAVE_RANDOM=1 -DHAVE_QSORT=1 - DHAVE_STRERROR=1 -DHAVE_LCHOWN=1 -DHAVE_FCHMOD=1 -DHAVE_SNPRINTF=1 -DHAVE_LOCALT IME_R=1 -DHAVE_STATVFS=1 -DHAVE_MEMMOVE=1 -DHAVE_USLEEP=1 -DHAVE_GETTIMEOFDAY=1 -DGETTIMEOFDAY_TWO_ARGS=1 -DHAVE_DEV_ZERO=1 -DHAVE_IOS_BINARY=1 -DHAVE_OSTREAM=1 -DHAVE_CPP_EXPLICIT=1 -DHAVE_CPP_SPECIALIZATION=1 -DHAVE_CPP_MODERN_SPECIALIZE_ TEMPLATE_SYNTAX=1 -DHAVE_CPP_PARTIAL_SPECIALIZATION=1 -DHAVE_CPP_ACCESS_CHANGING _USING=1 -DHAVE_CPP_AMBIGUITY_RESOLVING_USING=1 -DHAVE_CPP_NAMESPACE_STD=1 -DHAV E_CPP_UNAMBIGUOUS_STD_NOTEQUAL=1 -DHAVE_CPP_NEW_CASTS=1 -DHAVE_CPP_DYNAMIC_CAST_ TO_VOID_PTR=1 -DNEED_CPP_UNUSED_IMPLEMENTATIONS=1 -DHAVE_I18N_LC_MESSAGES=1 -DMO Z_MAIL_NEWS=1 -DMOZ_ENDER_LITE=1 -DNS_MT_SUPPORTED=1 -DMOZ_USER_DIR=\".mozilla\" -DMOZ_MATHML=1 -DMOZ_DLL_SUFFIX=\".so\" -DXP_UNIX=1 -DUNIX_ASYNC_DNS=1 -DJS_THR EADSAFE=1 -DLAYERS=1 nsDirectoryIndexStream.cpp "", line 116: Error: String/char constants may not include line separator. ** Assertion ** : 0 (/set/taz/builds/fcs0406/intel-S2/lang/cafe/resources/cdr/sr c/c_dataparse.cc: 963) make[4]: *** [nsDirectoryIndexStream.o] Error 195 make[4]: Leaving directory `/home/doehrm/mozilla/netwerk/base/src' make[3]: *** [install] Error 2 make[3]: Leaving directory `/home/doehrm/mozilla/netwerk/base' [doehrm@sun8 ~/mozilla]$ uname -a SunOS sun8 5.8 Generic i86pc i386 i86pc
doehrm, my tests were indeed done against M15 (as you well know ;-). Please file a separate Bugzilla bug for the tip-of-the-tree build problems you are seeing in trying to build the Solaris Intel version with the Sun Workshop compilers. Thanks.
I actually would rather that the switch statement simplifications had not been made. The cases were explicily layed out as much for documentation of all the possible cases to handle and as example for other ports as for any other reason. I doubt that the code size or speed was significantly improved by the change. But this is no big deal.
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: