[fpc-pascal] Flushing serial inque on Linux
Hello, I am trying to flush the serial inque on Linux with no success. So far I have: procedure FlushInQue(lHandle: Longint); var QueSelector: Longint; begin QueSelector:= TCIFLUSH; Fpioctl(lHandle, TCFLSH, @QueSelector); end; I can read incoming characters, so the connection is ok and lHandle is valid. I tried TCIOFLUSH as another QueSelector and tried also ioctl instead of Fpioctl. BTW, I am new to Linux (Ubuntu 6.06) and not really sure, which units I have to include: baseunix, oldlinux unix. I tried several combinations. Thanks, Bernd. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Some features I use daily in FPC I hope never go away!
I Hope the following never goes away - I use this stuff all the time!
Types
-
Cardinal, Pointer, Integer
Always evaluate to the endian in use.
SizeOf(Cardinal)=SizeOf(Pointer)=SizeOf(Integer)
Offsets
---
If I have a record or a class - and dereference the pointer "nil" I can
always get the actual offset for a data element! I LOVE THIS.
Example:
---CODE BEGIN
Type rtMyRecord = record
saMyName: ansistring;
saMyEmail: ansistring;
end;
var rMyRecord:=rtMyRecord;
lpMyRecord: pointer;
uMyCardinalOffset: cardinal;
begin
lpMyRecord:=getmem(SizeOf(rtMyRecord));
uMyCardinalOffset:=cardinal(@rMyRecord(nil^).saMyEmail);
end;
---CODE END
You can do the same thing with a class, without the carat "^" symbol. This
is not such a big deal for many people because you can access the record or
class elements like this:
rMyRecord(lpMyRecord^).saMyEmail:='[EMAIL PROTECTED]'; However, there are
times when I use a generic routine - that works with ansistrings generally -
or binary chunks - like searching memory for a specific integer value.
I'm able to write a generic routine - that can search an array of pointers
to class instances or record types, and pick out the element to seek out
based on the offset.
--- CODE BEGIN
// Sample function definition to look at a specific element
function bFindAnsistring(
p_saSearchFor: ansistring;
p_lpStructureWithAnsiToSearch: pointer;
p_lpOffset: pointer;
): boolean;
...
// Sample usage of offsets - in a ansistring search routine for a known
"structure type"
if bFindAnsistring('[EMAIL PROTECTED]', lpMyRecord,
@rMyRecord(nil^).saMyEmail) then
begin
writeln('FOUND IT')
end;
--- CODE END
And this is cool because the above call to bFindAnsiString function can be
designed for Ansistrings - and use the value passed in lpMyRecord and add
the passed offset using the nil trick above - to get the actual address of
the ansistring. So, in this mock up function bFindAnsistring, you could
write the contents of the element like this if you chose to (Just to
demonstrate why I think this is neat)
Code Begin
// Sample function definition to look at a specific element
writeln(Ansistring(pointer(cardinal(p_lpStructure)+cardinal(p_lpOffset))^));
// another example
bFindAnsistring:=(p_saSearchFor =
Ansistring(pointer(cardinal(p_lpStructure)+cardinal(p_lpOffset))^));
Code End
I have used this technique to write two main search functions in my own base
classes - one for binary searching - I use for everything NON-ansistring,
And another, like above - for ansistring. Ansistring has it's own rules - so
I try to let freepascal handle the slicing and dicing - and only use
pointers - not to "find the data" but to let the compiler know I mean the
Ansistring at this address. My tests show that this works fine - and doesn't
seem to screw up freepascals' reference counts and stuff (e.g. I don't get
memory leaks for accessing ansistring this way)
I just wanted to share that - and how much I love these abilities in FPC to
date. I hope this "raw power" stays available. Its basically fancy pointer
math - but - its nicer than c/c++ way - and shows how you can do all the
C/C++ dirty pointer tricks - rather cleanly in free pascal.
BASEADDRESS+OFFSET=YOU Are HERE
Best Regards,
Jason P Sage
Best Regards,
Jason P Sage
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
[EMAIL PROTECTED]
Sent: Wednesday, February 21, 2007 3:05 AM
To: fpc-pascal@lists.freepascal.org
Subject: fpc-pascal Digest, Vol 30, Issue 25
Send fpc-pascal mailing list submissions to
fpc-pascal@lists.freepascal.org
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
or, via email, send a message with subject or body 'help' to
[EMAIL PROTECTED]
You can reach the person managing the list at
[EMAIL PROTECTED]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of fpc-pascal digest..."
Today's Topics:
1. Re: Advantages of Pascal (Jonas Maebe)
2. Re: Advantages of Pascal (Dani?l Mantione)
3. Re: Wikies (Felipe Monteiro de Carvalho)
4. Re: Wikies (Florian Klaempfl)
5. Re: Wikies (Felipe Monteiro de Carvalho)
6. Re: Wikies (Florian Klaempfl)
7. open array and 2.1.1 (Joao Morais)
8. Re: Wikies (Felipe Monteiro de Carvalho)
9. Re: Advantages of Pascal (Marco van de Voort)
--
Message: 1
Date: Tue, 20 Feb 2007 20:09:51 +0100
From: Jonas Maebe <[EMAIL PROTECTED]>
Subject: Re: [fpc-pascal] Advantages of Pascal
To: FPC-Pascal users discussions
Message-ID: <[EMAIL PROTECTED]>
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
On 20 feb 2007, at 19:46, Patrick Leslie Polzer wrote:
> 1) "No Makefiles"
> ...and yet you ship a Makefile generator with FPC. Why?
Becau
Re: [fpc-pascal] Some features I use daily in FPC I hope never go away!
Op Thu, 22 Feb 2007, schreef Jason P Sage: > I Hope the following never goes away - I use this stuff all the time! > > Types > - > Cardinal, Pointer, Integer > Always evaluate to the endian in use. > SizeOf(Cardinal)=SizeOf(Pointer)=SizeOf(Integer) This isn't true: * Cardinal: is always an unsigned 32-bit integer * Pointer: can be 32-bit or 64-bit depending on processor * Integer: is a signed 16-bit or 32-bit integer depending on compiler mode > I just wanted to share that - and how much I love these abilities in FPC to > date. I hope this "raw power" stays available. Its basically fancy pointer > math - but - its nicer than c/c++ way - and shows how you can do all the > C/C++ dirty pointer tricks - rather cleanly in free pascal. Did we announce plans to disable it? :) No, in general we don't remove functionality, especially if it is usefull. So, don't worry. Daniël___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Some features I use daily in FPC I hope never go away!
Hi, Am Donnerstag, den 22.02.2007, 13:18 -0500 schrieb Jason P Sage: > I Hope the following never goes away - I use this stuff all the time! > > Types > - > Cardinal, Pointer, Integer > Always evaluate to the endian in use. > SizeOf(Cardinal)=SizeOf(Pointer)=SizeOf(Integer) > > > Offsets > --- > If I have a record or a class - and dereference the pointer "nil" I can > always get the actual offset for a data element! I LOVE THIS. > > Example: > ---CODE BEGIN > > Type rtMyRecord = record > saMyName: ansistring; > saMyEmail: ansistring; > end; > > var rMyRecord:=rtMyRecord; > lpMyRecord: pointer; > uMyCardinalOffset: cardinal; > begin > lpMyRecord:=getmem(SizeOf(rtMyRecord)); > uMyCardinalOffset:=cardinal(@rMyRecord(nil^).saMyEmail); > end; > > ---CODE END > > You can do the same thing with a class, without the carat "^" symbol. This > is not such a big deal for many people because you can access the record or > class elements like this: > rMyRecord(lpMyRecord^).saMyEmail:='[EMAIL PROTECTED]'; Since you're fiddling with low level stuff and I had a problem similar a while ago: Do you see a way of calculating the offset using types instead of variables? Using your example I would like to use something like: uMyCardinalOffset:=cardinal(rtMyRecord.saMyEmail); This would be much cleaner with respect to reading the resulting code. The HDF5 library makes heavy use of calculating offsets of record members. Currently I'm using prototype variables, but that is kind of unhandy and a difference in usage between Pascal and C I want to avoid, if possible at all. TIA, Marc ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Flushing serial inque on Linux
> I can read incoming characters, so the connection is ok and lHandle is > valid. I tried TCIOFLUSH as another QueSelector and tried also ioctl > instead of Fpioctl. termio.tcflush but that does fpioctl(fd,TCIOflush,pointer(qsel)); > BTW, I am new to Linux (Ubuntu 6.06) and not really sure, which units I > have to include: baseunix, oldlinux unix. I tried several combinations. baseunix, but there is some terminal stuff abstracted from exact *nix version in termio. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Some features I use daily in FPC I hope
Daniel Mantione Wrote: >This isn't true: >* Cardinal: is always an unsigned 32-bit integer >* Pointer: can be 32-bit or 64-bit depending on processor >* Integer: is a signed 16-bit or 32-bit integer depending on compiler mode And you are absolutely correct. I forget this because I have the FPC configuration set to always use the 32 bit sized integer. As for Cardinal being only 32bit - that stinks because it's a major oversight on my part. Is there a data type equivalent to Cardinal for 64-bit? I mean - I tried to use a gambit of "processor size" independent variables for doing "low level" stuff - like pointer math. Cardinal - Unsigned, can use write statements, can convert to and from text - perfect. Is there anyway it could be made 64bit? Or Platform size independent variables could be made besides pointer? Darn...this means code I thought was all nicely converted for 64 bit - is going to be useless. ...sigh... Then what I was thinking was wrong. I hope someday there is a platform size based variable like pointer is for Cardinal and Integer. --- Marc Santhoff Wrote: >Since you're fiddling with low level stuff and I had a problem similar a >while ago: >Do you see a way of calculating the offset using types instead of >variables? Using your example I would like to use something like: >uMyCardinalOffset:=cardinal(rtMyRecord.saMyEmail); Not quite - more like: uMyCardinalOffset:=cardinal(rtMyRecord(nil^).saMyEmail; I'n not sure I answered your question - and it is very clean mark - however, as the above states - I just got correct by Daniel on something that just impeded my ability to take my code to the 64 bit level without some major work. I was mistakingly under the impression that Pointer, Integer, and Cardinal - would grow with the platform size like pointer does. This limits me as to what I can do for fancy pointer operations - as there isn't much in the way of converting a pointer to a platform sized unsigned integer safely on 64bit platform. This is rather upsetting. My fault... but upsetting nonetheless. I do hope I answered your question - I mean, if I understood your original question about getting the offset with types versus variables - I think the syntax I wrote above does what you are asking. Best Regards All, Jason P Sage ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Some features I use daily in FPC I hope
> As for Cardinal being only 32bit - that stinks because it's a major > oversight on my part. Is there a data type equivalent to Cardinal for > 64-bit? I mean - I tried to use a gambit of "processor size" independent > variables for doing "low level" stuff - like pointer math. qword is 64-bit ptrint and ptruint are processor sized types (32-bit on 32-bit and 64-bit on 64-bit) for pointer math. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] dis - Advantages of Pascal
Since the advantages of pascal were being discussed I thought I'd mention some of the things that make me choose C over pascal for some things. I don't actually think of these as 'pascal sucks because x'. It's more of 'We need to add x' It's more compiler than language based. 1. Inline functions. C supports a lot more here a lot of it comes from the #include based architecture, to do the same thing to Pascal you'd need to store a lot more in the compiled unit. There's work there for someone. 2. SIMD support. I really don't know if this is something that should be added to FPC or not. If I knew that SIMD was here to stay I'd say definitely. The tricky bit is it should be a way to system independently generate SIMD code for different Instruction sets and to generate standard non SIMD implementations for targets that lack the instructions. It would also be interesting to see if there would be optimization gains for the compiler using some sort of SIMD support at the language level even generating non SIMD code. Any extension would effectively be giving extra information to the compiler about what is being done. That can't hurt can it? 3. Umm I dunno. Guess that's why I love Pascal :-) Of course there's the template-ey thing but that's been done to death. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] dis - Advantages of Pascal
Op Fri, 23 Feb 2007, schreef Neil Graham: > Since the advantages of pascal were being discussed I thought I'd mention some > of the > things that make me choose C over pascal for some things. > > I don't actually think of these as 'pascal sucks because x'. It's more of > 'We need to add x' > It's more compiler than language based. > > 1. Inline functions. C supports a lot more here a lot of it comes from the > #include > based architecture, to do the same thing to Pascal you'd need to store a > lot more > in the compiled unit. There's work there for someone. We've got a inline procdir? Or are you referring to macros? > 2. SIMD support. I really don't know if this is something that should be added > to FPC or > not. If I knew that SIMD was here to stay I'd say definitely. The tricky > bit is it should > be a way to system independently generate SIMD code for different > Instruction sets and > to generate standard non SIMD implementations for targets that lack the > instructions. > It would also be interesting to see if there would be optimization gains > for the compiler > using some sort of SIMD support at the language level even generating non > SIMD code. > Any extension would effectively be giving extra information to the > compiler about what is > being done. That can't hurt can it? There exists a Vector Pascal compiler. They basically extend the language with features to do vector operations, allowing them to do ground-breaking performance. The Vector Pascal extenstions are under our consideration, however, we need the infrastructure in the compiler first. Until then, take a look at Vector Pascal itself. Daniël Mantione___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] dis - Advantages of Pascal
Daniël Mantione wrote: We've got a inline procdir? Or are you referring to macros? inline has the potential to do the trick but it's harder than something from a #include based system because with an include system the compiler actually gets to see the original code and can do a lot more. I do admit it appears I'm a bit behind the times since things have gotten better since last I looked. The docs now say "As of version 2.0.2, inline works accross units." and barring the typo that's a great improvement. Does it actually store object or source code for use across units? Transferring the source across allows optimizations with the surrounding code that may not otherwise be possible. There exists a Vector Pascal compiler. They basically extend the language with features to do vector operations, allowing them to do ground-breaking performance. The Vector Pascal extenstions are under our consideration, however, we need the infrastructure in the compiler first. Until then, take a look at Vector Pascal itself. I was unaware of Vector pascal. Googling it is getting me broken links, not a good sign. Any idea if it's possible to share units between fpc and vector pascal? ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] dis - Advantages of Pascal
Op Fri, 23 Feb 2007, schreef Neil Graham: > Daniël Mantione wrote: > > We've got a inline procdir? Or are you referring to macros? > > > inline has the potential to do the trick but it's harder than something from a > #include based > system because with an include system the compiler actually gets to see the > original code > and can do a lot more. > > I do admit it appears I'm a bit behind the times since things have gotten > better since last > I looked. The docs now say "As of version 2.0.2, inline works accross units." > and > barring the typo that's a great improvement. Does it actually store object or > source code for > use across units? Tree nodes. This is a machine representation of the Pascal source. > Transferring the source across allows optimizations with > the surrounding code that may not otherwise be possible. Indeed, more and more inline optimizations become possible nowadays. > > > There exists a Vector Pascal compiler. They basically extend the language > > with features to do vector operations, allowing them to do > > ground-breaking performance. The Vector Pascal extenstions are under our > > consideration, however, we need the infrastructure in the compiler first. > > Until then, take a look at Vector Pascal itself. > > > I was unaware of Vector pascal. Googling it is getting me broken links, not a > good sign. The site seems down indeed. I'd try again within a while. > Any idea if it's possible to share units between fpc and vector pascal? Vector Pascal is a compiler that does not focus on Borland compatibility. It does implement the critical Borland features though (like units). So, if you limit yourself to use basic language features, code exchange might be feasible. Daniël___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
