Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!seismo!rochester!mayer From: mayer@rochester.ARPA (Jim Mayer) Newsgroups: comp.lang.c Subject: Re: bit-field pointers / arrays Message-ID: <23280@rochester.ARPA> Date: Wed, 17-Dec-86 15:15:35 EST Article-I.D.: rocheste.23280 Posted: Wed Dec 17 15:15:35 1986 Date-Received: Thu, 18-Dec-86 03:02:14 EST References: <311@bms-at.UUCP> <534@cartan.Berkeley.EDU> <3796@utcsri.UUCP> Reply-To: mayer@rochester.UUCP (Jim Mayer) Organization: U of Rochester, CS Dept, Rochester, NY Lines: 29 Keywords: why not? In article <3796@utcsri.UUCP> greg@utcsri.UUCP (Gregory Smith) writes: >My question is this: how do you support this through extensions to C? >( I wouldn't expect to port code from a 34010 to anything else). >Writing assembler subtroutines to do the work is obviously a big lose. I wonder if the "pragma" construct could be used for this. In particular, (I don't remember the exact syntax): pragma compiler_function(_foo) would inform the compiler that it was ok to assume a particular definition for the function "_foo". In particular, any invocation of "_foo" could be replaced by inline code using special instructions, etc. A implementation of "_foo" is assumed to be part of a library. If the pragma was not recognized it would be ignored. The pragma would not apply if "_foo" is not known to the compler, or if it is used in a context other than an invocation. This kind of thing does not solve all of Greg's problems, but it does address the problem of getting access to low level machine operations without modifying the C language in non-standard ways. I suspect that between the use of a mechanism like the one above and the bitfield constructs that are already in C one could get a lot of work done. -- -- Jim Mayer Computer Science Department (arpa) mayer@Rochester.EDU University of Rochester (uucp) rochester!mayer Rochester, New York 14627