[fpc-devel] FPC micro controller

[Desmond Coertzen]

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 <marcov at 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 at lists.freepascal.org
> http://lists.freepascal.org/mailman/listinfo/fpc-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freepascal.org/pipermail/fpc-devel/attachments/20090731/891c248f/attachment.html>