• Rolf Campbell (13/13) Aug 16 2001 Quote from overview:
• weingart cs.ualberta.ca (Tobias Weingartner) (18/32) Aug 16 2001 This is one problem. However, if you have bitfields, please define the
• Matt Gessner (5/25) Aug 16 2001 Hear, hear! I write embedded systems for a living, and most of the conf...
• Walter (10/31) Aug 16 2001 feature
• Robert W. Cunningham (22/24) Aug 16 2001 Yes, but debugging massive bit twiddling for things like long bit string...

"Rolf Campbell" <rolf.campbell tropicnetworks.com> writes:

Quote from overview:

Features To Drop
-Bit fields of arbitrary size. Bit fields are a complex, inefficient feature
rarely used.

 You mention that you want to have 'D' be able to directly interface with
hardware, "...retains the ability to write high performance code and
interface directly with the operating system APIs and with hardware."

Many types of hardware (and file-formats) make use of bit-fields in their
structures.  While it is always possible to make masks and bit shift stuff
yourself, it is more prone to error than using bit-fields.  I think that
bit-fields are a part of the compiler which many people will implement
themselves if it's not included (kinda like string class in C++).

-Rolf Campbell

weingart cs.ualberta.ca (Tobias Weingartner) writes:

In article <9lgqhk$2clv$1 digitaldaemon.com>, Rolf Campbell wrote:
 Quote from overview:
 
 Features To Drop
 -Bit fields of arbitrary size. Bit fields are a complex, inefficient feature
 rarely used.
 
  You mention that you want to have 'D' be able to directly interface with
 hardware, "...retains the ability to write high performance code and
 interface directly with the operating system APIs and with hardware."

This is one problem.  However, if you have bitfields, please define the
ordering that they will have bits in.  Bitfields are not portable in
C/C++ due to this fact.  All OS software needs to use masks/etc to write
"portable" drivers in C.


 Many types of hardware (and file-formats) make use of bit-fields in their
 structures.  While it is always possible to make masks and bit shift stuff
 yourself, it is more prone to error than using bit-fields.  I think that
 bit-fields are a part of the compiler which many people will implement
 themselves if it's not included (kinda like string class in C++).

This again is very true.  I would recommend having some sort of
bitfield mechanism, along with some mechanism to access memory and
I/O ports.  This could well be implemented in modules (using assembly
language) on each port of the language.  With automatic inlining (and
link-optimization passes), this could be as good, or better than
language support for the various "machine oriented" constructs.

In other words, have a bitfield module, that implements both LE, BE, and
other ordering for bitfields.


-- 
Tobias Weingartner |        Unix Guru, Admin, Systems-Dude
Apt B 7707-110 St. |        http://www.tepid.org/~weingart/
Edmonton, AB       |-------------------------------------------------
Canada, T6G 1G3    | %SYSTEM-F-ANARCHISM, The OS has been overthrown 

Matt Gessner <mattg aiinet.com> writes:

Rolf Campbell wrote:

 Quote from overview:
 
 Features To Drop
 -Bit fields of arbitrary size. Bit fields are a complex, inefficient feature
 rarely used.
 
  You mention that you want to have 'D' be able to directly interface with
 hardware, "...retains the ability to write high performance code and
 interface directly with the operating system APIs and with hardware."
 
 Many types of hardware (and file-formats) make use of bit-fields in their
 structures.  While it is always possible to make masks and bit shift stuff
 yourself, it is more prone to error than using bit-fields.  I think that
 bit-fields are a part of the compiler which many people will implement
 themselves if it's not included (kinda like string class in C++).
 
 -Rolf Campbell
 
 
 

Hear, hear!  I write embedded systems for a living, and most of the
configuration
and status registers are implemented with a bit here and a couple of bits there.

This is an extremely useful language feature in doing embedded systems.

Matt

"Walter" <walter digitalmars.com> writes:

"Matt Gessner" <mattg aiinet.com> wrote in message
news:3B7C19A7.3040203 aiinet.com...
 Rolf Campbell wrote:
 Quote from overview:
 Features To Drop
 -Bit fields of arbitrary size. Bit fields are a complex, inefficient


feature
 rarely used.

  You mention that you want to have 'D' be able to directly interface


with
 hardware, "...retains the ability to write high performance code and
 interface directly with the operating system APIs and with hardware."

 Many types of hardware (and file-formats) make use of bit-fields in


their
 structures.  While it is always possible to make masks and bit shift


stuff
 yourself, it is more prone to error than using bit-fields.  I think that
 bit-fields are a part of the compiler which many people will implement
 themselves if it's not included (kinda like string class in C++).

 -Rolf Campbell

 Hear, hear!  I write embedded systems for a living, and most of the

configuration
 and status registers are implemented with a bit here and a couple of bits

there.
 This is an extremely useful language feature in doing embedded systems.
 Matt

When I've done hardware I/O, I always wound up doing masking and shifting,
because it produced better code.

"Robert W. Cunningham" <rwc_2001 yahoo.com> writes:

Walter wrote:

 When I've done hardware I/O, I always wound up doing masking and shifting,
 because it produced better code.

Yes, but debugging massive bit twiddling for things like long bit strings to
SPI devices quickly becomes a nightmare.  It would truly be beneficial to have
the D "bit" type enhanced for packing into fundamental integer types (and
arrays of same).

One big problem is that the same D code must compile and run on platforms with
different endian-ness!  The same hardware chip (say, an Ethernet controller)
with a mix of 8/16/32-bit registers soon becomes a nightmare, depending on if
the device is accessed by byte, word or dword.  The situation in C often
requires special macros to handle endian-ness, or (worse) a mess of
conditionally compiled code.

Another embedded perspective:  It would be good to define ways of writing D
code that will GUARANTEE the garbage collector will NOT be invoked!  Perhaps a
compiler switch to disable both GC and the language features that rely upon
it.  I'd willing accept a restricted language subset for certain circumstances
(say, device drivers and interrupt handlers) if it will allow me to program an
entire system in a single language.

When using C, I often result to inline assembly ("asm(...)") to handle cases
the language can't handle well.  But this makes the code inherently
non-portable, so I always wind up including the messy C equivalent in a
#ifdef'ed code section ("#ifdef NOASM ...").


-BobC