On Thursday 28 February 2008 13:09, Michael Schnell wrote:
> > Yes. That's what {$BIT_ORDER} would stand for (still, it would not
> > change *byte* order).
>
> I don't understand this. I don't think the bit order within a byte is
> to be considered changing.
Well, the question is, if the first bit
Yes. That's what {$BIT_ORDER} would stand for (still, it would not
change *byte* order).
I don't understand this. I don't think the bit order within a byte is to
be considered changing.
I would call the issue "byte-order" and (thus I'd prefer something like
{$BIT_PACKED_BYTE_ORDER} or {$B
On Thursday 28 February 2008 12:17, Michael Schnell wrote:
> > Enable_Mode : Enable_Set; // bit 14 .. 15/leftmost bits
>
> With an x86 the "leftmost bits" will be in the "rightmost" (second)
> of the two bytes,
>
> with an 68K the "leftmost bits" will be in the "leftmost" (first) of
> t
Enable_Mode : Enable_Set; // bit 14 .. 15/leftmost bits
With an x86 the "leftmost bits" will be in the "rightmost" (second) of
the two bytes,
with an 68K the "leftmost bits" will be in the "leftmost" (first) of the
two bytes,
So the two can't communicate this record via file
On Thursday 28 February 2008 11:28, Michael Schnell wrote:
> > AFAICS, it would be useful for bitpacked records only, so it could
> > appear anywhere where a {PACKRECORDS} directive or similar can
> > appear currently.
>
> IMHO it would only be useful (allowed with, regarded by) bitpacked
> record,
On 28 Feb 2008, at 11:17, Daniël Mantione wrote:
Op Thu, 28 Feb 2008, schreef Jonas Maebe:
It's not about Linux vs. Windows, it's about FPC 2.2.0 vs FPC
3.4.0, coupled with the fact that bitpacked records as currently
defined are not usable for defining a specific layout.
It compeletely
AFAICS, it would be useful for bitpacked records only, so it could
appear anywhere where a {PACKRECORDS} directive or similar can appear
currently.
IMHO it would only be useful (allowed with, regarded by) bitpacked
record, as any other data representation is supposed to be optimized for
sp
Op Thu, 28 Feb 2008, schreef Jonas Maebe:
On 28 Feb 2008, at 08:19, Daniël Mantione wrote:
As long as the compiler is consistent between platforms, it is okay.
Differences between little/big endian are acceptable because this is the
only situation where we require the coder to manually int
On 28 Feb 2008, at 08:19, Daniël Mantione wrote:
As long as the compiler is consistent between platforms, it is okay.
Differences between little/big endian are acceptable because this is
the only situation where we require the coder to manually intervene
and write two code paths (usually a
On Thursday 28 February 2008 10:01, Michael Schnell wrote:
> > {$BITORDER LOW_ORDER_FIRST}
> > {$BITORDER HIGH_ORDER_FIRST}
>
> Where can this be used ? What exactly does it mean ?
Well, call it proposal (of course, the names are strongly influenced by
personal language preferences).
AFAICS, it
{$BITORDER LOW_ORDER_FIRST}
{$BITORDER HIGH_ORDER_FIRST}
Where can this be used ? What exactly does it mean ?
-Michael
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
On Thursday 28 February 2008 09:51, Micha Nelissen wrote:
> Well we have procedures to do byte swapping, but none to do bit
> swapping. It's also very inefficient AFAIK; while changing the
> compiler's definition of which bit to use is "free".
{$BITORDER LOW_ORDER_FIRST}
{$BITORDER HIGH_ORDER_FIR
Daniël Mantione wrote:
Op Thu, 28 Feb 2008, schreef Micha Nelissen:
Jonas said the bits were swapped, not the bytes. So PPC32 (1 shl 30)
becomes (1 shl 6) on Intel (actual), while it should be (1 shl 1)
(expected use by compiler). It's both the "second bit", bit it's in
different places.
O
The only thing I want to guarantee is that blockwrite followed by
blockread on a platform with the same endianness works and will work
in the future.
This (combined with ifdef based endian conversion) guarantees
portability of structures to any platform.
Or do I see this wrong?
IMHO, I
Op Thu, 28 Feb 2008, schreef Micha Nelissen:
Daniël Mantione wrote:
To my knowledge there is no problem with the current implementation. Endian
conversion is already the reponsibility of the programmer. Therefore I
don't see a need for changes on the compiler side.
Jonas said the bits were
To my knowledge there is no problem with the current implementation.
Endian conversion is already the reponsibility of the programmer.
Therefore I don't see a need for changes on the compiler side.
It might be possible do define the individual bytes of a certain value
in a bitpacked record to
Op Thu, 28 Feb 2008, schreef Michael Schnell:
To my knowledge there is no problem with the current implementation. Endian
conversion is already the reponsibility of the programmer. Therefore I
don't see a need for changes on the compiler side.
I don't understand your meaning here.
If a
The compiler can only care about processor endianness. Having a known
binary structure is something different as being usable for hardware
access.
Right. AFAIK, even C does not do this in a language construct. But FP
might be better than standard :) .
-Michael
___
Daniël Mantione wrote:
To my knowledge there is no problem with the current implementation.
Endian conversion is already the reponsibility of the programmer.
Therefore I don't see a need for changes on the compiler side.
Jonas said the bits were swapped, not the bytes. So PPC32 (1 shl 30)
bec
Op Thu, 28 Feb 2008, schreef Michael Schnell:
C-style bitpacking ("char c:1" and "int c:1" are often laid out differently
in C depending on the previous fields,
Not only this. C defines the layout as implementation depended. I once was
bitten by this when porting a networked project from a
To my knowledge there is no problem with the current implementation.
Endian conversion is already the reponsibility of the programmer.
Therefore I don't see a need for changes on the compiler side.
I don't understand your meaning here.
If a record with binary fields is defined and transferr
C-style bitpacking ("char c:1" and "int c:1" are often laid out
differently in C depending on the previous fields,
Not only this. C defines the layout as implementation depended. I once
was bitten by this when porting a networked project from a low endian
processor to a high endian processor :
Op Thu, 28 Feb 2008, schreef Michael Schnell:
Bitpacked records are simply not fit for defining a particular layout
Thus maybe an additional option (supposedly three choices: "compiler
endianess" (default = not binary portable = behavior as it is now), "low
endian", and "high endian") coul
Op Thu, 28 Feb 2008, schreef Michael Schnell:
Of course the compiler should be internally consistent. A record written on
i.e. Windows should be readable on i.e. Linux. Only if {$packrecords C}
is used, we pack records according to ABI, as to interface with the OS.
Are any bitpacked struc
Bitpacked records are simply not fit for defining a particular layout
Thus maybe an additional option (supposedly three choices: "compiler
endianess" (default = not binary portable = behavior as it is now), "low
endian", and "high endian") could help.
-Michael
___
Of course the compiler should be internally consistent. A record
written on i.e. Windows should be readable on i.e. Linux. Only if
{$packrecords C}
is used, we pack records according to ABI, as to interface with the OS.
Are any bitpacked structures used in the API of any OS ?
If hardware ac
Op Wed, 27 Feb 2008, schreef Jonas Maebe:
In other words, if there will be ever differences as to target platforms,
this has to happen only under $packrecords C, or an equivalent directive
for bitpacked records.
There is no equivalent directive for bitpacked records, and supporting
C-style
On 27 Feb 2008, at 22:46, Daniël Mantione wrote:
There is no reason why bitpacked records should be any different
from packed records: They should internally consistent. Therefore,
the packing behaviour should be known, documented, and therefore
usable for binary use.
They are already ve
Op Wed, 27 Feb 2008, schreef Jonas Maebe:
As I said it's an opaque construct (so no control or guarantees whatsoever
about the layout) and it was not written with hardware interfacing in mind
(regardless of what other people like to promote it for).
Ok, I'll bite, we have something to discu
On Wednesday 27 February 2008 15:56, Michael Schnell wrote:
> In the Linux source code preprocessor macros are used if data
> structures are accessed that require a certain endianess (usually
> "net"- data that are defined high byte first by TCP/IP).
>
> Here clever tweaking provides that no additi
In the Linux source code preprocessor macros are used if data structures
are accessed that require a certain endianess (usually "net"- data that
are defined high byte first by TCP/IP).
Here clever tweaking provides that no additional code is created if the
byte order already is correct with th
On Wednesday 27 February 2008 14:15, Florian Klaempfl wrote:
> Vinzent Hoefler schrieb:
> > And that's why I'd rather go with Ada's representation clauses. If
> > the hardware platform is unsuitable for the thing I want it to do,
> > it simply doesn't compile. Which is justified, because in 99% of
Vinzent Hoefler schrieb:
> And that's why I'd rather go with Ada's representation clauses. If the
> hardware platform is unsuitable for the thing I want it to do, it
> simply doesn't compile. Which is justified, because in 99% of the times
> such RCs are hardware specific.
I still don't see how
On Wednesday 27 February 2008 13:55, Jonas Maebe wrote:
> And no, I'm not saying it's your fault if something you use breaks in
> a newer release, I'm merely saying it's nobody else's fault in
> particular either (at least not most of the time).
Hey, I wasn't trying to blame anybody here.
I was
On 27 Feb 2008, at 13:55, Vinzent Hoefler wrote:
On Wednesday 27 February 2008 12:21, Daniël Mantione wrote:
I.e. we can
exchange packed records with TP/Delphi, what would be the problem
with bitpacking? If I recall well, Jonas made our bitpacking
compatible with GCC and GNU-Pascal.
Grea
On Wednesday 27 February 2008 12:21, Daniël Mantione wrote:
> Op Wed, 27 Feb 2008, schreef Vinzent Hoefler:
> > Well, TP didn't, and until now I found no real documentation on it
> > (it sure wasn't mentioned in *my* copy of the programmer's manual).
>
> That is correct, but the last version of TP
On 27 Feb 2008, at 13:42, Vinzent Hoefler wrote:
On Wednesday 27 February 2008 12:56, Jonas Maebe wrote:
"bitpacked" was introduced in version 2.2.0 (which is the latest
official release).
See, and that's a problem im production code. The project started at
the
time where 1.0.10 was curr
On Wednesday 27 February 2008 12:56, Jonas Maebe wrote:
> On 27 Feb 2008, at 12:17, Vinzent Hoefler wrote:
>
> > Free Pascal Compiler version 2.0.0 [2005/09/09] for i386
> > Copyright (c) 1993-2005 by Florian Klaempfl
> > Target OS: Linux for i386
> > Compiling test.pas
> > test.pas(6,10) Error: I
On Wednesday 27 February 2008 12:33, Daniël Mantione wrote:
> > Too many Ada-features have crept into Pascal over the years. ;)
>
> You can look at it that way, but Ada wasn't the blueprint for Pascal
> extensions.
Well, in the early days, it was quite the other way around, yes. Ada is
derived (
On 27 Feb 2008, at 12:17, Vinzent Hoefler wrote:
On Wednesday 27 February 2008 11:47, Daniël Mantione wrote:
Then use bitpacked records:
If you'd document them properly?
I don't understand why it's not in the 2.2.0 docs, because the doc
changes were committed to svn on 2007-06-29, which
Op Wed, 27 Feb 2008, schreef Vinzent Hoefler:
On Wednesday 27 February 2008 11:47, Daniël Mantione wrote:
Then use bitpacked records:
If you'd document them properly?
Already done afaik.
So we're on-topic again. You are comparing Pascal and Ada. I look at Ada
as a more strict version o
Op Wed, 27 Feb 2008, schreef Vinzent Hoefler:
Well, TP didn't, and until now I found no real documentation on it (it
sure wasn't mentioned in *my* copy of the programmer's manual).
That is correct, but the last version of TP appeared in 1992. Many Pascal
compilers have supported bitpacking,
On Wednesday 27 February 2008 11:47, Daniël Mantione wrote:
> Then use bitpacked records:
If you'd document them properly?
-- 8< --
type
TX = 1 .. 4;
TY = 0 .. 3;
type
Foo = bitpacked record
A : TX;
B : TY;
end {record};
var
X : Foo;
begin
X.A := 1;
X.B := 2;
On Wednesday 27 February 2008 11:45, Florian Klaempfl wrote:
> Vinzent Hoefler schrieb:
> > On Wednesday 27 February 2008 11:16, Micha Nelissen wrote:
> >> Vinzent Hoefler wrote:
> > If I mean to set the write buffer water mark of the SDRAM
> > controller
> >
> > register, I'd rather write:
> > |SD
Op Wed, 27 Feb 2008, schreef Vinzent Hoefler:
You mean like ADA? Indeed, I agree :P
No, I meant languages which are not able to give me bit level control
over a type and have to circumvent this restriction with either
awkward "macro magic" or even can't do nothing at all.
If I mean to set t
Vinzent Hoefler schrieb:
> On Wednesday 27 February 2008 11:16, Micha Nelissen wrote:
>> Vinzent Hoefler wrote:
>>> On Wednesday 27 February 2008 09:44, Michael Schnell wrote:
You can avoid cryptic language constructs in the main source code.
>>> Or you can avoid cryptic languages altogether.
On Wednesday 27 February 2008 11:16, Micha Nelissen wrote:
> Vinzent Hoefler wrote:
> > On Wednesday 27 February 2008 09:44, Michael Schnell wrote:
> >> You can avoid cryptic language constructs in the main source code.
> >
> > Or you can avoid cryptic languages altogether. :D
>
> You mean like ADA
Vinzent Hoefler wrote:
On Wednesday 27 February 2008 09:44, Michael Schnell wrote:
You can avoid cryptic language constructs in the main source code.
Or you can avoid cryptic languages altogether. :D
You mean like ADA? Indeed, I agree :P
Micha
__
On Wednesday 27 February 2008 09:44, Michael Schnell wrote:
> You can avoid cryptic language constructs in the main source code.
Or you can avoid cryptic languages altogether. :D
> I did not yet use the preprocessor in Pascal but a standard way to
> access memory mapped ports in C is something l
> Op Wed, 27 Feb 2008, schreef Marco van de Voort:
>
> > function ByteIO(var p):puchar; inline;
> >
> > begin
> > result:=puchar(@p);
> > end;
>
> > const port = puchar(_port); // !??!?
> > port^:=$55;
>
> Nope, don't forget that we have a nice arsenal of constructs to do system
> programming,
Op Wed, 27 Feb 2008, schreef Marco van de Voort:
function ByteIO(var p):puchar; inline;
begin
result:=puchar(@p);
end;
const port = puchar(_port); // !??!?
port^:=$55;
Nope, don't forget that we have a nice arsenal of constructs to do system
programming, like the mem array, the port ar
> You can avoid cryptic language constructs in the main source code.
>
> I did not yet use the preprocessor in Pascal but a standard way to
> access memory mapped ports in C is something like this (from the top of
> my head):
>
> #define _port = 0x87
const _port=$87;
> #define ByteIO(p) *(((
You can avoid cryptic language constructs in the main source code.
I did not yet use the preprocessor in Pascal but a standard way to
access memory mapped ports in C is something like this (from the top of
my head):
#define _port = 0x87
#define ByteIO(p) *(((volatile unsigned char)*)(p))
#
> > If Pascal, or another decent language is available, C is *never* the
> > best choice. :-)
> Since with FP it is possible to use a preprocessor this is kind of true,
> as same can be use to cure shortcomings of the language used which might
> be problematic especially in embedded projects.
C
If Pascal, or another decent language is available, C is *never* the
best choice. :-)
Since with FP it is possible to use a preprocessor this is kind of true,
as same can be use to cure shortcomings of the language used which might
be problematic especially in embedded projects.
-Michael
_
Felipe Monteiro de Carvalho ha scritto:
On Mon, Feb 25, 2008 at 10:12 AM, Michael Schnell <[EMAIL PROTECTED]> wrote:
IMHO, nowadays, 8 (and 16) bit processors only make sense for very small
projects. Those are very hardware specific and thus using C here does
make sense.
I have to disagree w
Of course you are right. By small I meant the size of the task the
processor is supposed to do and thus to some extend the estimated effort
needed for programming.
If you plan a device that is to be sold in huge quantities, you select
the cheapest possible processor whatsoever, completely disr
On Mon, Feb 25, 2008 at 10:12 AM, Michael Schnell <[EMAIL PROTECTED]> wrote:
> IMHO, nowadays, 8 (and 16) bit processors only make sense for very small
> projects. Those are very hardware specific and thus using C here does
> make sense.
I have to disagree with this one, depending with what "sma
Jeff Duntemann wrote:
This is very blue-sky,
FPGA processors are used a lot in embedded projects (though of course
usually with programming in C). As well Altera as Xilinx have µCLinux
for their processors (full Linux to come very soon) These are the
"primary" FPGA companies, but there are sev
This is very blue-sky, but it would be an interesting enhancement to
Lazarus to target ARM or Atmel AVR CPUs in the manner of the Processing
language/IDE:
http://en.wikipedia.org/wiki/Processing_%28programming_language%29
It's how you create software for the Arduino boards that are so popular
IMHO, nowadays, 8 (and 16) bit processors only make sense for very small
projects. Those are very hardware specific and thus using C here does
make sense.
OTOH, 32 bit processors have become very cheap and handy. For embedded
projects, IMHO, especially processors that are programmed as "ip-Cor
On 24 Feb 2008, at 12:59, Christian Iversen wrote:
However, the most obvious problem here is that (AFAIK) fpc does not
support arbitrary 8- and 16-bit targets. You need to find an
architecture that fpc supports, so you can compile programs for it.
Florian is working on an AVR port (http://
On Sat, Feb 23, 2008 at 5:07 AM, Andrew Haines <[EMAIL PROTECTED]> wrote:
> Can freepascal be used on small processors that are 8 or 16 bits or does
> it expect that there are at least 32 bits for most things?
FPC only supports 32 and 64bits platforms. I recommend using
commercial Pascal compiler
Andrew Haines wrote:
Can freepascal be used on small processors that are 8 or 16 bits or does
it expect that there are at least 32 bits for most things? I've been
tempted lately to start making little circuits with microcontrollers on
them. I realize that a great deal of the rtl/fcl would not be
Can freepascal be used on small processors that are 8 or 16 bits or does
it expect that there are at least 32 bits for most things? I've been
tempted lately to start making little circuits with microcontrollers on
them. I realize that a great deal of the rtl/fcl would not be used on
these little pr
65 matches
Mail list logo
