Re: [fpc-devel] Want to remove AVL_Tree from DOM
On Saturday 24 October 2009, Sergei Gorelkin wrote: > I want to remove the avl_tree-related stuff from DOM unit. The > reasons are: If that's a CfV, I vote "yes". Vinzent. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] New feature discussion: for-in loop
On Monday 26 October 2009, Micha Nelissen wrote: > Vinzent Höfler wrote: > > At first, "const function" would tell us that the function does not > > change the object in any way, right? > > What is "the object"? In that case, the list, of course. > Usually there are 2 objects: the list (TList > e.g.) and the object being iterated, e.g. TList.Objects[I]. Those > referenced objects can be volatile, the const-ness only applies to > the TList. Yes, that's what I thought. > Ideally the iterator state and the state of the items > iterated over are separated. (Maybe this is not so with e.g. > TStringList). Suppose, the list items have a property "Owner" and the iterator calls some method that says "Owner.Delete (self);" somewhere. How's the compiler supposed to detect that? In some languages, this problem is circumvented by creating a copy of the list before iterating the set, but I don't think that this is a viable solution for Pascal (or any compiled language, for that matter). Vinzent. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] class abstract, class sealed implementation. please review.
On Saturday 17 October 2009, Florian Klaempfl wrote: > Vinzent Höfler schrieb: > > Florian Klaempfl : > >> From a compiler developers point of view, it makes optimization > >> easier under certain cases (e.g. virtual method calls). It's the > >> same as with inline: inline has no advantage except that it is a > >> hint to the compiler how the code can be optimized. > > > > I really doubt that "sealed" is just meant as hint to the compiler > > that the VMT remains static or something. > > It might be more but at least from compiler developer's point of view > it can be used for this. Well, yes. And from the programmer's PoV "inline" can be used as a restriction to prevent pointers to such functions. ;) Vinzent. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Patch, font rendering on Arm-Linux devices.
Are enumeration types 1 or 4 bytes in Delphi? If they are one byte, it looks quite different (and I'm not sure about all the types used here, some seem to be sets, some enumerations). But at the first glance it seems, they used both packed records to either ensure minimum size or known record layout (maybe they even used the structure in some assembly module?), and also aligned them manually to avoid unaligned access issues. Vinzent. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Freepascal in microcontrollers
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 in a record is the leftmost or
the rightmost bit.
It's a matter of interpretation. But as Jonas pointed out, the order of
the bits may change depending on the endianess (assuming I didn't
misunderstand him).
> I would call the issue "byte-order" and (thus I'd prefer something
> like {$BIT_PACKED_BYTE_ORDER} or {$BIT_PACKED_ENDIAN}.
It's not byte order.
If I declare:
|bitpacked record
| X : Byte;
| Y : Byte;
|end record;
X will still be at the lowest address and Y will be at @X + 1. The issue
arises when I say:
|bitpacked record
| X : Boolean;
| Y : Boolean;
| Z : Two_Bit_Enum;
|end;
Assuming, bit 0 is the LSB, does the compiler access bit 0 and 1 (low
order first) for X and Y or does it choose bit 7 and 6 (high order
first) then? And how would it interprete a specific value for Z? At
least two interpretations are possible:
X:7, Y:6, Z[5:4] or X:0, Y:1, Z[3:2]
ASCII graphic:
|X|Y|Z|Z|-|-|-|-|
|-|-|-|-|Z|Z|Y|X|
Ok, I guess, the issue with the enum is none, because the LSB is still
at the right place on the data bus, no matter how you look at it. So
forget that. ;)
Of course, there are more nasty things like
|bitpacked record
| X : Boolean;
| Y : Byte;
|end;
where a single value would cross the byte boundary... *headscratch* I
guess, there's a reason, why endianess issues are not automatically
handled by the compiler. :D
Vinzent.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Freepascal in microcontrollers
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
> the two bytes,
Yes, bad example, because we already crossed the byte boundary. The real
question about leftmost and rightmost was on which "data line" each bit
would appear.
(Usually it's called most significant bit, but as we're talking about
hardware bits, not numbers, I wouldn't use that term. In this context,
no bit is necessarily more significant than the other.)
> So the two can't communicate this record via files or via network.
>
> If you want to have them understand each other, you need to define
> the edianess of the record independently of that of the processor.
Yes. That's what {$BIT_ORDER} would stand for (still, it would not
change *byte* order).
> Enumerated types don't help here.
They weren't meant to solve the issue, they were meant to help to
understand the issue I was trying to point out.
The question was, how to interpret the enumeration values, if their bit
order could/would differ from that of the record they're in.
Should they be put in as is or swapped accordingly?
Vinzent.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Freepascal in microcontrollers
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, as any other data representation is supposed to be optimized
> for speed according to the processor architecture.
Hmm, not necessarily. I frequently use enumeration types to express the
meaning of a set of hardware bits. So thinking about it, what if I'd
use enumerations in a bitpacked record? Maybe like this:
-- 8< --
type
// 2 bits.
Enable_Set = (Dont_Care := 0, // 00
Disable := 1, // 01
Enable:= 3); // 11
type
Control =
bitpacked record
Continuous_Mode : Boolean;// bit 0/rightmost bit
Alternate_Compare : Boolean;// bit 1
...
Enable_Mode : Enable_Set; // bit 14 .. 15/leftmost bits
end;
-- 8< --
I don't know if FPC can pack enumerations into a bitpacked record at
all, but if it does, it might consider the bit order here, too.
Consider something like:
-- 8< --
var
My_Set: Enable_Set;
My_Record : Control;
My_Set := My_Record.Enable_Mode;
-- 8< --
How should the assignment be handled if the bit order for that bitpacked
record is changed?
Vinzent.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Patch, font rendering on Arm-Linux devices.
On Thursday 28 February 2008 11:25, Daniël Mantione wrote: > Op Thu, 28 Feb 2008, schreef Vinzent Hoefler: > > On Thursday 28 February 2008 09:16, Daniël Mantione wrote: > >> Memory access. What happens is that the non-packed version causes > >> more cache misses. > > OMG. I'm s confused. ;) I read "that the packed version causes more cache misses" here. That was the part where I didn't understand why. > > Please elaborate. If the (unaligned) data is crossing a cache-line, > > thus causing two full cache-line reads, I'd understand that, but > > once it's in the cache, it wouldn't matter anymore? > > Yes, but if you have an array of them (as we have in this case), > considerably more of these records will fit in the cache. Yes, that's what I figured, so I'm on the same path as you here, it seems, but tracing back the discussion it read: -- 8< -- > I'd like to understand more this issue. > Why are non packed records faster? Cache trashing. One of the most underestimated performance killers in modern software. > The difference occurs at memory allocation or at memory access? Memory access. What happens is that the non-packed version causes more cache misses. -- 8< -- The first part tells me non-packed records are faster, but the second line tells me that the non-packed version also causes more cache misses, thus is slower. That got me confused, I think. Of course, the net result only depends on the benchmark you're using. ;) Vinzent. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Freepascal in microcontrollers
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 would be useful for bitpacked records only, so it could
appear anywhere where a {PACKRECORDS} directive or similar can appear
currently.
Vinzent.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Freepascal in microcontrollers
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_FIRST}
?
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Patch, font rendering on Arm-Linux devices.
On Thursday 28 February 2008 09:16, Daniël Mantione wrote: > Memory access. What happens is that the non-packed version causes > more cache misses. Please elaborate. If the (unaligned) data is crossing a cache-line, thus causing two full cache-line reads, I'd understand that, but once it's in the cache, it wouldn't matter anymore? IOW: How can a packed (thus smaller) record cause more cache misses than a better aligned (but bigger) one? That it can in certain circumstances, I'd understand, but as a general rule? Vinzent. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Patch, font rendering on Arm-Linux devices.
On Tuesday 26 February 2008 17:27, Luiz Americo Pereira Camara wrote: > Yury Sidorov wrote: > > The patch removes packed record for some platforms. > > IMO packed can be removed for all platforms. It will gain some > > speed. > > I'd like to understand more this issue. > Why are non packed records faster? > The difference occurs at memory allocation or at memory access? At memory access. On x86 processors it's usually only a speed penalty (or has anyone ever seen the AC flag turned on?), on other processors you may even have to workaround exceptions (i.e. bus errors), because the processor simply refuses to read or write unaligned data. And then the only way to circumvent the processor's refusal is to read/write the data byte by byte or mask it out, which is slower than just reading or writing it. Consider writing a 16-bit value spanning across 32-bit-values where the processor can only access a single 32 bits value at an aligned address: *_ _ _ _*_ _ _ _ |0|1|2|3|4|5|6|7| |___| Now the data you need is spanning across bytes [2:5], but the processor can only read full 32 bits either at position 0 (reading bytes [0:3]), or position 4 (reading byte [4:7]). You'd need to read both processor words, mask the data in the lower and upper half of each and write back both words with the new data patched "inbetween" them. So by now, no matter if the processor handles it for you or if the compiler would insert the necessary code to do it, even a simple increment is insanely expensive in terms of processor cycles. Vinzent. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Freepascal in microcontrollers
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 additional code is created if > the byte order already is correct with the processor the code is > compiled for. As pointed out, this is possible without a preprocessor. Not in C, though. Vinzent. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Freepascal in microcontrollers
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 > > the times such RCs are hardware specific. > > I still don't see how ada could handle things like little endian cpus > accessing big endian peripherial with bit patterns overlapping byte > borders (no, this is not an academic case, just look at the brain > dead arm fpa). Well, I'm not sure what you want here, let me try: |type Data is ... | |for Data'Bit_Order use High_Order_First; |for Data use | record | Byte_3 at 0 range 0 .. 7; | Byte_2 at 1 range 0 .. 7; | Byte_1 at 2 range 0 .. 7; | Byte_0 at 3 range 0 .. 7; | end record; Don't get it wrong. An Ada compiler does *not* automatically flip bytes for you, so if you really have some type spanning byte boundaries in the wrong endianess, you still have to flip it accordingly. IOW: |type Data is: | |for Data'Bit_Order use High_Order_First; |for Data use | record | Word_1 at 0 range 0 .. 15; | Word_0 at 2 range 0 .. 15; ... does not work as one might expect. The bytes would still be flipped on a little endian machine. But at least it is possible to define a record representation totally endianess independent. It's a bit more complex than necessary, so it's probably better to read the whole stuff (although it might require some Ada experience to really see it through) http://www.sigada.org/ada_letters/sept2005/Endian-Independent%20Paper.pdf instead of letting me give you an example. After all, for embedded programming the guarantees I get from Ada record representation clauses is usually enough to know it'll work. Vinzent. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Freepascal in microcontrollers
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 merely reasoning why I can't use the latest bleeding edge compiler. ;) > > And let me guess: There's no way to specify how the Endianess of > > the bitpacked type should be interpreted regardless of the target > > system? > > 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). So, basically it is not useful in the context I was mentioning (JFTR: neither do the similar C99 constructs). Things like memory controller register fall into the hardware category, I suppose. ;) Vinzent. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Freepascal in microcontrollers
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 appeared in 1992. Many > Pascal compilers have supported bitpacking, since 2.2 we do too. Well, the first version of the software I am maintaining appeared around 1992, too. There still were IFDEFs for TP4 in it. > > If it's > > similar to C-records then it's unusable anyway, as there are no > > guarantees. Not about endianess, not about padding. > > This is simply a matter of documenting and standardizing. For me it's a matter of the hardware. > 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. Great. And surely the PCI-board registers are compatible with GCC (oh, and if so, which compiler version then?). > > And what about volatile and/or atomic semantics? > > Pascal does not have volatile. It is not strictly needed either since > the use of mem or absolute should provide sufficient information to > the compiler it cannot optimize away reads/writes. No. Global variables in threading context are just as volatile as any memory-mapped hardware might be. And how should the compiler know that a given pointer actually points to a memory-mapped hardware register if you can't tell it? Sure, so far I did not have problems with such (I don't use too many global variables, the embedded hardware is programmed in another language anyway, and I only (mis)use types as atomic, if I can sufficiently guarantee that in most circumstances the access will be atomic indeed). Vinzent. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Freepascal in microcontrollers
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: Identifier not found "bitpacked" > > "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 current (and a couple of months later I used the 1.9.6 release candidate), but due to several show-stoppers (thread leaks, random XML parser crashes) I'm currently stuck to version 2.0.0. Of course, I tried version 2.2.0 shortly after its release, but then the project didn't even compile anymore. Ok, my fixed up version of the tread manager implementation was expected to break, but that suddenly subroutines were moved to other units wasn't something I expected. (Yes, the Interlocked stuff is now in System where before it was in SysUtils - which generally is a good thing; when using such code, chances are high, you don't even want to pull in SysUtils - , but still it breaks my code). And there may have been other issues, I don't remember. Of course, some day soon I'll probably do a branch to migrate to 2.2.0, but until then, sorry, "bitpacked" or not, documented or not, I can't use it, because it doesn't exist in the current setup. > That said, bitpacking is unsuited for hardware interfacing because it > is opaque: 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. > The bit layout is also different on little and big endian systems. And let me guess: There's no way to specify how the Endianess of the bitpacked type should be interpreted regardless of the target system? Vinzent. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Freepascal in microcontrollers
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 (mostly) from Pascal. And other languages had their influences (and others later were influenced), too. Even computer languages have their Babel tower. > Some come from C, some from Modula-2, some from Visual > Basic. Bitpacking can be considered a "real" Pascal extension, early > compilers in the eighties could already do it. Well, Ada's representation clauses also were known in 1983 already. And that was after the standardization procedure was through, so they surely appeared in the earlier 1979 drafts already. (And no objection please, but representation clauses are quite a bit more than just bitpacking.) But as most features of Ada those probably appeared somewhere else before, I guess. But for sure, such types (do they really call it "record" there or is that just my imagination?) appeared in C not before 1999. Together with other brain dead design decision, this makes (or at least "made") C about the worst choice for embedded, low level programming - and yet, it is the most successful. Vinzent. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Freepascal in microcontrollers
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;
WriteLn (X.A);
WriteLn (X.B);
WriteLn (SizeOf (X));
end.
-- 8< --
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: Identifier not found "bitpacked"
> type TSDRAM_Buffer_Control=bitpacked record
> {...}
>end;
>
> var SDRAM_Buffer_Control:TSDRAM_Buffer_Control absolute [$xx];
>
> begin
>{...}
>SDRAM_Buffer_Control.WB_Watermark := Sixteen;
>{...}
>
> Just like Micha I'm not impressed about the Ada code,
It wasn't meant to impress anybody. It was meant to show that there's no
preprocessor needed.
> and it is off-topic, this is and remains a Pascal newsgroup.
Oh, I thought of it as a mailing list. ;)
> Comparisons
> between Pascal and other languages are on-topic, comparisons between
> C and Ada are off-topic.
So we're on-topic again. You are comparing Pascal and Ada. I look at Ada
as a more strict version of Pascal, is all. Too many Ada-features have
crept into Pascal over the years. ;)
Vinzent.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Freepascal in microcontrollers
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: > > |SDRAM_Buffer_Control.WB_Watermark := Sixteen; > > > > instead of > > > > |SDRAMBufferControl := (SDRAMBufferControl and not > > | WB_WATERMARK_MASK) or WB_WATER_MARK_16; > > I don't see the point: pascal and also fpc know bitpacked records? 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). If it's similar to C-records then it's unusable anyway, as there are no guarantees. Not about endianess, not about padding. And what about volatile and/or atomic semantics? Well, too many question at once. I boil it down to this one: How else do you write it? The original layout declaration: | for SDRAM_Buffer_Control use | record | WB at 0 range 0 .. 0; | WB_Flush at 0 range 1 .. 1; | WB_Watermark at 0 range 2 .. 3; | Read_Ahead at 0 range 4 .. 4; | -- bits [5:7] are reserved | end record; It get's especially tricky, because in many cases the bit patterns don't fit the numbers: | type RAS_CAS_Delay is range 2 .. 4; | for RAS_CAS_Delay'Size use 2; or | type CAS_Latency is range 2 .. 3; | for CAS_Latency'Size use 1; I don't really want to write |SDRAM_Timing_Control.CAS_Latency := 1; // Where 0 is 2 and 1 is 3. Well, not that big a problem, because once the patterns get nonconsecutive, you'd need enums either way. ;) Vinzent. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Freepascal in microcontrollers
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? 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 the write buffer water mark of the SDRAM controller register, I'd rather write: |SDRAM_Buffer_Control.WB_Watermark := Sixteen; instead of |SDRAMBufferControl := (SDRAMBufferControl and not WB_WATERMARK_MASK) or | WB_WATER_MARK_16; Not even to think of the much more cryptic C version. Vinzent. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Freepascal in microcontrollers
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 like this (from the top > of my head): > > > #define _port = 0x87 > > #define ByteIO(p) *(((volatile unsigned char)*)(p)) > > #define port=ByteIO(_port) -- 8< -- snip -- with Interfaces; with System.Storage_Elements; procedure Foo is -- -- Declare a reusable volatile 8 bit IO port type. -- type IO_Port is new Integer range 0 .. 255; for IO_Port'Size use 8;-- 8 bits, of course. pragma Atomic (IO_Port); -- Sort of superfluous here. pragma Volatile (IO_Port); -- Make address conversions directly visible, -- but only inside "Foo" here. use System.Storage_Elements; -- Now declare a (volatile) IO port variable, -- and tell its address. My_Port : IO_Port; for My_Port'Address use To_Address (16#87#); begin -- Assign the 0x55 value to the 0x87 address. My_Port := 2#01010101#; end Foo; -- 8< -- snip -- Although it's a whole lot of declarations for this simple: -- 8< -- _ada_foo: .LFB3: movb$85, 135 ret .LFE3: -- 8< -- So, given the right choices, neither C, nor a preprocessor is needed. And hell, preprocessors sometimes are even forbidden for a particular project. If you want to verify code you need the code which turns up after being preprocessed anyway. Vinzent. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] New download location for the ebook--sorry for the messup!
On Wednesday 20 February 2008 17:01, Jeff Duntemann wrote: > Good luck and thanks for the reports. I'll have to look into why Lulu > downloads don't work. Well, JFTR, the download at the original site worked for me just like any other. No problems. And for the content: It was a pleasure reading it. :) Vinzent. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Light weight threads for FPC
On Friday 14 December 2007 11:46, Mattias Gaertner wrote: > For many parallel algorithms you don't > need events, priority or synchronize. But you need to easily and fast > start a set of threads with IDs 0..N. Ok, so you're mostly caring about the thread creation overhead, it seems. So yes, here I'd go with Florians thread pools advice. And no, it's not implemented yet, AFAIK. You still can implement such thread pools on top of OpenMP(I) (or similar APIs), if you need to get much lighter. ;) Vinzent. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Light weight threads for FPC
On Friday 14 December 2007 10:20, Florian Klaempfl wrote:
> I think some thread pool class is more important, it would be
> basically the same as above
>
> for i := 0 to 3 do
> Handle[i] := TTask(ThreadPool.QueueTask(Func {tThreadFunc},
> @FuncArg[i]));
>
> for i := 0 to 3 do
> Result[i] := WaitForTask(Handle[i], 0);
Yes, that would be something nice and useful, indeed.
Vinzent.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Light weight threads for FPC
On Friday 14 December 2007 09:37, Felipe Monteiro de Carvalho wrote: > On Dec 13, 2007 7:55 PM, Mattias Gaertner <[EMAIL PROTECTED]> wrote: > > Has someone already created a unit for light weight threads? > > I don't know much on the subject, but Is TThread heavy? What are the > disadvantages of using it? No, TThread is either heavy or middle-weight, according to the definitions at http://whatis.techtarget.com/definition/0,,sid9_gci814910,00.html depending on the actual implementation. On Linux 2.4 it would be heavyweight, on Win32 systems and Linux kernel 2.6+ it would be middle-weight. (Well, the context switching times mentioned there are not really up to date, usually not even context switching between processes takes several milliseconds, or "thousands of microseconds" as they liked to say.) But actually, I don't know how much more "light" a thread can take: "When all context and thread operations are exposed at the user level, each application needs only the minimal amount of context saved with it, so that context switching can be reduced to tens of microseconds. Therefore, user-level threads are considered lightweight threads." Which is something that you simply never want to do outside of bare-metal embedded systems. And even there you'd normally wrap your threading implementation in something more "middle-weight" before you expose that API to the user. Vinzent. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Light weight threads for FPC
On Thursday 13 December 2007 19:55, Mattias Gaertner wrote:
> Has someone already created a unit for light weight threads?
>
> Something like: Create a group of 4 threads named 0,1,2,3 and execute
> a procedure/method?
for i := 0 to 3 do
Handle[i] := tThreadId(BeginThread (Func {tThreadFunc},
@FuncArg[i]));
for i := 0 to 3 do
Result[i] := WaitForThreadTerminate (Handle[i], 0);
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] weird syntax
On Tuesday 11 December 2007 10:04, Michael Schnell wrote:
> Andrew Haines wrote:
> > Hi,
> >
> >
> > Is it possible to make this work:
> >
> > if X > 3 or < 10 then ...
> >
> > of course it would be shorthand for: if (X>3) or (X<10) then
>
> The "or" operator is stronger than the "<" operator by definition.
> This can't be changed.
Neither needs to be. There is no operand, but two operators ("or <") in
the second expression, so you wouldn't even be able to apply precedence
rules.
Vinzent.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Parallel Computing
On Monday 10 December 2007 12:54, Michael Schnell wrote: > IMHO the "parallel" idea is hard to implement, as the compiler needs > to heavily support it. Nonetheless, this was what this wiki page was about: Proposals for parallel *language* constructs (especially WRT to the C-centric OMP spec). BTW, I didn't have time to look at your proposal, but once I got "procedure of thread" you're quoting here, I'd expect the language to take care of (most) synchronization issues, much like the "protected object" in the Ada language does. Vinzent. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Parallel Computing
On Monday 03 December 2007 09:20, Graeme Geldenhuys wrote: > On 03/12/2007, Marco van de Voort <[EMAIL PROTECTED]> wrote: > > That is an open door that has been kicked in by all vendors. The > > problem is > > I kind-of understand that... Borland tried to encapsulate the whole > threading thing in a TThread class. Yeah, right. And back in 1983, Ada already tried to encapsulate that in a task object. If any of the FPC developers had time to implement something more nifty, there would have been plenty of time to come up with something. Quite a while ago there were even some ideas shared for the OMP API etc. pp. I can't imagine that Microsoft's ideas of adding multi processing to dot-net will change the overall picture. Especially not when I think of all the parallel language( construct)s invented in the past 30 years to accomplish just that. Vinzent. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] SysUtils exception translation issues
Hi all, after we had that quite heated discussion in core, I decided to take matters into my own hand and come up with some useful proposal. But now I am looking at fpc2.2.0 sources for SysUtils and feel quite desperate. The thing is that I don't know if those are actual bugs, design decisions, or Delphi compatibility issues: 1) Strangely, runtime error 1 (invalid function number) is translated to EOutOfMemory. 2) Translation to I/O errors: there's a string set for RTE15, although it's not even handled by the case statement, as well as RTE 16 to 18, and 104, which are not handled neither. 3) Most DOS-specific errors are not handled at all (see RTE150 - 162). 4) RTE 202 (Stack check error), and RTE210 (object not initialized) are not handled. 5) RTE206 is translated to EOverflow, although there is an EUnderflow exception type. 6) RTE212 (stream registration error) is translated to an EExternal exception, although EExternal should probably not be raised on its own, but rather provide as base class for real "external" error situations. 7) RTE213 again is not handled, while RTE214 (collection overflow error) suddenly becomes an EBusError. 8) Why is RTE217 (unhandled exception) translated to EControlC? 9) RTE220 - 225 are not documented as Variant errors. For me it looks as if the runtime error to exception translation is more or less screwed anyway. Vinzent. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] property syntax extension
On Thursday 18 October 2007 12:55, Michael Schnell wrote: > > I think it is better to send a RTF document than a ODT document: > > * it is smaller > > * more programs can read it > > * no need to download and install plug-ins for a seizable minority > > of people without open office or ODT-plug-in installed. > > Valid considerations, but regarding this, PDF is a much better > option. (BTW.: Open Office does write PDF without any plugins or > external programs.) Oh, come on. An OpenOffice created PDF would have had about 30K+ size after base64 encode. :P And that for data which could most easily have been provided as plain text inside the mail: -- 8< -- PropertyDeclaration ::= PROPERTY Identifier [PropertyInterface] [PropertySpecifiers] [Directives] PropertySpecifiers ::= [ ... ] [ ... ] [ATTRIBUTES AttributesArray] AttributesArray ::= '[' (AttributeDeclaration [, AttributeDeclaration]) ']' AttributeDeclaration ::= ':' Declaration examples: TmenuItem = class(...) ... property Detachable: Boolean read FDetachable write SetDetachable attributes ['widgetsets:qt,gtk,win32', 'implementor:Vasya Pupkin', 'creation-date:01.01.2007']; ... end; TxxxDatabase = class(...) ... property TransactionModel: TTransactionModel read FtransactionModel write SetTransactionModel attributes ['engines:firebird,oracle,sybase-asa']; ... end; -- 8< -- Of course, the syntax highlighting is now missing but as the intended target audience are the developers and not managers, the missing blue won't lose you information, I'd say. Vin"How big is that whole mail now?"zent. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] sdlgraph, pre-alpha
On Wednesday 22 August 2007 19:18, Micha Nelissen wrote: > Michael Van Canneyt wrote: > >> Why is calling via a procvar very much slower than a normal call ? > >> It's just an extra memory fetch (hopefully in cache) ? > > > > Jonas meant that each pixel is drawn separately. The procvar is not > > the issue. > > Before me going too far in unknown territory, but isn't that the > basis for any software implemented graphics routine: drawing pixels ? According to Michael Abrash: No, it's not. Linedrawing is more like it. Vinzent. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] win32 debugging broken in fixes_2_2?
On Wednesday 11 July 2007 06:39, Florian Klaempfl wrote: > That's a point though I thought we could safe this extra check > because I didn't expect that a lot of people are still using PII :) Well, if the OS supports SSE and thus no SIGILL is generated, what would be the point in using CPUID to check for SSE *after* that at all? ;) Honestly, I don't think that "extra check" would hurt anyone. Vinzent. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] win32 debugging broken in fixes_2_2?
On Tuesday 10 July 2007 09:58, Vinzent Hoefler wrote: > On Tuesday 10 July 2007 12:40, Yury Sidorov wrote: > > Maybe other way to detect SSE support exists... > > CPUID? To be more precise, the way recommended by Intel: "To make this check, execute the CPUID instruction with an argument of 1 in the EAX register, and check that bit 25 (SSE) and/or bit 26 (SSE2) are set to 1." -- IA32 Software Developer's Manual, Volume 3: System Programming Guide ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] win32 debugging broken in fixes_2_2?
On Tuesday 10 July 2007 12:40, Yury Sidorov wrote: > Maybe other way to detect SSE support exists... CPUID? Vinzent. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] language extensions
On Thursday 14 June 2007 06:42, Florian Klaempfl wrote: > Why do you need a plug in mechanism? You've the sources? When you > have the sources, 90 per cent of the use of a plugin are gone. Well, we'd call that non-intrusive change. ;) You'd just need to compile the plug-in, and not a changed compiler (which then may even apply recursively). This rules out a whole class of possible error sources. So it's probably the last 10% that counts. ;) Which, BTW, fits nicely into another 90/10 rule: 90% of all errors are coming from only 10% of the code. ;) Vinzent. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Issue with Critical sections
On Thursday 05 April 2007 09:16, Sergei Gorelkin wrote: > It appears that my way of thinking has been severely affected by > using IDEs. When putting mouse over identifier shows where it comes > from, prefixing seems redundant :) Prefixing *is* redundant, that's the whole point of it, but it also takes you to the safe side. I never liked Pascal's solution of calling subroutines with the same name depending on the order of the use clauses, when those use clauses are so far away from the actual code. Change the clause, you (may) change the code. Not mentioning this awful "reuse" clause here, that's the worst. But I'm getting carried away... stop. Well, so doing the mouseover to look at where it's from already has a bad taste of suspecting some surprise. And well, an IDE can't help you on the printout. Clicking on the headlines in a newspaper doesn't take you to the article, neither. ;) > VH> I won't judge if FPC is correct here (it's supposed to be > Delphi-, not VH> Kylix-compatible), but if Borland decided to move > those routines, they VH> didn't do it right neither. ;) > > They did not move routines - they just had to implement Linux > versions somehow. And they did it in a way that was not breaking > existing code. So they should have implemented the "Windows" unit, simple as that. Or add a "Linux" unit as replacement. > In this particular case I wanted to avoid FCL dependence via using > SyncObjs. Fair enough. It's a reason after all. Vinzent. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Issue with Critical sections
On Wednesday 04 April 2007 15:29, Sergei Gorelkin wrote:
> That is exactly what I'm speaking about. Removing 'Windows' from
> uses clause is essentially stopping using it :) And if the code
> continues to compile and work after that, it is just fine.
Sorry, I always forget that most people are not like me and just use
subroutine names without caring where they come from, while I'm used to
always prefix the unit names to the subroutines and thus simply
removing "Windows" from the use clause would not work, because the
routines suddenly come from a different place.
Well, my opinion and my experience say you should know which routines
you are actually using. I know that since the days I used DisposeStr
and the FPC compiled code horribly crashed, because it was the wrong
one.
> The code I was compiling was already cross-platform (Delphi/Kylix),
> and 'uses Windows' was wrapped by {$IFDEF MSWINDOWS}. In Kylix,
> InitializeCriticalSection and DeleteCriticalSection are implemented
> in SysUtils unit, so any code using these functions continue to work
> under Linux. It was surprise for me that this code could not compile
> with FPC.
I won't judge if FPC is correct here (it's supposed to be Delphi-, not
Kylix-compatible), but if Borland decided to move those routines, they
didn't do it right neither. ;)
Well, I'd still suggest to either stick to "System.InitCriticalSection"
etc. regardless if the Windows unit is included or not (yes, this
actually *requires* you to prefix it), or just use the SyncObjs unit
like everyone else out there.
Vinzent.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Issue with Critical sections
On Wednesday 04 April 2007 13:13, Micha Nelissen wrote: > Sergei Gorelkin wrote: > > > But EnterCriticalSection/LeaveCriticalSection also exist in Windows > > API. And they are implemented in System unit without changing > > names. Therefore, to > > They shouldn't be exposed publicly in the system unit. Why's that? At least it's documented that way. And I don't see any harm in doing so. Vinzent. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Issue with Critical sections
On Wednesday 04 April 2007 12:59, Sergei Gorelkin wrote: > But EnterCriticalSection/LeaveCriticalSection also exist in Windows > API. And they are implemented in System unit without changing names. > Therefore, to make my code cross-platform, I have only to remove > Windows from uses clause - then cross-platform versions from System > unit will be used. This is fine. No. If you want to be cross-platform just do not use the "Windows" unit at all. Rather only use the functionality provided by the system unit, regardless of the compilation target. The "Windows" unit should generally only included if you write platform specific code and such code should be separated in its own include file or even unit anyway. Vinzent. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Issue with Critical sections
On Wednesday 04 April 2007 10:33, Sergei Gorelkin wrote: > I was porting to Linux some Windows code which uses critical > sections API, and got 'Identifier not found' error on > InitializeCriticalSection and DeleteCriticalSection symbols. If I had to guess, I'd say this is probably because those identifiers come from the Windows unit. > After > searching through RTL code, I discovered that abovementioned > functions are named InitCriticalSection and DoneCriticalSection. At > the same time, the EnterCriticalSection and LeaveCriticalSection are > not renamed, so code using them compiles without errors. Why this > inconsistency? Because one is the RTL abstraction on the different OSes, the other one is the direct Windows-API-Call. > Should I supply a patch that adds > Initialize/DeleteCriticalSection as aliases for > Init/DoneCriticalSection? No, I'd suggest to fix your code. Regards, Vinzent. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: Inter Process Communication
On Thursday 01 March 2007 00:11, Jason P Sage wrote:
> I've just performed more tests using the stock simpleipc - and the
> SendMessage and GetMessage - though defined as "STRING" (Which I
> thought had a max length) seems to be able to support huge
> ansistrings.
Well, RTFS:
|unit simpleipc;
|
|{$mode objfpc}{$H+}
|
|interface
There's the {$H+} in it, so String actually is an AnsiString already, no
ShortString anymore.
Vinzent.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] "case" with range stupidities
On Thursday 15 February 2007 14:46, Daniël Mantione wrote: > Op Thu, 15 Feb 2007, schreef Vinzent Hoefler: > Because, in a case statement you are already "inside" the brackets: Yeah, I sort of figured that. ;) > > Another oddity would be a for loop: > > > >for Bla := One to Five do ... > > > > would be a range only, yes? (Apart from the fact that - due to the > > "to" keyword - really isn't). > > It is a range, but one also needs to specify the direction > (to/downto), so it is logical that for-loops don't use .. syntax. Oh, right, I forgot that. Damn. That's why in Ada you can write for Bla in X'Range loop vs. for Bla in reverse X'Range loop for the intended direction of the given range. > > What about a compiler built-in like Low() and High() called Range() > > where its return type indicates something that would be compatible > > to a case and for label and just denote the range of the whole > > type? > > > > Basically a short cut to the "Low (Type) ..|to High (Type)" > > expression, but without the possible pitfall of writing > > > >Low (Type) .. High (A_Similar_And_Unfortunately_Compatible_Type) > > > > and thus being less error-prone...? > > It looks okay, but does this pitfall actually exist? Yes, it does. Especially when copying and pasting. ;) The reason why I stumbled over that was that I changed a case statement from a perfect fit: case Frequency of 1600: Idx = Hz_1600; ... where the returned Idx is an index to an array of hardware parameters to generate that frequency. For some unpublishable reason I changed that from a perfect match (here: 1600) to a range (say: 1500 .. 1700) and I started declaring range types for that because putting in the range into the case label seemed too bad for later changes. So then I ended up writing: case Frequency of Low (Range_1_6_K) .. High (Range_1_6_K) : Idx := ... Low (Range_1_8_K) .. High (Range_1_8_K) : Idx := ... ... for quite some values. Of course you start copy- and pasting things then and I had to triple check if I really matched the Low(...) with the according High(...) parts and the correct value for Idx. > low(colour)..high(wind_direction) would be a type violation. Yes. But integer ranges are compatible in any case and that's what I am bound to here (in fact, the code even "kind of" changes those integers to a type-safe enumeration type for further uses). > > or > > > > |case Bla in > > |Range (X): ... > > > > doesn't actually look unreadable to me... > > Indeed, but do you solve a problem? I.e. I can imagine some kind of > syntax to allow set constants would help, but this seems mostly a > typing shortcut. Well, it is. The above mentioned lines of Ada code can still be expressed as for Bla in [reverse] X'Low .. X'High loop and would still mean the same. And due to the fact that in Pascal such a Range() built-in would still not be useable in a for loop, it seems, its use would be too limited to be considered an improvement. Unless I'd get Reverse_Range(), too. ;) Regards, Vinzent. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] "case" with range stupidities
On Thursday 15 February 2007 13:36, Daniël Mantione wrote:
> Op Thu, 15 Feb 2007, schreef Vinzent Hoefler:
> > Well, fair enough, but why is that I can declare a
> >
> >type
> > Foo = array[byte] of Something;
> >
> > where the type name "byte" also indicates the range? Considering
> > that
> >
> >type
> > Foo = array[Low (byte) .. High (byte) of Something;
> >
> > is totally equivalent, the allowed usage of range types seems a
> > little bit inconsistent...
>
> Yes, but as I said, case labels are a set, not just a range:
>
> const x=[0,1,5];
>
> type foo=array[x] of something
>
> ...would again be rather weird.
It would be, yes. It even seems constants can't be used in an array type
declaration at all (well, not in a way different from defining the
lower and upper bound, I mean) and
const
X = 0 .. 5;
does not work either while "type X = (Zero, One, Five)" would do both
cases. ;)
So in short: it seems a range type like "byte" can be used where a
"pure" range is expected, but it cannot be used where a set is expected
(like for a case label, even though there a set constant would not be
accepted either):
-- 8< --
type
X = (Zero, One, Five);
var
Bla : X;
const
Foobar = [Zero, One];
begin
Bla := Five;
case Bla of
Low (Foobar) .. High (Foobar) : WriteLn ('Less than Five.');
// The following two lines don't work, of course.
//Foobar: WriteLn ('NO.');
//[Foobar] : WriteLn ('NO.');
else
WriteLn ('More than One, I guess.');
end {case};
// A real set operation.
if Bla in Foobar then
WriteLn ('Really less than Five.')
else
WriteLn ('Wrong. It is NOT less than five!');
end.
-- 8< --
So if the case label is considered a set why can't I use a set constant
(see the commented lines above) and if I do the range thing, which
compiles, it does not consider the value of the constant but rather the
range of its /type/...?
Seems to me that case labels are very special things, at least.
Another oddity would be a for loop:
for Bla := One to Five do ...
would be a range only, yes? (Apart from the fact that - due to the "to"
keyword - really isn't).
So wouldn't it be easier to write
| for Bla := X do ...
here, when X is some range type, I'd like to iterate over? Again I have
to Write "Low (X) to High (X)" quite similar to the "case" case.
I suppose changing that behaviour regarding range types is not an option
at all, so I'd ask for some other improvement:
*deep breath*
What about a compiler built-in like Low() and High() called Range()
where its return type indicates something that would be compatible to a
case and for label and just denote the range of the whole type?
Basically a short cut to the "Low (Type) ..|to High (Type)" expression,
but without the possible pitfall of writing
Low (Type) .. High (A_Similar_And_Unfortunately_Compatible_Type)
and thus being less error-prone...?
I mean, doing:
|for Bla := Range (X) do
or
|case Bla in
|Range (X): ...
doesn't actually look unreadable to me...
Regards,
Vinzent.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] "case" with range stupidities
On Thursday 15 February 2007 13:06, Daniël Mantione wrote:
> Op Thu, 15 Feb 2007, schreef Vinzent Hoefler:
> > program
> >Case_Test;
> >
> > type
> >My_Range = 2000 .. 3000;
> >
> > var
> >X : Integer;
> >
> > begin
> >X := 2500;
> >
> >case X of
> > Low (My_Range) .. High (My_Range) : WriteLn ('In range.
> > (1)'); My_Range : WriteLn ('In range.
> > (2)'); else
> > WriteLn ('Out of range.');
> >end {case};
> > end {Case_Test}.
> >
> > -- 8< --
> >
> > Is there any reasoning why the first switch in the case statement
> > ("Low (My_Range) ...") is allowed, whilst the second one (just
> > "My_Range") is not (says: "constant expression expected")?
>
> Well, a case label is basically a set of values. A type definition is
> something different, i.e. you cannot use "byte" or "longint" as case
> labels either.
Well, fair enough, but why is that I can declare a
type
Foo = array[byte] of Something;
where the type name "byte" also indicates the range? Considering that
type
Foo = array[Low (byte) .. High (byte) of Something;
is totally equivalent, the allowed usage of range types seems a little
bit inconsistent...
Vinzent.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] "case" with range stupidities
Hi all,
consider the following program:
-- 8< --
program
Case_Test;
type
My_Range = 2000 .. 3000;
var
X : Integer;
begin
X := 2500;
case X of
Low (My_Range) .. High (My_Range) : WriteLn ('In range. (1)');
My_Range : WriteLn ('In range. (2)');
else
WriteLn ('Out of range.');
end {case};
end {Case_Test}.
-- 8< --
Is there any reasoning why the first switch in the case statement ("Low
(My_Range) ...") is allowed, whilst the second one (just "My_Range") is
not (says: "constant expression expected")?
Another minor issue is that a type declaration like:
type
My_Range = (2500 - 500) .. (2500 + 500);
is not accepted (message similar to ";" expected, ".." found) and
(basically the same declaration)
type
My_Range = 2500 - 500 .. 2500 + 500;
is. Sometimes I'd really like to add those parantheses just to make the
intention more clear.
Regards,
Vinzent.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Error: Unable to create "reg.xml" file
On Friday 19 January 2007 13:23, Michael Van Canneyt wrote: > HKEY_USER keys is not desirable or feasible (roaming profiles etc). A > config directory can be made read/write for all users. A registry key can be made that, too. Vinzent. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Error: Unable to create "reg.xml" file
On Friday 19 January 2007 13:12, Marco van de Voort wrote: > There is one dangerous caution against overzealous inifile use: with > lessened privileges (a situation that is going to become more > frequent under Vista, iow, user has no admin rights), apps can't > write to "program files/" with the default permissions, and must use > special directories for this. Yes, and the hell they should, multi user OS's are out there for how long? Thirty years? Almost fourty? So - writing application specific data to the same, single location for each and every user is inappropriate for most applications anyway. This leaves us with the "AppData" (or whatever it's called) directory in the user's home directory - or the local registry keys. Without proper rights you can't write to the "global" registry keys either. So I don't see the difference apart from the usual "Is it better to back up thousands of ini files in different locations, or a single blob aka. registry which is several megabytes of a mixture of important data and junk?" question. Vinzent. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Threads and alot of crap continued
On Thursday 09 November 2006 08:22, Michael Schnell wrote: > > Yes, of course, this still *is* nothing more than an event loop, > > ... > > A decent event loop should use an OS API to free the processor until > the next event is scheduled: That's why I wrote the example in Esterel. Give me that API and I sure will use it. Modula had signals at least (although I don't remember it too good), Ada has task entries (and you still write your tasking code in a loop, then). Alas, Object Pascal lacks a decent portable OS tasking interface. Vinzent. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Threads and alot of crap continued
On Wednesday 08 November 2006 16:08, Micha Nelissen wrote: > Vinzent Hoefler wrote: > > The answer to my "I always thought a timer is more comparable to an > > interrupt or signal than a polling loop." was "That is a very > > common misconception." which I still refuse as being a correct > > answer. > > The irony is of course that you clamp to your interrupt definition, > but still implement your log timed event with a loop :-). Well, yes and no, just like I would do in Esterel, for example: |loop | await NEXT_TIME; | emit EXPIRED; |end loop; Because I do not know of any other construct to express indefinite repeatition, I used a loop. Any other ideas? ;) Yes, of course, this still *is* nothing more than an event loop, and its asynchronous character would only come from the fact that it is done in parallel with some main thread, so it neither does interfere with the execution of the main program nor does it depend on it. > > Especially outside of the usual GUI-application, we seemed to be > > talking about, because the user/programmer somehow has to make sure > > that the polling is actually done some time in the future. > > Considering that a simply "ReadLn" can block indefinitely already, > > this is quite hard to accomplish then, isn't it? > > Well, readln is used in the trivial (T)UIs; TUIs/GUIs are usually > event-driven, Whatchamacallit, it was an example where calling this "event loop" might be close to impossible. Yet, admitted, the expiring timer still wouldn't stop the ReadLn from reading its file, so you're screwed either way, but you could for example emit a "beep" to the user from time to time. ;) > like networked apps also can be. A Timer fits in a event-driven app > just fine, I didn't say, it doesn't, did I? If so, I'm sorry. But I even remember mentioning priority queues in that context (which could somehow ensure a timer event would be handled in time, so even "real time" is possible if enough care is taken by the programmer). > and then a timer doesn't interrupt > anything anymore; but your intuition may say that it should, that's > why it's a common misconception. Ok, I now understand where "my misconception" comes from. :P We're back to the usual GUI application where everything depends on that event loop. :) Of course, that's fine for most "event-driven" applications, especially when being GUI. IOW, it can be considered the difference between being preemptive and being cooperative. ;) Problem here is that I would call my event loop only every couple of hours, because responding to on the event "now process image data" takes so long. :) And as far as I understood, the problem was exactly that: To implement something like TTimer in an application which is *not* based on a regularly called event loop. Vinzent. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Threads and alot of crap continued
On Wednesday 08 November 2006 14:43, Micha Nelissen wrote: > Vinzent Hoefler wrote: > >> but it's not realtime by any definition. > > > > First, I never said "real-time" in that context and second: it sure > > can > > I concluded that from your quote: > > > Timing events allow for a handler to be executed at a future point in > time in an efficient way, as it is a standalone timer that is > executed directly in the context of the interrupt handler (it does > not need a server task). > I mainly quoted that to clarify my intention of the term "timer", because there seemed to be some confusion about that. The answer to my "I always thought a timer is more comparable to an interrupt or signal than a polling loop." was "That is a very common misconception." which I still refuse as being a correct answer. [It seems that a lot of people seem to put all their efforts in looking at a single particular implementation before trying to see the big picture. ;)] I didn't say that it *is* necessarily an interrupt or signal, I just said it is comparable to one, by which I meant its preemption of ongoing operations. To implement the semantics of "timing events allow for a handler to be executed at a future point" a polling-loop could prove to be a very problematic solution. Especially outside of the usual GUI-application, we seemed to be talking about, because the user/programmer somehow has to make sure that the polling is actually done some time in the future. Considering that a simply "ReadLn" can block indefinitely already, this is quite hard to accomplish then, isn't it? > I read server task as thread, and a timer as interrupting any thread > at the time it was fired and calling some callback then. Yes. And if a timer implemented as thread has the highest priority it would even do exactly that, and I also said that in one of my last mails. Still no word of "real-time", although now we're catching up. ;) > Maybe Ada creates a hidden thread itself in which it calls these > callbacks (so cheating on its own definition IMHO), Maybe. :) I didn't read the new standard yet, but I guess, the actual implementation is left to the implementor as long as the required semantics are kept. Although it seems rather unliky it actually might be an additional thread on top of the OS' scheduling system, or it might be a real hardware interrupt, or it might be the scheduler of the runtime without any OS running at all ... > but otherwise the > only value for such interrupts would be realtime requirements. Well, Ada is - of course - a language designed with real-time systems in mind. Yet, this doesn't mean, that the general concept is useless outside of a hard real-time scope. Considering that in the GUI-application such things seem to be used very commonly (due to the polling-loop implementation without the implications of being executed concurrently), the value seems to be a little bit greater than to "useful in real time environments only". As far as I understood, the only problem here we discussed were applications without such dedicated event loop. > > microseconds running on an RTOS, of course. > > That's not the common OS case. Precisely, and that's why I even tried to avoid the term "real time" thus far. Yet, such feature can be useful. Vinzent. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Threads and alot of crap continued
On Wednesday 08 November 2006 13:21, Micha Nelissen wrote: > Vinzent Hoefler wrote: > >repeat > > SysUtils.Sleep (self.Interval); > > self.Logger.Flush; > >until self.Terminated; > > > > is totally impossible to work? To implement something less crude > > you > > It works, Oh wonder. A couple of lines ago these semantics were still "impossible". > but it's not realtime by any definition. First, I never said "real-time" in that context and second: it sure can be, if the thread's priority demands an immediate wake-up after the sleep. Then and if implemented a litte bit less crude - as I suggested - it would be no less real-time than |declare | Next_Cycle : Ada.Real_Time.Time := Ada.Real_Time.Clock; | CYCLE_TIME : constant Ada.Real_Time.Time_Span := | Ada.Real_Time.To_Time_Span (1.0); | use type Ada.Real_Time.Time; |begin | loop | Next_Cycle := Next_Cycle + CYCLE_TIME; | Do_Some_Work; | delay until Next_Cycle; | end loop; |end; in Ada would be. And the jitter in the above Ada code was about 30 microseconds running on an RTOS, of course. Vinzent. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Threads and alot of crap continued
On Wednesday 08 November 2006 12:44, Micha Nelissen wrote:
> Vinzent Hoefler wrote:
> > So, the semantics would be about the same as in a signal (apart
> > from the "softer" timing), but you would have much less
> > restrictions in the handler's implementation compared to a real OS
> > signal, which acts more like an interrupt.
>
> Impossible.
Yeah, right. So this:
--- 8< ---
{/= tFlusher.Execute =\}
{ }
{\/}
procedure tFlusher.Execute;
begin
self.Started.SetEvent;
repeat
SysUtils.Sleep (self.Interval);
self.Logger.Flush;
until self.Terminated;
// Last Action Hero.
self.Logger.Flush;
end {tFlusher.Execute};
--- 8< ---
is totally impossible to work? To implement something less crude you
could either implement a "delay until" by checking the point in time,
the threads gets woken up or on UNIX you could even sigwait() for
SIGALARM and (re)set it accordingly.
> You'll end with TThread.Synchronize, but without its
> advantage of knowing in which thread it runs, because the entire
> *point* of a GUI thread is that it's not doing anything for 99% of
> the time (waiting for user input only).
I don't a GUI thread. Currently I have up to 24 threads processing image
data and writing log information (which I don't want to be written line
by line, that's why I collect them in a queue for a couple of seconds
before actually writing it to a file) and some other threads processing
RPC requests. And only one of them provides an RPC interface to
something you'd call GUI.
But of course, automatically calling methods by a "timer" with such
semantics is totally impossible. Guess I have to rethink, why it
actually works.
Vinzent.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Threads and alot of crap continued
On Wednesday 08 November 2006 10:53, Micha Nelissen wrote: Sorry for all the confusion, I'm trying to clarify what I actually mean (or what I would *expect* from such a timer object): > I don't see how async timers can be useful for software (maybe to > control hardware perhaps, but only the trivial kind as well, no > complex state allowed), as you cannot take any locks, First: Of course you can take locks. Such a "timed execution" is - just like any other thread - still scheduled by the OS and thus follows the same rules. A higher priority to make sure an expired timer actually preempts other running threads doesn't change this fact. > and must be re-entrant. This implies you can almost call no function > at all. Second: You could call any function you can call safely from within any other plain thread. That's the difference to a "real" signal (where you can merely set some variable to be polled later and bail out), and makes it so much nicer to use than OS' signals. So, the semantics would be about the same as in a signal (apart from the "softer" timing), but you would have much less restrictions in the handler's implementation compared to a real OS signal, which acts more like an interrupt. Vinzent. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Threads and alot of crap continued
On Wednesday 08 November 2006 10:26, Ales Katona wrote: > This is an old problem, and not fixable by wishing it. If you want a > good async. timer, sure make one, but don't expect it to work safely > by magic. I'm sure I won't, I'm paranoid. :) > That's what I ment, it won't simply "just work without implications" > like TThread SEEMS to. Alright, yes. But as soon as you start overriding Thread.Execute the user (as in programmer) should start thinking about those issues anyway, so I didn't consider that a show-stopper. Maintaining thread-safety ain't so complex once you start following some simple rules. Vinzent. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Threads and alot of crap continued
On Wednesday 08 November 2006 10:14, Michael Schnell wrote: > If you take a look the start of this thread, I mentioned that after > implementing Delphi/Lazarus like behavior for the main thread without > the need for a GUI, I'd like to enhance the concept by optionally > having an TApplication object for any thread (e.g. > TThread.Application) and thus having an event scheduler for same. Sorry, if it caused confusion, but I don't know about TApplication or its particular implementation. I don't do GUI. ;) I was just reading about timer objects ... sorry. > By this it would be possible to implement TTimer in a way that it's > callbacks can be fired in the context of a thread and thus > "asynchronous timer event" are possible in a completely compatible > way, allowing the user to define, regarding what context the event is > asynchronous. IMHO this would be a great plus for any embedded > "real-time" use of FPC. Now we're talking. :) Vinzent. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Threads and alot of crap continued
On Wednesday 08 November 2006 10:01, Michael Schnell wrote: > But doing a function call (or hence using a callback) does not change > the thread context you are running in and thus you are still the same > thread. IOW: code lines are not _dedicated_ to a thread context. Oh that, of course. Seems I got confused by all the talking that my code can't work at all, and started to think in TThread objects instead of execution context. Well, right. I wasn't going to write a task scheduler. ;) But now ... rereading the post, the original text was "You can't just put a TTimer in which works in it's own thread and then calls some callback in it's own thread," and I still wonder why I shouldn't be able to do that (well, if TTimer would actually do what its name suggests and no-one else would change the subject to one particular Delphi-way-implementation called TTimer, when I am still talking about a timer object in general). Vinzent. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Threads and alot of crap continued
On Wednesday 08 November 2006 09:42, Michael Van Canneyt wrote: > On Wed, 8 Nov 2006, Vinzent Hoefler wrote: > > On Wednesday 08 November 2006 09:16, Michael Van Canneyt wrote: > > > On Wed, 8 Nov 2006, Michael Schnell wrote: > > > > > As for general use, you can't do a Timer this way. > > > > > > > > Right ! The beauty of TTimer (and GUI events as well) is that > > > > it does not work in a thread. Otherwise it e.g. would not be > > > > possible to do GUI stuff in a timer event, as VCL and LCL are > > > > not thread save (and probably can't be made thread save). > > > > > > It can't because X-Windows or MS-Windows are not thread-safe. > > > > Yeah, right. And threading in DOS is not possible either, because > > DOS is non-reentrant, is it? > > I don't know. I didn't make any statements about DOS, AFAIK. No you didn't. But I heard the same before and yet there *is* a thread-safe implementation on top of GTK (which isn't thread-safe, either) and there *are* threading implementations under DOS. So I'd be careful with such "it can't"s. ;) Vinzent. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Threads and alot of crap continued
On Wednesday 08 November 2006 09:27, Ales Katona wrote: > On st , 2006-11-08 at 07:35 +0000, Vinzent Hoefler wrote: > > On Tuesday 07 November 2006 16:10, Ales Katona wrote: > > > As for general use, you can't do a Timer this way. > > > > Believe me, I can. :) > > > > > You can't just put > > > a TTimer in which works in it's own thread and then calls some > > > callback in it's own thread, > > > > I even call the callback of another thread. :P > > No you can't. You still refuse to tell me why, so please stop telling me what I can't do, especially when I *am* doing it. Of course the procedures in question are protected against concurrent execution from different threads at the same time. This was needed anyway, because the object was designed to be called from different threads anyway. So adding a "timed" call from another thread wasn't too hard, as you probably can imagine. Of course I am not using this GUI based TTimer object, I was talking about the concept "timer" in a more general way. Call it signal, if you like that better. > > If you'd do that, the timer event callbacks would be queued and > > then executed in the context of the main thread. > > The user is only required to call CheckSynchronized from time to > > time, but because the accuracy of the time of execution of any > > associated handler is in the hands of the user anyway as long as > > you stick to a synchronous solution to avoid putting the burden of > > locking data to the programmer. > > As long as you don't want to implement real-time behaviour, I don't > > even see a problem in that. If the user decides to not call/execute > > any provided "message event loop", the execution of the timer > > handler code will be deferred until the end of the universe anyway. > > This is exactly the "oh-so-complex" solution I use in lNet, Let me quote yourself: "Apart from asynchronous stuff like watching handles etc. I don't see much use for this relativly complicated program model." So you yourself seem to look at it as "complex" somehow. > and is basicly the only solution. Well, using a (priority) message queue is a common solution, yes. Yet it's not necessarily the only one. :P It all depends on what you're trying to accomplish. I still like to have a "asynchronous timer event" model. It would still simplify some code. Vinzent. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Threads and alot of crap continued
On Wednesday 08 November 2006 09:16, Michael Van Canneyt wrote: > On Wed, 8 Nov 2006, Michael Schnell wrote: > > > As for general use, you can't do a Timer this way. > > > > Right ! The beauty of TTimer (and GUI events as well) is that it > > does not work in a thread. Otherwise it e.g. would not be possible > > to do GUI stuff in a timer event, as VCL and LCL are not thread > > save (and probably can't be made thread save). > > It can't because X-Windows or MS-Windows are not thread-safe. Yeah, right. And threading in DOS is not possible either, because DOS is non-reentrant, is it? Vinzent. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Threads and alot of crap continued
On Wednesday 08 November 2006 09:15, Michael Schnell wrote: > Right ! The beauty of TTimer (and GUI events as well) is that it does > not work in a thread. Well, I don't consider it beautiful, I consider it a hack. :) Vinzent. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Threads and alot of crap continued
On Tuesday 07 November 2006 17:10, Michael Schnell wrote: > > Of course, because the common concept of a timer is as asynchronous > > as in "multi-threaded" or even "interrupt". > > That is not true ! (See my other post.) Well, a timer is, even though the Delphi implementation of a so-called TTimer object might not. Basically a timer starts, later then it expires an that expiration creates an event (in the old days we called that interrupt). This event is no way synchronous to the code currently running. > Timer events are queued in a line (message-queue) with all > "hardware"/"GUI" events. Ok. So this would do nothing more than synchronize the asynchronous event of an expired timer to the main thread. Of course, the "time" of execution of the code associated with the expiration is now determined by the time the message queue is handled the next time. So why don't use CheckSynchronized for this? Vinzent. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Threads and alot of crap continued
On Tuesday 07 November 2006 16:10, Ales Katona wrote: > As for general use, you can't do a Timer this way. Believe me, I can. :) > You can't just put > a TTimer in which works in it's own thread and then calls some > callback in it's own thread, I even call the callback of another thread. :P > unless the users are informed, and-or > the thing is locked and protected but you can't do that from within a > TThread (because you don't know what the callback code is). Well, in Turbo Pascal I could write interrupt handlers the wrong way, without locking code/data in question and nobody cared about that simple fact. But if that's so complex: Why don't you use the usual synchronization stuff then to put the asynchronous timer event in a message queue using Synchronized? > In case of gui TTimer this cannot happen because it's not threaded, > so the userloop would first finish, then the user function returns > and the main gui loop does it's stuff (this is my oh-so-complicated > part, done by the gui). The problem in a portable general solution is that the may be no "main gui loop" and you can't just write one and force anyone to use it, right? So why don't you use Synchronized/CheckSynchronize (or whatever it's called) then? If you'd do that, the timer event callbacks would be queued and then executed in the context of the main thread. The user is only required to call CheckSynchronized from time to time, but because the accuracy of the time of execution of any associated handler is in the hands of the user anyway as long as you stick to a synchronous solution to avoid putting the burden of locking data to the programmer. As long as you don't want to implement real-time behaviour, I don't even see a problem in that. If the user decides to not call/execute any provided "message event loop", the execution of the timer handler code will be deferred until the end of the universe anyway. Vinzent. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Threads and alot of crap continued
On Tuesday 07 November 2006 15:17, Ales Katona wrote: > So eg: if you want to do something every 1000ms, you could put a > TThread based timer in, and make it Sleep(1000) and then call the > code, but you must be sure that your main thread cannot have > conflicts if this code is called at any time (eg: variable writes > etc.). Of course, because the common concept of a timer is as asynchronous as in "multi-threaded" or even "interrupt". You're not seriously trying to work around that simple fact, do you? Vinzent. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Threads and alot of crap continued
On Tuesday 07 November 2006 15:02, Michael Schnell wrote:
> > I always thought a timer is more comparable to an interrupt or
> > signal than a polling loop.
>
> That is a very common misconception.
Indeed. Even a paper in "Embedded Computing Design" about Ada 2005
follows that "very common" misconception:
-- quote -- 8< --
Timing events allow for a handler to be executed at a future point in
time in an efficient way, as it is a standalone timer that is executed
directly in the context of the interrupt handler (it does not need a
server task).
The use of timing events may reduce the number of tasks in a program and
the overhead of context switching. It provides an effective solution
for programming short time-triggered procedures and implementing some
specific scheduling algorithms, such as those used for imprecise
computation. Imprecise computation increases the utilization and
effectiveness of real-time applications by means of structuring tasks
into two phases (one mandatory and one optional). Scheduling algorithms
that try to maximize the likelihood that optional parts are completed
typically require changing asynchronously the priority of a task, which
can be implemented elegantly and efficiently with timing events.
-- /quote -- 8< --
But of course, the Delphi "concept" is right.
> A TTimer event is not an
> interrupt in that it does not interrupt any code in the Application.
> such an "automatic event" is always done in the main thread and only
> started when (1) the application is idle, (2) the application comes
> back from some other event, or (3) Application.ProcessMessages is
> called. Only another thread can be interrupted ("preempted") by such
> an event.
Those are details of _one_ particular implementation.
> The big advantage is that you do not need to protect any resources
> from multi-threaded access if you do not explicitly create a thread
> by means of TThread.
And the big disadvantage seems to be a overly complicated programming
model. Guess, what I'd prefer.
Vinzent.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Threads and alot of crap continued
On Tuesday 07 November 2006 14:47, Michael Schnell wrote:
> > Well, for me it would have saved me some time which I wasted in
> > creating threads that implement "timing events" by simply sleeping
> > for a particular time.
>
> IMHO this should be done following the Delphi paradigms to be nice to
> Delphi users coming over to FCP (only enhancement allowed). Of course
> Lazarus does this, but IMHO it would be great to have this in a
> system without a GUI, too.
At first: It doesn't matter how it's done to me as long as it works. :)
My system is a system without a GUI, or to be more precise: with a
remote (G)UI. That's why I don't know about LCL or whatever and I don't
even care, because I simply don't understand what "time" as in "timer"
has to do with "graphics" as in "graphical". For me that's two
completely different subjects unless we're talking about animations
where those two subjects meet.
All I needed was a simple timer, so that some user supplied routine was
being called after some specified time has been elapsed. There's
nothing complicated in that view of the programming model, because it's
the user's view. I implemented that by using an additional thread in a
relatively simple way, although its execute method was merely a
|while not self.Terminated do
|begin
| SysUtils.Sleep (self.Interval);
| self.Logger.Flush;
|end {while};
to take care of my requirement that the Flush-routine of the logger
object would be called once in a while.
If "following the Delphi paradigm" leads to such complicated solutions
as layed out here by Ales (and I'm still talking about the user's view
here, not any particular implementation) I surely can live without such
a solution.
Vinzent.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Threads and alot of crap continued
On Tuesday 07 November 2006 12:42, Ales Katona wrote: > If you want a "Timer" a "polling" mechanism has to take place which > looks if something happened on some timer for example, Is that so? > OnTimer is "ready to be fired" (you can't call callbacks in threads, I can't call callbacks in threads? Why's that? Or am I understanding something wrong? > and if you go single-threaded you have to provide the main loop > hooks). Do I? I always thought a timer is more comparable to an interrupt or signal than a polling loop. > So basicly, let's say TTimer is in RTL and there's some event > mechanism already too, you'd have to do something like this: > > procedure init; > begin > Timer.Timeout:=somenumber; > Timer.OnTimer:[EMAIL PROTECTED]; > EventHandler.RegisterTimer(Timer); // could be the other way around > end; > > procedure MainLoop; > begin > EventHandler.HandleEvents; // if eventhandler after polling all > timers in it's watchlist find out some has it's interval done, it > fires it's callback end; > > begin > Init; > MainLoop; > end. Timer.OnTimer := @Some_Callback; Timer.Timeout := Some_Number; Timer.Periodic := True; And somewhere a "Timer.Start;", that should be it. There's no need to register the timer in a global event loop or even explicitely calling it. If that's needed on a particalur target, the timer's implementation should take care of this. > Apart from asynchronous stuff like watching handles etc. I don't see > much use for this relativly complicated program model. Don't know what's complicated here. It's asynchronous by definition, of course, but apart from that? Well, for me it would have saved me some time which I wasted in creating threads that implement "timing events" by simply sleeping for a particular time. And there's really nothing complicated in queuing log messages and saving the queued messages every five seconds. Vinzent. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] TStringList.CustomSort
On Tuesday 07 November 2006 09:17, Micha Nelissen wrote: > Chris Cheney wrote: > > > Of course, the efficient way to build a sorted list is to set > > Sorted to False and to sort the list after all the items have been > > added. > > It doesn't matter in O-time: both are O(n log n). Nevertheless, you > probably will save some function call overhead. That highly depends on the sorting algorithm used. A plain Quicksort has a very bad worst case of O(n**2) that develops especially when the list to be sorted already is. Even Bubblesort would be faster in such a case. Vinzent. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] CmdLine
On Thursday 19 October 2006 09:39, Marc Weustink wrote: > The only thing guaranteed by the language is that if you follow its > definitions, it will compile. No. That's syntax. I'm talking about semantics. Vinzent. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] CmdLine
On Thursday 19 October 2006 08:31, Marc Weustink wrote: > The case shows that users can do this. There is no language construct > that forbids it. So optimizing this with a smart linker may break > such code. Yes, it may. So what? There's hell a lot of code that is generally possible within the language. Still it can be unportable, plain wrong, only work in certain situations etc. pp. Read: It still may break. So "no language construct that forbids it" is no excuse, especially when you're digging around in internal compiler constructs. Otherwise I'd expect some of my old code to work with FreePascal - where I outsmarted TPs heap manager to be able to free parts of dynamically allocated arrays. >IMO, ppl will always be smarter and find a valid case where things get >broken. This highly depends on your definition of "valid". My opinion: If it ain't guaranteed by the language, it ain't valid. Vinzent. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Threads and alot of crap
On Tuesday 17 October 2006 10:03, Micha Nelissen wrote: > Windows events do not have this problem since they are stateful. To be more precise: Windows signals are persistent, not transient like Unix signals are. Vinzent. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Threads and alot of crap
On Tuesday 17 October 2006 09:46, Jonas Maebe wrote: > On 17 okt 2006, at 11:22, Vinzent Hoefler wrote: > >> The pthread_cond_wait() function atomically unlocks the > >> mutex argument > >> and waits on the cond argument. > >> > >> So the mutex should already be unlocked afterwards. > > > > If you would have read a couple of lines further you also would > > have > > > > found: > > |Before returning to the calling thread, pthread_cond_wait > > | re-acquires mutex (as per pthread_lock_mutex). > > That is not on the Mac OS X man page for pthread_cond_wait. See >http://www.hmug.org/man/3/pthread_cond_wait.php I see. > Not sure if this means it's not necessary in the Mac OS X (and > possibly FreeBSD) versions, or that the Mac OS X man pages are > incomplete. They are most definitely incomplete. Vinzent. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Threads and alot of crap
On Tuesday 17 October 2006 09:03, Jonas Maebe wrote: > On 17 okt 2006, at 10:44, Daniël Mantione wrote: > > procedure intRTLEventSetEvent(AEvent: PRTLEvent); > > var p:pintrtlevent; > > > > begin > > p:=pintrtlevent(aevent); > > pthread_mutex_lock(@p^.mutex); > > pthread_cond_signal(@p^.condvar); > > pthread_mutex_unlock(@p^.mutex); > > end; > > > > procedure intRTLEventStartWait(AEvent: PRTLEvent); > > var p:pintrtlevent; > > > > begin > > p:=pintrtlevent(aevent); > > pthread_mutex_lock(@p^.mutex); > > end; > > > > procedure intRTLEventWaitFor(AEvent: PRTLEvent); > > var p:pintrtlevent; > > > > begin > > p:=pintrtlevent(aevent); > > pthread_cond_wait(@p^.condvar, @p^.mutex); > > pthread_mutex_unlock(@p^.mutex); > > end; > > This last pthread_mutex_unlock does not make sense to me. From the > pthread_cond_wait man page: > > The pthread_cond_wait() function atomically unlocks the mutex > argument > and waits on the cond argument. > > So the mutex should already be unlocked afterwards. If you would have read a couple of lines further you also would have found: |Before returning to the calling thread, pthread_cond_wait re-acquires |mutex (as per pthread_lock_mutex). > Further, what is > the lock/unlock for in the intRTLEventSetEvent? pthread_cond_signal > can perfectly deal with multiple threads simultaneously signalling > the same condition variable (pthreads is a multithreading api, not a > random non-reentrant piece of code). Oh, is it? Read the f*cking man page: |A condition variable must always be associated with a mutex, to avoid |the race condition where a thread prepares to wait on a condition |variable and another thread signals the condition just before the first |thread actually waits on it. Vinzent. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] format function
On Thursday 12 October 2006 13:46, Micha Nelissen wrote: > Jonas Maebe wrote: > > can still be one (meaning that it's a negative zero). And for some > > fpu calculations this even matters. > > Like ? Divide by signed zero. That decides if the result is positive or negative infinity. :D Vinzent. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] format function
On Thursday 12 October 2006 12:16, Andrea Mauri wrote:
> Dear all,
> this is my first mail to this mailing list, I'm not sure this is the
> correct one to post this topic.
> I noticed a strange behavior of the format function. I'm not sure it
> can be considered as a bug.
> If I use
> format('%.3f', [-0.0001])
> the resulting string is
> -0.000
> and not
> 0.000
> Why?
Hmm, I'd guess that's because the (original) number is negative and the
sign is not changed by rounding or chopping off digits.
Vinzent.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Tail recursion optimization
On Tuesday 10 October 2006 08:29, Florian Klaempfl wrote: > Daniël Mantione wrote: > > Op Tue, 10 Oct 2006, schreef Florian Klaempfl: > >> Yesterday, I've implemented tail recursion optimization > >> (http://svn.freepascal.org/svn/fpc/trunk/compiler/opttail.pas > >> resulting in > >> http://www.hu.freepascal.org/fpcircbot/cgipastebin?msgid=158 pp11 > >> is the new compiler, fpc11 the old, both are 2.1.1). > > > > Wow! > > Well, it's use for real world applications is limited Limited to what? Binary tree data structures only? ;) Vinzent. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Adding a unidirectional dataset to sqldb
On Thursday 05 October 2006 08:13, Michael Van Canneyt wrote: > On Thu, 5 Oct 2006, Joost van der Sluis wrote: > > > > Now I'm thinking about using an interface, to avoid double code. > > But I don't know what effect that has on run-time performance. I > > mean, the idea was to make if faster ... > > An interface does not contain any code, so how would adding an > interface help ? No code -> no execution time. Try being faster than that. SCNR. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Suggestion for change: Overly strict check
On Tuesday 03 October 2006 16:26, Flávio Etrusco wrote: > At my workplace we've standardized on using three "scope prefixes": > p_ for function parameter, m_ for members/fields, and g_ for global. I know that discussion, I lost it at work already, but apart from C where every identifier is sort of global, there's absolutely no need for this: Writing this/self. removes the need for m_ and even adds some sort of safety, because that's one rule the compiler can actually check. - That's one. The difference between locals and paranetrized locals does not need to be mentioned at all, because inside the function they behave the same and have the same scope. - That' two. Globals should be forbidden. That's three. Hmm, ok, if really needed, you should prefix the unit name to ensure sudden name clashes (like my "Break" identifier) anyway, so globals are easily identified simply by being used already. - So, now that's three. > I have used "scope prefixes" long before this/them and I as a > somewhat-die-hard-Pascal-programmer had a hard time getting used to > the underscores, which seems to divide the identifier and makes you > code look like C, but I barely notice it now ;-) And it's very > practical for code completion :-) Well, since my variable names tend to be longer than four chars, I always use underscores and my code sure does NOT look like C. ;) ItMakesIdentifiersMoreReadableBecauseTheUnderscoreIsAsCloseAsYouCanGetToNormalTextWithoutUsingWhitespace. Vinzent. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Suggestion for change: Overly strict check
On Tuesday 03 October 2006 11:15, Micha Nelissen wrote: > On Tue, Oct 03, 2006 at 07:36:11AM +0000, Vinzent Hoefler wrote: > > On Monday 02 October 2006 17:16, Micha Nelissen wrote: > > > Ok, so enforcing different names is good then, that makes code > > > more context insensitive, since identifiers won't suddenly > > > "resolve" to parameters with the same name. > > > > No, it's more like the other way around. You get sudden name > > clashes which you didn't have before, because in the other class > > the field which clashes with your wisely chosen parameter name > > didn't exist. > > We should be talking about semantics, not about 'compabilility > whatever the resulting meaning may be'. Yes, but the semantics is clear due to scoping rules. It may not be obvious, though. ;) > > There's a reason, I always write "self.Identifier" and I also > > refuse to revert back to the so called Hungarian notation (like > > AParameter). Even if there is *no* parameter and/or field with that > > name it's always clear which part is meant. > > This is not Hungarian notation. Hungarian is to prefix variable names > with the (abbreviated) type. Oh, come on. It's still a meaningless prefix not checked by anyone, at last the compiler. Especially when software gets changed usually the prefixes remain for whatever "historical reason" and the meaning changes (anyone remember LPSZSomething? Long Pointers are gone since ages, but the type names remained for "compatibility"), so those prefixes are much more dangerous than they appear at first sight, if you trust them. And if you don't trust them, that means you check it for yourself and then you can get rid of them, because the serve no purpose other than making variable names totally unreadable. > > It would be more wise to warn about name clashes between units, > > because for example NewStr is defined in objects.pas and in > > classes.pas (IIRC), but depending on which one and how it is used > > your program may crash. > > Agree, it's separate, but a good point. Well, I don't consider it *that* separate. There's a "scoping" rule defined by the language and as such there are no ambiguities (at compiler level), yet it's not obvious to the developer. Change the order in which units are included and the semantics may change. Of course, the semantic change would still be defined by the language. I remember trying to compile some TP7 code and I couldn't figure out what went wrong until I noticed there was one unit included that defined a variable called "Break". Finally finding why |if condition then | break; didn't compile anymore although it did a couple of days before taught me to always use the full name prefixed by the unit's name. > > As long as such problems exist in the language definition itself, > > this whole discussion about "cleaner code" and if such syntactic > > checks are needed is f*cking pointless, because the language > > already forces you to use fully qualified names anyway if you want > > to avoid such problems. So you can as well use "self" to distiguish > > between parameters and fields even if they have the same name. > > In theory, yes, but in practice nobody prefixes every field usage of > self with 'Self.'. Not even counting my"self" (and not counting Ada programmers, where similar things are much more common, because there the compiler stops at any *possible* ambiguity), I know at *least* two nobodies then. And hell, I lost track how often have I seen "this. ..." in highly modern Java code. ;) So it seems much more common than you may think. Vinzent. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Suggestion for change: Overly strict check
On Monday 02 October 2006 17:16, Micha Nelissen wrote: > Chris Cheney wrote: > >> I'm pretty sure he means that no can no longer, for example, copy > >> a function from one class to another, without risking having to > >> rewrite all the parameter names. > > > > You have understood me correctly - I would have expressed it a > > little differently, but not as succinctly. > > Ok, so enforcing different names is good then, that makes code more > context insensitive, since identifiers won't suddenly "resolve" to > parameters with the same name. No, it's more like the other way around. You get sudden name clashes which you didn't have before, because in the other class the field which clashes with your wisely chosen parameter name didn't exist. There's a reason, I always write "self.Identifier" and I also refuse to revert back to the so called Hungarian notation (like AParameter). Even if there is *no* parameter and/or field with that name it's always clear which part is meant. It would be more wise to warn about name clashes between units, because for example NewStr is defined in objects.pas and in classes.pas (IIRC), but depending on which one and how it is used your program may crash. As long as such problems exist in the language definition itself, this whole discussion about "cleaner code" and if such syntactic checks are needed is f*cking pointless, because the language already forces you to use fully qualified names anyway if you want to avoid such problems. So you can as well use "self" to distiguish between parameters and fields even if they have the same name. Vinzent. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Suggestion for change: Overly strict check
On Wednesday 27 September 2006 20:50, ik wrote: > Let me give you an example of a real bug that allow attackers to gain > root access using X-server, and I hope you will understand why such > checking can be a good thing. It *can*. But as usual the pros and cons should be weighted properly. Although I usually like tremendous amounts of compiler checks, because they save my time, I have to agree with Christian here. This sort of "syntax" check is far too strict. If at all, it should be a warning and *only* if the types could actually be confused. Forcing people to use Hungarian Notation, like it was already suggested, to avoid this check doesn't help neither, there are enough examples for that. (Granted, maybe this is due to the fact, that I always write "self. ..." for an object method/variable, so local names can't get confused in such a way at all.) Vinzent. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] Inlining functions...
Hi,
some questions:
1) Is there some good reason why the support for the inline keyword can
be turned on and off explicitely by the {$INLINE} directive?
2) Can I check somehow if inlining is enabled during compilation?
{$IFOPT INLINE} didn't work. ;)
2a) If the answer to 2) is "no", can we make the compiler to ignore it
like the "far" keyword? It's because, I'm quite used to the fact that
inline is merely a suggestion to the compiler, not taken as a command
to be obeyed all times.
Vinzent.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: [patch] types.pp - InflateRect() & Size()
On Tuesday 25 July 2006 14:42, Graeme Geldenhuys wrote: > Sorry, I added the two Size() functions as a last minute and only > after sending the patch I noticed that it breaks the FPC build! > Sorry! > > I attached another patch, without the Size() functions... Anybody > know how we can get around the Size() issue. It conflicts with the > "SIZE = TSize;" line on line 94 in unit types.pp I'd suggest to get rid of the "SIZE" type rename. But most probably it will break something else somewhere... Vinzent. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] LinkLib Issues In Lazarus and in FPC-2.0.2
On Monday 17 July 2006 15:33, Micha Nelissen wrote: > Vinzent Hoefler wrote: > > Of course they don't. Unlike some other languages where such things > > are standardized quite clearly, (most) consistency, dependency and > > linking issues are beyond the scope of the official C-standard. > > I'm not talking about the C language, but the vendors, the C library > implementors, etc. And I was talking about the deficiency of its language definition that leads to exactly what your complaining about. Don't make the mistake to reduce language to syntax only. Vinzent. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] LinkLib Issues In Lazarus and in FPC-2.0.2
On Monday 17 July 2006 15:03, Micha Nelissen wrote: > No these are separate things. The C compiler vendors do not provide a > common platform resulting in a differing mess that has to be held > together with scripts. Of course they don't. Unlike some other languages where such things are standardized quite clearly, (most) consistency, dependency and linking issues are beyond the scope of the official C-standard. What a luck that at least the code is portable from one platform to another. If you have a spare floppy to transport it. :-> Vinzent. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Problem loading 2 dlls created on Free Pascal
On Thursday 13 July 2006 12:31, Jose Manuel wrote: >>> The error code is: 193 0x00C1 N/A %1 is not a >>> valid Win32 application. >>> >>> But that doesn't make sense. [...] > > I guess FPC is creating the DLL with no relocation section in it. > Another issue is that meaningless error. It should be "Abnormal > process termination" or the like.. :-? Uhuh. How come that this would make more sense? ;-) SCNR, Vinzent. -- "An unexpected error occured." - Oh, all the other ones are *expected*? ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Format with zero padding
On Tuesday 20 June 2006 11:39, Micha Nelissen wrote:
> Vinzent Hoefler wrote:
> > On Tuesday 20 June 2006 10:44, Micha Nelissen wrote:
> >> How can I zero-pad using Format ?
> >
> > RTFM. :-)
> >
> > SysUtils.Format ('%.4D', Some_Int);
>
> Sounds like I found a case where 'C' is more intuitive than pascal
> ;-).
As if format strings were intuitive at all. :-)
I'd call "Zero_Pad (Some_Int, 4)" definitely more intuitive.
> Seriously, isn't "Format" an imitation of C's printf ?
Apart from the fact, that you can get run time type checking? Yeah, I
suppose so.
> At least they
> are very similar, but on this detail (and maybe some others as well)
> they are different.
Well, let's assume it's due to Delphi-compatibility. Probably Borland
decided to do it differently just for the fun of it. ;-)
Vinzent.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Format with zero padding
On Tuesday 20 June 2006 10:44, Micha Nelissen wrote:
> How can I zero-pad using Format ?
RTFM. :-)
SysUtils.Format ('%.4D', Some_Int);
Vinzent.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] dominant short strings in compiler source
On Wednesday 17 May 2006 20:50, Marco van de Voort wrote: > Having to check and guard each and every string operation is also not > really productive. K&R tried that :-) And I thought they did it the other way around. Leaving the check as an exercise to the coder. ;-) Vinzent. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Math.DivMod results should be signed
On Tuesday 21 March 2006 04:37, Michalis Kamburelis wrote: > I'm concerned with using DivMod in cases when Dividend is < 0. DivMod > declaration is > >procedure DivMod(Dividend: Integer; Divisor: Word; var Result, > Remainder: Word); > > which means that it doesn't allow for Result and Remainder to be < 0. Which would seem correct, if this were really a modulo-operation. Unfortunately, DivMod should really be called DivRem, because it does not calculate the modulus, but rather the remainder of the division operation. But at least the name of the result variable suggests so. > But when Dividend is < 0, Result and/or Remainder sometimes have to > be < 0. For example, > > var >UnsignedDivResult, UnsignedModResult: Word; >DivResult: SmallInt absolute UnsignedDivResult; >ModResult: SmallInt absolute UnsignedModResult; > begin >DivMod(-39, 20, UnsignedDivResult, UnsignedModResult); > end; > > gets me UnsignedDivResult = 65535 and UnsignedModResult = 65517. Of > course when treating memory as signed values (DivResult and > ModResult), I can "decipher" correct values (-1 and -19) but that's > obviously unclean. Agreed. This result proves, that on an x86 the IDIV instruction is used, which is a signed integer operation with _signed_ results. So if Delphi does it the same way, they really screwed up the interface, because then it only works correctly for non-negative Dividends and Divisors less than 32768. > Sure I can also just use "div" and "mod" > operators, they always get me correct values, but I understand that > doing div and mod separately may be slower than DivMod on some > processors. Yes, just because you would do exactly the same operation twice. > I know that DivMod arguments have to stay as Word for Delphi compat. I suppose so, although it is wrong (or let's say: very restricted) anyway. > But in the light of the above, it seems like a good idea to add > overloaded DivMod version that returns Result and Remainder as signed > values ? It would be, definitely. Especially because it does seem to calculate it that way. Vinzent. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] about realtime tasks
On Wednesday 18 January 2006 10:30, Stefan Kisdaroczi wrote: > Its working so far, but using multiple tasks, there are some strange > effects (exceptions,hangs). > From the freepascal documentation: > "Although it is not forbidden to do so, it is not recommended to use > system-specific threading routines: ..." As far as I understand that it means you should not do that at the _application side_. There is a ThreadManager to abstract away these system specifics. > As far as I understood, I need to include the unit cthreads, which i > have done. Which AFAIK in turn uses the pthreads library. Which is probably not what you want. > When I include cthreads and (manually?) initialize the ThreadManager, > would it be ok ? I think you should "simply" write and install your own thread manager based on the (native or the RT-POSIX-threads) xenomai API and link to the xenomai library _instead_ of the libpthread. Vinzent. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Templates / Generics Syntax
On Friday 04 November 2005 13:48, Vinzent Hoefler wrote: Stupid KMail. Deleted the text after file's eof. After the file there was supposed to be a remark about that the example does not compile as is, because generics in Ada are different from C++ templates, which are merely more like macros, but that it may give some ideas about the proposed syntax. Damn. I hate software. Vinzent. -- public key: http://www.t-domaingrabbing.ch/publickey.asc pgpO6hm6mmAZa.pgp Description: signature ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Templates / Generics Syntax
On Friday 04 November 2005 13:27, Marco van de Voort wrote:
["<>"]
> The evil is in
>
> - using characters instead of modifiers.
> - worse, recycling already used characters.
Alright, I completely understand at least the first part, so perhaps
they should simply not be overused. :-)
Just for the fun and for those who don't know it yet, the previously
given example in Ada95-syntax:
-- 8< -- snip --
procedure Gen_Test is
-
package Show is
procedure Do_It (i : Integer);
procedure Do_It (s : String);
end Show;
package body Show is
procedure Do_It (i : Integer) is
begin
null;
end Do_It;
procedure Do_It (s : String) is
begin
null;
end Do_It;
end Show;
-
-
generic
type T (<>) is private;
procedure Dump (Value : T);
procedure Dump (Value : T) is
use Show;
begin
Do_It (Value);
end Dump;
-
-
procedure My_Dump is new Dump (Integer);
procedure My_Dump is new Dump (String);
-
begin -- Gen_Test
My_Dump (42);
My_Dump ("foobar");
end Gen_Test;
pgp0x2VjCjF7F.pgp
Description: signature
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Templates / Generics Syntax
On Friday 04 November 2005 13:00, Micha Nelissen wrote: > Combining some of the wiki ideas, and has no "evil" <> characters > :-). I don't understand the fuzz about using "<>". It's not even close to being C(++)-ish, because it was used for describing discrete range types _at least_ in Ada's generics back in 1983[*] already. Perhaps someone should take a look at those, because these are also quite different from C++-templates. Vinzent. [*] That would be the same year the term "C++" just appeared first in history of programming languages then, and this particular C++ didn't even have templates yet. -- public key: http://www.t-domaingrabbing.ch/publickey.asc pgp3kje8Y8SWV.pgp Description: signature ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Templates / Generics
On Friday 04 November 2005 09:25, Micha Nelissen wrote: > Marc Weustink wrote: > > > If the generic is "pre"compiled (which is maybe necesary if you > > need access to privates) then I fear some runtime logic has to be > > added to call the correct procedure. IE. something like > > > > case TypeInfo(Data) of > > StringType: Show(Data); > > IntegerType: Show(Data); > > end; > > The whole idea of Generics is to avoid this :-) At user level, yes. But as a compiler-writer you'd gotta make it work somehow. Vinzent. -- public key: http://www.t-domaingrabbing.ch/publickey.asc pgp8YjRx3wBer.pgp Description: signature ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Advantages of/alternatives for Inc (was: bug: Inc(v, i)/Dec(v, i))
On Friday 08 July 2005 12:39, Tom Verhoeff wrote: > On Thu, Jul 07, 2005 at 07:47:03AM +0000, Vinzent Hoefler wrote: > > operators. So especially with the "added" overflow check I think, > > Inc and Dec are pretty useless functions, because the don't do > > anything you can't accomplish by using "+" or "-" unless you have > > very_long_and_complex_variable_names and want to save some typing > > work. > > You suggest that it saves only typing, No, I just tried to ignore that point and hoped nobody would notice. :) > but it also simplifies > optimization in cases where the variable is compositite, because the > address needs to be calculated only once. Yes, but in the same way it endorses using functions with side-effects. Consider |Int_Ptr^ := Int_Ptr^ + 1; vs. |Inc (Int_Ptr^); where Int_Ptr is a function returning a pointer to a different Integer each time it is called. > E.g. in one piece of code, > I have a 13-dimensional array of integers, and I do > > Inc ( A[e1, e2, ..., e13] ) > > I don't know if modern compilers will properly optimize > > A[e1, e2, ..., e13] := Succ ( A[e1, e2, ..., e13] ) They should, unless the index expressions are functions - which may have side-effects. See above. > In fact, it would be nice to have a Self for arrays as well (as for > objects), where you could write > > with A[e1, e2, ..., e13] do > Self := Succ ( Self ) It could be more generic, if you'd allow renaming declaration like Ada does: declare X : Integer renames A(e1, e2, ..., e13); begin X := X + 1; end; Well, the problem with possible side-effects would remain then. Perhaps we should introduce the notion of a pure function (like in VHDL) to give the compiler a hint that it doesn't need to recalculate all that stuff. Vinzent. -- public key: http://www.t-domaingrabbing.ch/publickey.asc pgpMSJLwHG0Le.pgp Description: signature ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] bug: Inc(v,i)/Dec(v,i)
On Friday 08 July 2005 12:24, Gerhard Scholz wrote: > - Original Message - > From: "Vinzent Hoefler" <[EMAIL PROTECTED]> > To: "FPC developers' list" > Sent: Friday, July 08, 2005 1:24 PM > Subject: Re: [fpc-devel] bug: Inc(v,i)/Dec(v,i) > > > OTOH, ... > > new abbreviation? what's that? http://www.acronymfinder.com/af-query.asp?String=exact&Acronym=otoh ;-) > With some accustomization, "inc(..." and "v := v + ..." is both good > readable, and normally (at least with checks off) it was assumed to > produce compacter and faster code. Especially when v is not a simple > variable, but a more complex one, e.g.: > Inc ( v[j]^[k].a[l], delta ) ; > And in such a case it's also better readable. Yes, if you really need to do such complex expressions. I tend to write smaller subroutines which take arguments. Vinzent. -- public key: http://www.t-domaingrabbing.ch/publickey.asc pgpaGLZ96AKdh.pgp Description: signature ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] bug: Inc(v,i)/Dec(v,i)
On Friday 08 July 2005 10:49, Gerhard Scholz wrote:
> Beside, v is word or byte, depending on a compiler-$if elsewhere, so
> I would have to write:
>
> inc ( {$ifdef big} smallint {$else} shortint {$endif }v, delta ) ;
>
> Not very clear readable.
Agreed. It's not readable at all. So don't do that, instead
{$IFDEF BIG}
type My_Type = SmallInt;
{$ELSE}
type My_Type = ShortInt;
{$ENDIF}
and then
|Inc (My_Type(v), Delta);
should do the trick.
OTOH, to be honest: I don't see the point in using Inc/Dec here at all,
especially if "v := v + Delta;" would work perfect already. I even
think the "standard" way of doing the addition would be much more
readable in that context.
Vinzent.
--
public key: http://www.t-domaingrabbing.ch/publickey.asc
pgplFJ6tp8cLb.pgp
Description: signature
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] bug: Inc(v,i)/Dec(v,i)
On Thursday 07 July 2005 21:27, Marcel Martin wrote:
> Vinzent Hoefler a écrit :
>
> > Personal note: Maybe there was a reason why Borland Pascal didn't
> > do range checks on Inc/Dec.
>
> Yes, there is always a good reason for a bug :-)
Any sufficiently advanced bug cannot be distinguished from a
feature. :-)
> If ever you changed that, i.e., if you suppressed the overflows
> with Inc and Dec, thanks to let us know explicitely (here, for
> instance).
Full ACK. They have to document it either way (and in the past they
did).
> Personally, I would have to rewrite a few lines of
> code, like, for instance, in
>
> procedure XDiv2(X: PBigFloat);
> begin
>with X^ do if not IEqu0(Mantissa) then {$Q+} Dec(Exponent); {$Q-}
> end;
Yeah. Sure. Same reason I had to rewrite:
| for i := 0 to Buf_Len - 1 do
| begin
| b := tByteArray (Buf)[i];
| Inc (C_Sum, b); { work around range check error RRG/VH 161100 }
| ComOut (P_Nr, b);
because after we decided to port the whole stuff to Linux, FPC broke the
code again. :-)
> > The only time I ever used it was a checksum
> > calculation which was modulo anyway. Any other time I use the usual
> > operators. So especially with the "added" overflow check I think,
> > Inc and Dec are pretty useless functions, because the don't do
> > anything you can't accomplish by using "+" or "-" unless you have
> > very_long_and_complex_variable_names and want to save some typing
> > work.
>
> That's a matter of habit. Not sure but I believe that with TP3,
> the compiled code was better with "Inc" than with "+".
Yes, it used a direct memory increment which was better on the
processors we used back then. Interestingly with the introduction of
the Pentium 10 years ago which (in most cases) could execute the
mem-store/reg-inc/mem-store faster than the direct in-memory-addition
this optimization fired back. Of course then it didn't matter that much
anymore, 'coz the processor was too fast already. ;-)
Vinzent.
--
public key: http://www.t-domaingrabbing.ch/publickey.asc
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
