Thanks for fixing bug 4118. I had to apply the attached patch to get the current svn to compile under linux
Colin

Colin Western wrote

Thanks for fixing bug 4118. I had to apply the attached patch to get the current svn to compile under linux

Thank you, applied the patch. (revision 507)

(Core: original fix not yet merged to fix branch, please check).

Michael.

I didn't merge the widestring memory handling to fixes and it wasn't wrong to do so, see the current failures :)

Florian Klaempfl wrote

I didn't merge the widestring memory handling to fixes and it wasn't wrong to do so, see the current failures :)

They don't work with checkpointer (see bug report 4125).

Martin

Anybody a suggestion how we should handle this? There was a bug report (http://www.freepascal.org/bugs/showrec.php3?ID=2423) that FPC causes problems when working with variants and widestrings and passing them to windows.

Move all FPC_CHECKPOINTER calls to a function tcg.maybe_checkpointer() that also requires a tdef as argument. Make an exception for tdef=widestring under windows.

In delphi, on windows the function NewWideString calls SysAllocStringlen to allocate the wide string. On Linux, a simple getmem is used.

When freeing the wide string, SysFreeString is used.

I don't see any other way to do it. To make the code 'system
independent' you could introduce a set of procedural variables
GetWideStringMem : Function (Len : Integer) : Pointer;
FreeWideString : procedure(var P : Pointer);

Which are set to defaults on non-win32, and which are set to 2 functions that call the appropriate windows functions.

Michael.

Peter Vreman wrote

Move all FPC_CHECKPOINTER calls to a function tcg.maybe_checkpointer() that also requires a tdef as argument. Make an exception for tdef=widestring under windows.

Does it work with pwidechar(widestring) or pwidechar(@widestring[index])? We should have an additional string type 'OLEString' or 'BSTR' on windows, 'widestring' should remain reference counted and heap based on all platforms.

That won't like people who count on delphi compatibility. Maybe we should make the widestring heap allocation through the widestring manager so heaptrace can hook it.

Florian Klaempfl wrote

That won't like people who count on delphi compatibility. Maybe we should make the widestring heap allocation through the widestring manager so heaptrace can hook it.

Then the other way around, a new widestring which is reference counted on all platforms for people like, me who count on cross platform portability. So i can write

type
 {$ifdef FPC}
 mywidestring  = FPCwidestring;
{$else}
 mywidestring = widestring;
{$endif}

and exchange 'widestring' by 'mywidestring' 10'000 times... In most times i use widestrings and not ansistrings and i estimate the performance gain of the FPC widestrings over the not reference counted delphi strings.

Hello,

I started WinCE port. Any help is appreciated.

Currently not much is done.
I added added new (empty) target wince to compiler and built crosscompiler for arm with wince target.

I have some questions:
1. What is simplest way to add wince target to makefiles? The only way I see is to edit all makefile.fpc files and add wince to them.
2. I need fakertl stuff to start.
3. Any knowledge of how to implement export,import,linker stuff for wince target?
4. Port of windows unit for WinCE?

Yury Sidorov.

Hi,

I updated source to the latest 510 revision and get the following error while compiling ARM crosscompiler:

cpubase.pas(416,65) Fatal: Syntax error, "," expected but ")" found

The error is due to type Tsubregister was changed.

Yury Sidorov.

What do you mean with all? Only the top level make files should really need extra effort. For the other Makefiles it's enough with a fpcmake of 2.1.1 svn branch to regenerate them.

2. I need fakertl stuff to start.

Well, I'am not sure how close wince to win32 is. Maybe you can start with the win32 system unit?

3. Any knowledge of how to implement export,import,linker stuff for wince target?

No. Probably the same as win32 does. Playing with the gnu c/binutils for wince would be a good starting point.

4. Port of windows unit for WinCE?

No idea how much it from win32 differs.

Fixed.

From: "Florian Klaempfl"

I do not know much about fpcmake, but as I see there is makefile.fpc file in each directory. fpcmake creates makefile files based on makefile.fpc files. Which makefile.fpc files should be changed to add new target os?

Yes, I hope actual system unit for WinCE will be based in win32 system unit. But first of all I need fpc to create working WinCE executables, so I need fake (empty) rtl to test it.

Yury Sidorov.

I think do get basic things rolling you don't need to change one but create a new one in rtl/wince

Which tool chain do you plan to use? Using the fakertl is more hazzle than starting with a real system unit :)

Maybe we should reconsider the idea of a new string type: ref. counting and containing a field contain the encoding. The widestring is very windows specific anyways.

Florian Klaempfl wrote

Maybe we should reconsider the idea of a new string type: ref. counting and containing a field contain the encoding. The widestring is very windows specific anyways.

