[fpc-pascal]ARM cross-compiling error
hi, I have tried to build last cvs version 1.9.4 for ARM and It can't compile I'm using ppc386 version 1.0.10 to make it! #> #> make clean all OS_TARGET=linux CPU_TARGET=arm BINUTILSPREFIX=arm-linux- #> DUMP SCREEN-- /bin/rm -f arm/*.o arm/*.ppu arm/*.rst arm/*.s arm/*.a arm/*.so arm/*.ppl /bin/rm -f arm/ppc386 arm/ppcaxp arm/ppc68k arm/ppcppc arm/ppcppc arm/ppcrossarm /trabajo/programas/freepascal/cvs/fpc/compiler/ppc -darm -dGDB -dBROWSERLOG -dNOOPT -Xs -OG2p3 -n -Fuarm -Fusystems -Fu/trabajo/programas/freepascal/cvs/fpc/rtl/linux -Fiarm -FE. -dRELEASE pp.pas rgobj.pas(1989,56) Error: Incompatible type for arg no. 1: Got "TSuperRegister", expected "TRegister" rgobj.pas(2068) Fatal: There were 1 errors compiling module, stopping make[3]: *** [ppcrossarm] Error 1 make[3]: Leaving directory `/trabajo/programas/freepascal/cvs/fpc/compiler' make[2]: *** [cycle] Error 2 make[2]: Leaving directory `/trabajo/programas/freepascal/cvs/fpc/compiler' make[1]: *** [compiler_cycle] Error 2 make[1]: Leaving directory `/trabajo/programas/freepascal/cvs/fpc' make: *** [build-stamp.linux] Error 2 -- thank you in advanced regards ___ fpc-pascal maillist - [EMAIL PROTECTED] http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal]Align instruction
Peter Vreman a écrit :
>
> > Hello,
> >
> > With v1.9.4, is there a way to align a label in an assembler
> > procedure?
>
> .align, .balign or .p2align
I forgot to tell "with {$ASMMODE INTEL}". But if I understand you
well, in order to use aligned labels, I have to (re-)write the code
with the AT&T assembler. Fortunately the .s files do exist :-)
Thanks,
--
mm
http://www.ellipsa.net/
___
fpc-pascal maillist - [EMAIL PROTECTED]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal]Win32 API Call
At 12:00 AM 6/22/2004, you wrote:
You made a few mistakes translating GetCurrentHwProfile to Pascal:
Figures it was me... :-)
1. parameter to GetCurrentHwProfile should be TProfileInfo, not
PProfileInfo (using "var" parameter already forces passing HWProfile by
reference)
That's awfully odd, because according to the Win32 API reference the
function GetCurrentHwProfile requires a pointer, which pProfileInfo is
(tProfileInfo is just the type definition). Guess I have some more reading
to do.
2. result of GetCurrentHwProfile should be LongBool (4 bytes), not boolean
(1 byte)
But in your code it's still a boolean, but it now works (it returns TRUE).
And, when I change "Results : longbool" in the var declaration I get "Hint:
Type size mismatch, possible loss of data / range check error" at the
"writeln ('Results: ',Results,' - ',GetLastError);" statement (and with
either declaration the function returns TRUE, so I assume it's working with
both). Does that mean longbool isn't really necessary?
Guess I have even more reading to do then I thought!
3. most important, TProfileInfo.GUID and TProfileInfo.Name are not
AnsiStrings. They are just char arrays, see attached code for correct
declararions.
Another oddity, because the API reference says they're null-terminated
strings. So shouldn't an ansistring work for that too?
And where did you get those length numbers from, the ones you used for
those const definitions? I can't seem to find them anywhere, and it appears
that in order to get the info to display properly you need to assign
specific lengths to those char strings.
4. This is not important for FPC 1.0.x, but for newer FPC remember to
declare WinAPI functions as "stdcall" (FPC 1.0.x just used "stdcall" by
default).
I'll make note of that.
I'm attaching corrected version of your program.
Thanks for that -- you were a big help!
Regards,
Jim Wilson
___
fpc-pascal maillist - [EMAIL PROTECTED]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal]ARM cross-compiling error
Jose Pascual wrote: hi, I have tried to build last cvs version 1.9.4 for ARM and It can't compile I'm using ppc386 version 1.0.10 to make it! Fixed. ___ fpc-pascal maillist - [EMAIL PROTECTED] http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal]Win32 API Call
Jim Wilson wrote:
At 12:00 AM 6/22/2004, you wrote:
You made a few mistakes translating GetCurrentHwProfile to Pascal:
Figures it was me... :-)
1. parameter to GetCurrentHwProfile should be TProfileInfo, not
PProfileInfo (using "var" parameter already forces passing HWProfile
by reference)
That's awfully odd, because according to the Win32 API reference the
function GetCurrentHwProfile requires a pointer, which pProfileInfo is
(tProfileInfo is just the type definition). Guess I have some more
reading to do.
It's true that GetCurrentHwProfile requires a pointer to TProfileInfo.
But when you declare GetCurrentHwProfile parameter as "var HWProfile:
TProfileInfo" then compiler understands that "GetCurrentHwProfile
(Profile);" should pass a *pointer* to Profile variable as
GetCurrentHwProfile parameter. That's what "var" in "var HWProfile:
TProfileInfo" means : to pass HWProfile by reference, i.e. by pointer.
That's why HWProfile should be of type TProfileInfo, not PProfileInfo :
it will already be passed by pointer, thanks to "var" keyword.
2. result of GetCurrentHwProfile should be LongBool (4 bytes), not
boolean (1 byte)
But in your code it's still a boolean, but it now works (it returns
TRUE). And, when I change "Results : longbool" in the var declaration I
get "Hint: Type size mismatch, possible loss of data / range check
error" at the "writeln ('Results: ',Results,' - ',GetLastError);"
statement (and with either declaration the function returns TRUE, so I
assume it's working with both). Does that mean longbool isn't really
necessary?
Guess I have even more reading to do then I thought!
In my code I changed Boolean to LongBool only in declaration of
GetCurrentHwProfile. It's not needed to change type of "Results"
variable because FPC will implicitly convert between LongBool and
Boolean types.
SizeOf(LongBool) = 4, SizeOf(Boolean) = 1. This means that Boolean and
LongBool have really different representation inside computer memory. So
GetCurrentHwProfile should really return LongBool, not Boolean. If such
code runs correctly with "Boolean" instead of "LongBool", you can
consider it an accident.
3. most important, TProfileInfo.GUID and TProfileInfo.Name are not
AnsiStrings. They are just char arrays, see attached code for correct
declararions.
Another oddity, because the API reference says they're null-terminated
strings. So shouldn't an ansistring work for that too?
They *are* null-terminated strings. But they are not pointers to some
char arrays. Instead they are just char arrays. msdn calls them "pointer
to a null-terminated string" because in C pointer to a char can be
usually considered the same thing as an array of chars.
AnsiString is something completely different: AnsiString is a pointer to
some null-terminated char array with some additional internal data
(positioned right before the pointed memory place). As Peter said,
AnsiString is something that is known only in FPC and Delphi. It's
completely different than simple "pointer to null-terminated char array"
that is usually used in C. Such "pointer to null-terminated char array"
is called PChar in Pascal. *But* TProfileInfo.Name and GUID fields are
not PChar, they are simply char arrays.
And where did you get those length numbers from, the ones you used for
those const definitions?
I discovered HW_PROFILE_GUIDLEN and MAX_PROFILE_LEN values by looking at
C headers distributed with DevCpp. You can use any C compiler
distributed for Windows to do such thing. Just find a directory inside
your C compiler with header files for WinAPI (typically this should be a
directory with "windows.h" file) and there you will find C declarations
for all WinAPI constants, types, functions, macros...
I can't seem to find them anywhere, and it
appears that in order to get the info to display properly you need to
assign specific lengths to those char strings.
I'm sorry but I don't understand this statement. In Pascal you can
usually use "array[0..]of char" just like it was a "PChar", i.e.
compiler understands that it's a char array terminated with null character.
Regards,
--
Michalis
___
fpc-pascal maillist - [EMAIL PROTECTED]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal]Win32 API Call
> That's awfully odd, because according to the Win32 API reference the
> function GetCurrentHwProfile requires a pointer, which pProfileInfo is
> (tProfileInfo is just the type definition). Guess I have some more reading
> to do.
No, it makes a lot of sense. You could use:
(var value: TProfileInfo, ...) *or* (pvalue: PProfileInfo, ...)
Passing as "var" passes the value as a pointer behind the scenes, but gives
you the chance not to mess about with casting etc. You can't do this is C
really (winapi written in C..) Not back when the Win32API was written. Back
then every C app passed by value or as a pointer to simualte by reference.
> But in your code it's still a boolean, but it now works (it returns
TRUE).
> And, when I change "Results : longbool" in the var declaration I get
"Hint:
> Type size mismatch, possible loss of data / range check error" at the
> "writeln ('Results: ',Results,' - ',GetLastError);" statement (and with
> either declaration the function returns TRUE, so I assume it's working
with
> both). Does that mean longbool isn't really necessary?
It should be boolean. All Win32API return values which are BOOL translate as
Boolean.
> Another oddity, because the API reference says they're null-terminated
> strings. So shouldn't an ansistring work for that too?
No, no, no!! AnsiString (just use "String", it's the same difference unless
you change the RTL to use WideStrings) is an array of char 1...N, with an
extra hidden 0 element. This is a hangover from shortstrings which used
element 0 to hold their length. A PChar is an array 0...N-1 or char. In my
experiance you *can* pass Strings to API calls if you pass something like
@(s[1]) or in Delphi pchar(string), but if you use them in this
Record/struct, you'll quickly find that String <> PChar.
> And where did you get those length numbers from, the ones you used for
> those const definitions? I can't seem to find them anywhere, and it
appears
> that in order to get the info to display properly you need to assign
> specific lengths to those char strings.
Generally, with a Win32API call set your PChars to point to a buffer and
tell the API call how long it is. In some structures (records) the seze is
set, or is of a specific fixed sized type.
> >4. This is not important for FPC 1.0.x, but for newer FPC remember to
> >declare WinAPI functions as "stdcall" (FPC 1.0.x just used "stdcall" by
> >default).
>
> I'll make note of that.
To be fair to you, FPC should have always used StdCall for Win32API calls.
It would be less confusing now, anyway.
Matt
___
fpc-pascal maillist - [EMAIL PROTECTED]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
