Thanks to everybody for their comment. My own comment is mere suggestion.
As x86 developer, i'm used to manipulating bits with byte-wise or/and/not/shr/shl operators. (very tricky when doing PDU packing for 7 bit words into 8 bit words for some GSM coding schemes) As far as endian is concerned: Integer types i found always to be little endian in most pascal compilers by default. To do big endian (network byte order) transport for some protocols or file formats, i used the htonl and htons lib functions on the integer fields. I wrote htonl_64 myself for 8 byte width integers. As far as the FPC compiler is concerned, this should not be a concern as it seems the decisions regarding the byte order was made and cemented in place long ago. But now that you guys mention byte order, are there directives in FPC where integer byte orders can be changed? If language syntax might be extended to provide bit width accessibility for MCU's, i think the same methods must be followed throughout FPC: In all technical specifications I have come accross, bit 0 is always the least significant bit of any word regardless the size of the word. That makes things simple. As for the way the syntax will work, I can only suggest sticking with pascal as close as possible. It's a fantastic language. On Thu, Jul 30, 2009 at 10:15 AM, Marco van de Voort <mar...@stack.nl>wrote: > In our previous episode, Desmond Coertzen said: > > No use for OS, just for smaller MCU's that are bit accessible. > > > By application I meant: Is this the correct method to apply a bit-packed > > structure to code? > > Note that there are two kinds of bitaccessibility. > > E.g. microchip follows more the bitpacked way, where all SFR are overlayed > (ABSOLUTE in FPC) with a bitpacked union in the header. > > In addition some mcu's like IIRC 8051 (*) allows to access ANY integer/byte > value to be accessed using .<bitnr> suffix. So if b is of type byte, b.7 > returns the 7th bit. It also had a special type bit to store these and do > some limited arithmetic on them. Probably mapping directly on some bit > sized > registers/flags and instructions. > > (*) iirc we had some Hitachi clone 80515 or so. The compiler was the fairly > wellknown Keile one. > > _______________________________________________ > fpc-devel maillist - fpc-devel@lists.freepascal.org > http://lists.freepascal.org/mailman/listinfo/fpc-devel >
_______________________________________________ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
