[fpc-pascal] Lo
Hi Is there a reason why the lo function returns the lo word from a longint in FPC and not the lo byte as in Delphi. Regards Carsten -- Delphi 5 Doc -- function Lo(X): Byte; Description Lo returns the low-order Byte of the argument X as an unsigned value. X is an expression of type Integer. Fpc 224 Doc -- Synopsis: Return low byte/word of value. Declaration: function lo(B: Byte) : Byte function lo(i: Integer) : Byte function lo(w: Word) : Byte function lo(l: LongInt) : Word function lo(l: DWord) : Word function lo(i: Int64) : DWord function lo(q: QWord) : DWord ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Lo
On 11 Jan 2011, at 10:38, Carsten Bager wrote: Is there a reason why the lo function returns the lo word from a longint in FPC and not the lo byte as in Delphi. It was decided/implemented before Delphi existed and when FPC's main goal was still to become a 32 bit alternative to Turbo Pascal. Maximal Borland compatibility was not as high on the list at the time as trying to "fix" the language where we believed Borland made a bad decision. Getting the lower word seemed (and still seems, to me at least) more logical and useful for longints than returning the lower byte, hence the decision. Furthermore, lo() is implemented as an inline function in the system unit, which means that its result cannot differ depending on the language mode of the current source file. It could be changed into an internal compiler intrinsic so the behaviour differs for different syntax modes, but nobody has ever cared enough about this difference to make that change. This and other similar differences are also documented at http://www.freepascal.org/port.var Jonas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] The new Delphi 2010 RTTI
To split some hairs ;) Level the OS's with an addition (or some additions) and program the universal application on top of that. This makes the application lighter AND portable. Regards / Cees (who has no practical experience with fpc-pascal/Lazarus/Freepascal i.e. a lurker) On 01/10/2011 11:05 AM, michael.vancann...@wisa.be wrote: > > > On Mon, 10 Jan 2011, Vincent Snijders wrote: > >> 2011/1/10 alexv...@mail.ru : >>> But I want packages to be binary portable between OS (on target >>> processor >>> architecture) >> >> >> I don't think that is feasible, unless you don't use any OS features. > > Exactly. > > Even just because FPC supports multiple CPUs; You can't use an i386 > package on SPARC or ARM. > > So you'll always have to recompile your package for all platforms that > you want to support. > > Michael. > ___ > 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] The new Delphi 2010 RTTI
On 01/10/2011 12:09 PM, michael.vancann...@wisa.be wrote: > > > On Mon, 10 Jan 2011, alexv...@mail.ru wrote: > >> 10.01.2011 13:50, michael.vancann...@wisa.be пишет: >>> >>> >>> On Mon, 10 Jan 2011, alexv...@mail.ru wrote: >>> 10.01.2011 13:05, michael.vancann...@wisa.be пишет: > > > On Mon, 10 Jan 2011, Vincent Snijders wrote: > >> 2011/1/10 alexv...@mail.ru : >>> But I want packages to be binary portable between OS (on target >>> processor >>> architecture) >> >> >> I don't think that is feasible, unless you don't use any OS features. > > Exactly. > > Even just because FPC supports multiple CPUs; You can't use an i386 > package on SPARC or ARM. > > So you'll always have to recompile your package for all platforms > that you want to support. > > But only for all processors, not for all existing combinations of processor and OS. >>> >>> You should re-read Florian's email, and *fully* understand the >>> consequences. >>> >>> Your proposal requires that we emulate all OSes on all other OSes, >>> because >>> the basic package (rtl or whatever it will be called) always depends >>> on the OS. There is no way around this. >>> >> My solution, in short, is that packages should have OS independent >> interface to RTL built into executable visible to packages as RTL >> built as c package (with is a bridge to real RTL). > > I understood that. Assuming you can make this interface (which I don't > believe), your solution is still not realistic: > > And how will you make a package that uses a os-specific function OS > independent ? (for instance, a package with a control that uses a WinAPI > call.) > > So a package with the LCL is by definition impossible. > > Like I said, your proposal requires that we emulate all OSes on all > other OSes. Looking from the top (the user), is that not what is done now? All applications have the same user-interface for different OS's. So by definition what is in-between is part application and part 'normalisation' of the OS. Regards / Cees (who has no practical experience with fpc-pascal/Lazarus/Freepascal i.e. a lurker) > > Michael. > > > > ___ > 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: Re[4]: [fpc-pascal] Help building fpc svn Win64
> -Message d'origine- > De : fpc-pascal-boun...@lists.freepascal.org [mailto:fpc-pascal- > boun...@lists.freepascal.org] De la part de José Mejuto > Envoyé : mercredi 5 janvier 2011 17:42 > À : FPC-Pascal users discussions > Objet : Re[4]: [fpc-pascal] Help building fpc svn Win64 > > Hello FPC-Pascal, > > Wednesday, January 5, 2011, 4:50:20 PM, you wrote: > > > DB> On Jan 5, 2011, at 12:07 PM, José Mejuto wrote: > >> Anyway I was looking for mingw binutils for win64 in the website > >> without success, only win32 builds. > >> http://sourceforge.net/projects/mingw/files/MinGW/BaseSystem/GNU- > Binutils/binutils-2.21/ > > DB> try: http://mingw-w64.sourceforge.net/ > > I had solved it using the files from freepascal ftp server > ftp://ftp.freepascal.org/pub/fpc/contrib/cross/mingw/win64/ but even > when those files are added to the "bootstrap" they are not copied to > the newly created compiler via install, so lazarus projects fail to > compile (some) due the lack of GoRC.exe in example. You should be able to use the 32-bit version of GoRC there is no need of a 64-bit version, as the compiler adds the "/machine amd64 " option when calling it for win64 OS target. Could you test this out? Pierre Muller ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re[6]: [fpc-pascal] Help building fpc svn Win64
Hello FPC-Pascal, Tuesday, January 11, 2011, 12:21:19 PM, you wrote: PFP> You should be able to use the 32-bit version of GoRC PFP> there is no need of a 64-bit version, as the compiler PFP> adds the "/machine amd64 " option when calling it PFP> for win64 OS target. PFP> Could you test this out? Yes, 32 bits version works fine, but the "problem" is that the user should search across wikis, messages and other resources the missing files. While in win32 everything needs is in an snapshot, for x64 versions you need the 32 bits snapshot and 64 bits one, and add to the 64 bits version the missing tools (taken from the 32 bits). It's just a matter of make it simple. -- Best regards, José ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