My needs (native pascal cross platform gui with design id, internal text representation is UCS-2 for all visible components) :

- a string type which has 16 bit characters.
- is not limited in length.
- has the most possible performance on copying, allocation and deallocation.
- is compatible with pwidechar (or similar) for efficient pointer arithmetic.
- has the same behavior on all platforms.
- index can be null based (preferred).
- copy on write by accessing a character by index is not needed.
- works with checkpointer (checkpointer saves my life many times!).

This is a simple (dynamic) array of widechar!

Similar we can introduce (dynamic) array of char and (dynamic) array of 32bitchar.

Martin

Hi,

I reached significant waypoint in WinCE port.
I have Hello world application running on WinCE. :)

Here are some notes:

Official binutils seems to be buggy for WinCE target. I used binutils from Pocket GCC port and they work fine.

procedure fpc_cpuinit for ARM performs illegal instruction (rfs r0) on WinCE.
A question why this init is needed and is it needed at WinCE?

rfs r0
and r0,r0,#0xffe0ffff
orr r0,r0,#0x00020000
wfs r0

Currently I excluded this code for WinCE using ifdefs.

Yury Sidorov.

Yury Sidorov wrote

Hi, I reached significant waypoint in WinCE port. I have Hello world application running on WinCE. :)

GJ :)
Hope, you'll contribute the patches soon ;)

It turns floating point exceptions on.

Currently I excluded this code for WinCE using ifdefs.

It doesn't hurt much but you won't get floating point exceptions then.

From: "Florian Klaempfl"

I hope too :)

It is out of my knowledge now. I will defer exceptions stuff for later time...

One more question. I created 2 files t_wince.pas and i_wince.pas for WinCE target. But now I see that it will be better to add WinCE support to t_win.pas and i_win.pas files. Is it ok to do that?

Yury Sidorov.

Yury Sidorov wrote

One more question. I created 2 files t_wince.pas and i_wince.pas for WinCE target. But now I see that it will be better to add WinCE support to t_win.pas and i_win.pas files. Is it ok to do that?

Yes.

Hi,

FPC can not create smartlink library under Windows host using AR from cross-binutils for arm-wince-pe, because AR refuses to accept \ dir separator when mask symbol * is specified. Any AR compiled under cygwin has this issue.

How to solve this issue?

Yury Sidorov.

Maybe some of our mingw experts can compile arm-wince binutils :) Marco?

I built correct AR using mingw. Now I have complete set of working cross-binutils for WinCE.

Yury Sidorov.

Can you pack them and upload somewhere?

Hello,

1. Why SizeOf(integer) = 2 for ARM?

2. The following code produces wrong assemler code:

var
  i: DWORD;
begin
  i:=PDWORD($1234);
end;

The produced code for assignment is: ldr r0,[INVALID]

Yury Sidorov.

Hello, 1. Why SizeOf(integer) = 2 for ARM?

The size depends on the compiler mode. For objfpc and delphi modes it is 4.

> 1. Why SizeOf(integer) = 2 for ARM? The size depends on the compiler mode. For objfpc and delphi modes it is 4.

Yes this is due compiler mode.
Another question. Is it correct to keep SizeOf(integer)=2 in default fpc mode when most of current processors are 32bit and 64bit is coming?

Yury.

Yes. To be backwards compatible with old fpc versions we can't change the default mode to objfpc.

If you mean
i:=PDWORD($1234)^;

It's fixed now.

From: "Florian Klaempfl"

Yes. Thanks.

Yury.

Hi,

The following code produces Internal error 200312022:

var
  i: integer;
begin
  i:=PInteger(123)^;
end;

Yury Sidorov.

Fixed, hopefully I didn't destroy much because I didn't test the fix. Maybe you can create a system.s before applying the patch and diff it with a system.s from the new ppcarm.

From: "Florian Klaempfl"

system.s is generated properly as before.

But fix is incorrect. The following strange code is generated for assignment:

ldr r0,.L9
mov r3,#123
mov r1,#4
.L10:
ldrb r2,[r3], #1
subs r1,r1,#1
strb r2,[r0], #1
bne .L10
...
.L9:
.long U_P$TEST_I

Yury Sidorov.

123 is not aligned to a 32 bit boundary so byte moves are generated (try with 120 instead), at least arm-linux require proper alignment. I agree that the code is suboptimal and that it should generate 4 ld/st instructions but the code is correct imo.

From: "Florian Klaempfl"

Indeed, it must be processed in such way. With address 120 the code is much better :)

mov r0,#120
ldr r0,[r0]
ldr r1,.L9
str r0,[r1]

Yury.