Re: [fpc-pascal] syscalls and fpc
OK, so why don't you just say that you do not understand ?! Let me start again. I never said that you, Micha, Daniel, Peter, Florian, or even the big bad wolf should implement all of the given syscall functions in the each platform in the world. The design of Do_SysCall at this time is hurting the usage of syscalls, for 3 reasons: 1. There is a support only for up to 6 parameters (plus the instruction itself). 2. It support only integer base parameters, while you can not pass pointers, chars, array, record or floating point types. 3. Each OS changes/add/remove functions frequently, so assuming one of the above making the functions unusable for anything that is not an integer and up to 6 parameters. (If you do not understand my points please ask, and I'll try to clear it up) Now one *example* (that caused me to notice this issues) is the following: extern int inotify_add_watch (int __fd, const char *__name, uint32_t __mask) (Inotify is a Linux *only* feature that allows you to listen to any file system event on request, and it replacing the dnotify event, that had many issues). So as you can see by the Do_SysCall function(s): function Do_SysCall(sysnr,param1,param2,param3,param4,param5,param6:TSysParam):TSysResult; external name 'FPC_SYSCALL6'; They unable to give you an answer to the above deceleration. So my questions are (still): 1. Is there a way to implement the above with array of const ? 2. Is there a way to implement the above without using assembly, and if you must use assembly, then is there a way to use array of const inside the assembly, and if so, how ? As you can see, I still haven't requested anyone to do it for me, I'm only trying to figure out how to achieve the above request with syscall using FPC ! Here is a small way to do it btw, but it will be problematic with records (if you use assembly): function Do_SysCall(sysnr : TSysParam; const param1,param2,param3,param4,param5,param6) : TSysResult; external name 'FPC_SYSCALL6'; The problem is of course the number of bits that the registers can store in them (32 bit in i386 and 64 bit on x86_64). So when Micha mentioned the registers, I asked if my knowledge is valid, that you can do the following: push param1 push param2 push param3 ... push param6 And as you can see, you do not need to use specific register, but the system handle the bits for you. I hope you do understand the problematic design of Do_SysCall, and I hope you now understand what I'm asking and talking about. If you do not understand any point, please ask instead of arguing. Regardless of that, I do not expect FPC to have implementation of 100% of each system SysCall, because if I require to use a syscal, I'll call it,. or bind it: function Do_SysCall(sysnr : TSysParam; const param1,param2,param3,param4,param5,param6) : TSysResult; external; That way, it will be binding to he running environment of Linux or any other supported system. However I do not like this method, and therefor I prefer the usage of syscall instead. Ido On Feb 16, 2008 2:31 AM, Marco van de Voort [EMAIL PROTECTED] wrote: On Feb 16, 2008 2:00 AM, Marco van de Voort [EMAIL PROTECTED] wrote: way it assumes the number of parameters and also the type of them, so as I asked before, how I can either call the syscall command without assembler, or how I can pass an array of const (prior to that I asked regarding array of TSysParam) to assembly if three is no other way to use syscall ? So we can write you up as volunteer to write up prototypes (and worse maintain them) for about 300 calls per OS per arch? So what you are saying is, that because there are many commands that can be used by syscall, you prefer to give support only to the ones that actually in use by most programs, rather then to write something more general that will support everything, and will do it right ? There is no need to support all of them in the first place, and with formal typing and support, also maintaining the structs come into play, making a testsuite etc. Nothing that supports everything is easy, and nothing is ever exactly right once reality comes crashing in, except the helicopter view before actually getting your hands wet. Sorry but I still don't understand... The problem is the design/approach of the way syscall is implemented in FPC, while you are saying that because there are so many OS/commands that each use it differently, you just want to leave it as-is because it works for you No, because it works period. So according to what you say, I can either mark that there is no support for syscall in FPC (half work for most of the times is not enough, it's just wrong desgin), or I don't understand whats going on. I still haven't the faintest clue what your problem actually is, aside from style issues. Sure it is not the neatest solution, but neither are syscalls in general. gcc solves it slightly better with heaps of macros and custom
Re: [fpc-pascal] syscalls and fpc
ik schreef: OK, so why don't you just say that you do not understand ?! You don't understand. Let me start again. I never said that you, Micha, Daniel, Peter, Florian, or even the big bad wolf should implement all of the given syscall functions in the each platform in the world. The design of Do_SysCall at this time is hurting the usage of syscalls, for 3 reasons: 1. There is a support only for up to 6 parameters (plus the instruction itself). Yes, and for i386 that is the limit, dictated by the hardware. 2. It support only integer base parameters, while you can not pass pointers, chars, array, record or floating point types. Syscall pass registers, which are integers, so I don't see the problem. 3. Each OS changes/add/remove functions frequently, so assuming one of the above making the functions unusable for anything that is not an integer and up to 6 parameters. Which syscall has more than 6 parameter or a parameter that does not fit in a register? (If you do not understand my points please ask, and I'll try to clear it up) See above, I think I don't understand. Now one *example* (that caused me to notice this issues) is the following: extern int inotify_add_watch (int __fd, const char *__name, uint32_t __mask) Is this a syscal with 3 parameters that fit in a register? So as you can see by the Do_SysCall function(s): function Do_SysCall(sysnr,param1,param2,param3,param4,param5,param6:TSysParam):TSysResult; external name 'FPC_SYSCALL6'; They unable to give you an answer to the above deceleration. So my questions are (still): 1. Is there a way to implement the above with array of const ? Why? Not needed. 2. Is there a way to implement the above without using assembly, and if you must use assembly, then is there a way to use array of const inside the assembly, and if so, how ? Why? Not needed. As you can see, I still haven't requested anyone to do it for me, I'm only trying to figure out how to achieve the above request with syscall using FPC ! Here is a small way to do it btw, but it will be problematic with records (if you use assembly): function Do_SysCall(sysnr : TSysParam; const param1,param2,param3,param4,param5,param6) : TSysResult; external name 'FPC_SYSCALL6'; The problem is of course the number of bits that the registers can store in them (32 bit in i386 and 64 bit on x86_64). So when Micha mentioned the registers, I asked if my knowledge is valid, that you can do the following: push param1 push param2 push param3 ... push param6 No, you cant't because the kernel expects the parameters in the registers and put them on the stack. The rest *I* did not understand, so I snipped it. For your example, I expect you to write a wrapper like (taken one at random): function fpugetrlimit(resource : cInt; rlim : PRLimit) : cInt; begin FpUGetRLimit := do_syscall(syscall_nr_ugetrlimit, TSysParam(resource), TSysParam(rlim)); end; Something like: function fpinotify_add_watch (__fd: cint; __name: pchar; __mask: cuint32) : cint; begin fpinotify_add_watch := do_syscall(syscall_nr_inotify_add_watch, TSysParam(__fd), TSysParam(__name), TSysParam(__mask)); end; Vincent ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Empty record inside another record ?
To me it seems like some kind of trick, to extend a record at runtime. The empty record field, functions as a sort of offset/label/pointer if you will to the new fields that will will be extended to the record by simply allocating more memory then the size of the record. Then this label/field can be used as a sort of offset, by typecasting it to some extension record type. Could be pretty handy, quite impressive trick. However, is it safe to use ? I cannot find anything in the documentation about this ? Seems to be an old trick as well. Gonna copy this stuff and ask on free pascal compiler list, maybe they know something about this ;) I wonder if free pascal supports this trick as well ;) Bye, Skybuck. Skybuck Flying [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Hello, What's going on here: type TsomeRecord = record SomeField : integer; SomeEmptyRecord : record end; end; How can SomeEmptyRecord be usefully used ? What is it ? SizeOf(TsomeRecord) returns 4, kinda weird ?! Bye, Skybuck. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Empty record inside another record ?
Op Fri, 15 Feb 2008, schreef Skybuck Flying: To me it seems like some kind of trick, to extend a record at runtime. The empty record field, functions as a sort of offset/label/pointer if you will to the new fields that will will be extended to the record by simply allocating more memory then the size of the record. Then this label/field can be used as a sort of offset, by typecasting it to some extension record type. Could be pretty handy, quite impressive trick. However, is it safe to use ? Empty records are valid Pascal. I cannot find anything in the documentation about this ? Nothing in the documentation says it is forbidden either. The reason it is not explicetely mentioned is because there exists a much better method, objects: type base_structure=object field1:byte; end; extended_structure=object(base_structure) field2:byte; end; Daniël___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] New local-indexes support for sqldb
Op woensdag 13-02-2008 om 14:59 uur [tijdzone -0600], schreef Jesus Reyes: --- Joost van der Sluis [EMAIL PROTECTED] escribió: Hi all, fpc 2.3.1 and 2.2.1 now have local indexes support for sqldb. (TBufDataset) I would like it if you can test if it works ok for you before we release fpc 2.2.2. Maybe is not related to this feature but there seems to be mem leak: Call trace for block $4049E860 size 135 $08070601 TRACEALLOCMEM, line 1177 of ../inc/heaptrc.pp $08066DA4 ALLOCMEM, line 295 of /home/prog/fpc/rtl/inc/heap.inc $0826C3E5 TBUFDATASET__INTALLOCRECORDBUFFER, line 625 of bufdataset.pas Can you test if it's fixed in r10340? Joost ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] New local-indexes support for sqldb
--- Joost van der Sluis [EMAIL PROTECTED] escribió: Op woensdag 13-02-2008 om 14:59 uur [tijdzone -0600], schreef Jesus Reyes: --- Joost van der Sluis [EMAIL PROTECTED] escribió: Hi all, fpc 2.3.1 and 2.2.1 now have local indexes support for sqldb. (TBufDataset) I would like it if you can test if it works ok for you before we release fpc 2.2.2. Maybe is not related to this feature but there seems to be mem leak: Call trace for block $4049E860 size 135 $08070601 TRACEALLOCMEM, line 1177 of ../inc/heaptrc.pp $08066DA4 ALLOCMEM, line 295 of /home/prog/fpc/rtl/inc/heap.inc $0826C3E5 TBUFDATASET__INTALLOCRECORDBUFFER, line 625 of bufdataset.pas Can you test if it's fixed in r10340? Joost It is, :) Thanks. Jesus Reyes A. ¡Capacidad ilimitada de almacenamiento en tu correo! No te preocupes más por el espacio de tu cuenta con Correo Yahoo!: http://correo.yahoo.com.mx/ ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] syscalls and fpc
ik schrieb: 1. There is a support only for up to 6 parameters (plus the instruction itself). Which syscall has more parameters? 2. It support only integer base parameters, while you can not pass pointers, chars, array, record or floating point types. Did you just calculate how much functions it would take to support all these combinations besides the fact that no kernel function takes e.g. floats. 3. Each OS changes/add/remove functions frequently, so assuming one of the above making the functions unusable for anything that is not an integer and up to 6 parameters. Example? Did you realize that the linux supports _only_ one calling convention: taking the syscall number in a register and the other parameters in the remaining six registers? 1. Is there a way to implement the above with array of const ? Just add typecasts and a wrapper. Array of const is slow and not suitable for such low level stuff. 2. Is there a way to implement the above without using assembly, Just add type casts. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] syscalls and fpc
On Feb 16, 2008 10:03 PM, Florian Klaempfl [EMAIL PROTECTED] wrote: ik schrieb: 1. There is a support only for up to 6 parameters (plus the instruction itself). Which syscall has more parameters? I don't know, but then again, up until now I did not require to use syscall on my own (at least using FPC, because I used write using pure assembly). But now that I do require, I found a design that I find it problematic. But as I understand, I'm the only one that think there is a problem, so I'll give up and I'll not bother you on this again. 2. It support only integer base parameters, while you can not pass pointers, chars, array, record or floating point types. Did you just calculate how much functions it would take to support all these combinations besides the fact that no kernel function takes e.g. floats. Exactly my point on the design in the first place. The corrent design takes integers only. Regarding the Linux Kernel, I did not knew about the floating points issues, but what about pointers, arrays, structs etc ? 3. Each OS changes/add/remove functions frequently, so assuming one of the above making the functions unusable for anything that is not an integer and up to 6 parameters. Example? Did you realize that the linux supports _only_ one calling convention: taking the syscall number in a register and the other parameters in the remaining six registers? Yes and no, I did used assembly with syscalls for write (several years ago), but I can't find any documentation about syscall that write about it. In fact the only documentation I did found (even using google and not only using man. However on man 2 syscalls I found the following line: It is different with select and mmap. These use five or more parameters, and caused problems the way parameter passing on the i386 used to be set up. At the end of the above paragraph: These days passing five parameters is not a problem any more, and there is a __NR__newselect (used by libc 6) that corresponds directly to sys_select() and similarly __NR_mmap2. So originally the problem was 5 parameters not 6 ! and there are functions that might have more then 6 parameters, but they recommend an alias that uses less, and points to the original functions. BTW, why the C function uses var_args and not using overloads or other magic to pass the valid amount of parameters ? int syscall(int number, ...); And there are changes for every type of bit: On newer platforms that only have 64-bit file access and 32-bit uids (e.g., alpha, ia64, s390x) there are no *64 or *32 calls. Where the *64 and *32 calls exist, the other versions are obsolete. The manual is dated to 2002-01-07 (I copied it from the man page). 1. Is there a way to implement the above with array of const ? Just add typecasts and a wrapper. Array of const is slow and not suitable for such low level stuff. OK 2. Is there a way to implement the above without using assembly, Just add type casts. Ido -- http://ik.homelinux.org/ ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] syscalls and fpc
On 16 Feb 2008, at 21:55, ik wrote: Exactly my point on the design in the first place. The corrent design takes integers only. Regarding the Linux Kernel, I did not knew about the floating points issues, I don't know of a single OS kernel which supports using floating point in kernel space. but what about pointers, arrays, structs etc ? Pointers are the same size as TSysParam. There are no system calls which take arrays, structs etc. These days passing five parameters is not a problem any more, and there is a __NR__newselect (used by libc 6) that corresponds directly to sys_select() and similarly __NR_mmap2. So originally the problem was 5 parameters not 6 ! They added usage of ebp only later on. and there are functions that might have more then 6 parameters, Which ones? BTW, why the C function uses var_args and not using overloads C doesn't support function overloading. or other magic to pass the valid amount of parameters ? int syscall(int number, ...); Function overloading is no more magic than varargs. And there are changes for every type of bit: On newer platforms that only have 64-bit file access and 32-bit uids (e.g., alpha, ia64, s390x) there are no *64 or *32 calls. Where the *64 and *32 calls exist, the other versions are obsolete. I don't understand what what this has to do with the way system call interfacing works. Jonas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] syscalls and fpc
On Saturday 16 February 2008 14:55:24 ik wrote: On Feb 16, 2008 10:03 PM, Florian Klaempfl [EMAIL PROTECTED] wrote: ik schrieb: 1. There is a support only for up to 6 parameters (plus the instruction itself). Which syscall has more parameters? I don't know, but then again, up until now I did not require to use syscall on my own (at least using FPC, because I used write using pure assembly). But now that I do require, I found a design that I find it problematic. But as I understand, I'm the only one that think there is a problem, so I'll give up and I'll not bother you on this again. If the way the syscall routine works is a problem for you, then you are going to have to take that up with the Linux kernel guys. Free Pascal is only interfacing to something that the Linux kernel provides, and it's provided by the kernel in that very strict, very rigid manner. It doesn't matter what language you use, Pascal, C, or whatever, to perform a system call you must put some integer values into processor registers and perform an interrupt (if I recall correctly without looking it up, int $80). There's no getting around how that works. I beg your pardon if I'm misunderstanding the complaint. Best regards, Pete C. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Pascal Translator for Virtual Machines
I finally setup a SourceForge project for the PTVM: https://sourceforge.net/projects/ptvm/ Right now it's at beta 0.3, and can translate and compile (with MTASC) a simple Hello World application. I'm working on translating types, sentences, etc. I'm using SVN since I have more experience with it. Please let me know if you need anything to test or contribute. Regards! -Marco ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Pascal Translator for Virtual Machines
Hi Marco, Im glad to see that, Ill check out and keep in touch. []s Cesar Romero I finally setup a SourceForge project for the PTVM: https://sourceforge.net/projects/ptvm/ Right now it's at beta 0.3, and can translate and compile (with MTASC) a simple Hello World application. I'm working on translating types, sentences, etc. I'm using SVN since I have more experience with it. Please let me know if you need anything to test or contribute. Regards! -Marco ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] syscalls and fpc
ik wrote:
I think that the entire design of the Do_SysCall is malformed in the
way it assumes the number of parameters and also the type of them, so
as I asked before, how I can either call the syscall command without
assembler, or how I can pass an array of const (prior to that I asked
regarding array of TSysParam) to assembly if three is no other way to
use syscall ?
{/= SigTimedWait =\}
{ }
{\/}
function SigTimedWait (
var SigSet : BaseUnix.tSigSet;
Info: BaseUnix.pSigInfo;
var TimeOut : BaseUnix.tTimeSpec) : BaseUnix.CInt; inline;
begin
{$HINTS OFF} // I fucking *know* that most conversions below are not
// portable, so there is no need for the compiler
// telling me that crap. After all, this portion is
// unportable code by design anyway. ;)
exit (SysCall.Do_SysCall (
SysCall.Syscall_Nr_RT_SigTimedWait,
SysCall.tSysParam (@SigSet),
SysCall.tSysParam (Info),
SysCall.tSysParam (@Timeout),
SysCall.tSysParam (KERNEL_EXPECTED_SIGSET_SIZE)));
{$HINTS ON}
end {SigTimedWait};
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
