On 9 Mar 00, at 14:50, Marco van de Voort wrote:

...

I have been having discussions with Leon de Boer who is writing most of the FreeVision (FV) stuff. The project is being done to dispense with all copyright issues, and it seems that this has largely been achieved. I have ported the Objects unit to GPC, along with a few other units. The sticking point now is a number of the base units (drivers.pas, dialogs.pas and views.pas), which contain some assembler code. Some of these are in x86 assembler and some (determined by some IFDEFs) are in FPC assembler (which looks to me like the AT&T syntax).

There is no FPC syntax. FPC uses an modified NASM based internal assembler (which can do both AT&T and Intel), and also a pass through mode (DIRECT) which copies the code to the back-end file.

Well, the FPC asm stuff that I can see looks different from the AT&T syntax in the sense that I can't see any single quotation marks there.

...

Since I understand neither of these, I can't proceed with the porting.

Send me the relevant pieces, and I'll try to pascal'ize them.

I will do that in a private email.

Could you elaborate on the GPC modifications? Are they huge?

No, they are not. Actually the changes that I have had to make are quite minimal (at least when compared to the size of the code).

One possible problem are the strings. We are touching the 255 character TP limit in the IDE, and converted it to Delphi style dynamical AnsiStrings.

I know GPC has some dynamical string, but I don't know how it works. Are they source compatible with ansistrings (auto allocate, auto deallocate?)?

Not yet. But GPC does not have a 255 character limit for strings. You can give a string any capacity that you want, but you have to specify the capacity otherwise it defaults to 255 characters.

Length(s) should return length of string, and a setlength(s,len) should be defined that sets the length of string s to "len".

All that works okay under GPC.

...

If you would like to help with porting these units, then do please get in touch. It would seem better to recode these assembler routines in Pascal than to convert the FPC assembler to something that GPC can understand (if it isn't already in that form).

In my opinion, if we can port these three units to GPC, then a working class library for GPC (which also supports several other Pascal compilers) is within reach.

Try to implement the FPC-API .

Hmmm ... I am not too sure that that is the way to proceed ...

Best regards, The Chief ----- Dr Abimbola A Olowofoyeku (The African Chief) Email: African_Chief@bigfoot.com Author of Chief's Installer Pro v5.22 for Win32 http://www.bigfoot.com/~African_Chief/chief32.htm

(I'm CC'ing this to Pierre, the fpc core group member busy with FV atm.

Pierre: GPC also got Leon's code, and I'm maling with them to examine the possibility of a joint GPC/FPC FV, this to be able to propagate bugfixes between both teams.) )

...

[...] The sticking point now is a number of the base units (drivers.pas, dialogs.pas and views.pas), which contain some assembler code. Some of these are in x86 assembler and some (determined by some IFDEFs) are in FPC assembler (which looks to me like the AT&T syntax). Since I understand neither of these, I can't proceed with the porting.

All of these assembler parts can be ported to GPC using pure Pascal without a single byte of asm code. I have done this for BP's TV.

Dr A Olowofoyeku sent me the code. He asked me to look at tview,drivers and dialogs, views and drivers

- Dialogs however doesn't seem to contain assembler (but it imports drivers, maybe that confused him) - Drivers is the hardest unit of TV afaik. The old FPC FV drivers unit is already based on an earlier version by Leon De Boer (and therefore free). It doesn't contain assembler, and is fairly small. The problem code however, is more or less stuffed away in the FPC api (which is for download in the development section of I'll sent it to Dr A Olowofoyeku for study (the API is on the FPC website), but please don't distribute it further until you get clearence from Pierre that it is in fact not contaminated with TP code (which I can hardly believe btw) - TViews contains only two short assembler procedures. Firstthat and ForEach. I checked both, and think I can make pascal versions, except for one thing. Before calling the procedures that are parameters of these two (firstthat and foreach), the asm routine pushes the (%ebp) (which is afaik the ebp of the caller, to access the callers variables????). I don't know how to do that in pascal, but it is only one or two assembler statements)

Due to "clean room" issues (and to lack of time), I am preferring not to touch the units, but if someone wants to pascalize them I can give useful hints.

I didn't. I never had anything todo with TV beyond the interface level.

I again urge you to NOT to spent to much work on it. Making FV platform independant has been done before by FPC, and it would be double work. I'm sure there is a solution without too much ugly code. I don't know how far the assembler can be eliminated, but a lot of assembler

Marco van de Voort (MarcoV@Stack.nl) http://www.stack.nl/~marcov/xtdlib.htm

How does it handle the screen? Using *curses? (That's what our portable CRT unit does.)

Only under Linux (and/or BSD in the future), but not very succesfully. (it doesn't work fully over non linux telnet.

...

• TViews contains only two short assembler procedures. Firstthat and ForEach. I checked both, and think I can make pascal versions, except for one thing. Before calling the procedures that are parameters of these two (firstthat and foreach), the asm routine pushes the (%ebp) (which is afaik the ebp of the caller, to access the callers variables????). I don't know how to do that in pascal, but it is only one or two assembler statements)

GPC can handle this in Pascal. This is a feature of ISO 7185 Standard Pascal which Borland left out.

Just pass a local procedure as a parameter to `ForEach', and call it from there. GPC will ensure that the local procedure can access its parent's local variables.

Won't this cause typing violation?

...

I didn't. I never had anything todo with TV beyond the interface level.

I again urge you to NOT to spent to much work on it.

On what?

On porting LvB's code. Wait for the initial FPC version. We are merging what was our own code from the old version and rest of LvB's code.

This will effectively mean a separation of OS-dependant from independant code, and also do this in the same way as FPC, which keeps the packages compatible.

You don't have to follow this, I just encourage you to look at the API design and e.g. drivers unit, and mail your opinion.

This way GPC and FPC can still implement the OSdependant code differently if necessary (e.g. like on go32v2, where we don't want ncurses based).

It justs sets an interface between dependant and independant code.

...

Making FV platform independant has been done before by FPC, and it would be double work. I'm sure there is a solution without too much ugly code. I don't know how far the assembler can be eliminated, but a lot of assembler

This sentence is not

:-)

A lot of assembler can be eliminated. Even some more on GPC probably because of the %ebp thing in pascal.

Check e.g. API's callspec unit, for some things like that.

With GPC, you can eliminate _100%_ of the assembler code and write everything in Pascal. The worst thing which can happen is that we need C wrappers in order to use some system libraries in a portable way. (This is necessary as long as we do not have a c2p translator with 100% automatic translation.)

The main assembler things which I fear for are things like the %ebp stuff, not the OS dependant parts. (so calling methods from a different object in this one etc)

(if you sufficiently wrapped the extender on go32v2)

Marco van de Voort (MarcoV@Stack.nl) http://www.stack.nl/~marcov/xtdlib.htm

...

...

Just pass a local procedure as a parameter to `ForEach', and call it from there. GPC will ensure that the local procedure can access its parent's local variables.

...

Won't this cause typing violation?

What to you mean ? Of course types will be checked. Look on attached program. It's CORRECT pascal's (standard pascal, not even "pascal with GPC extensions") program. If you'll change x:integer to x:real in first line it'll be not correct pascal parogram and GPC will complain. In GPC you can use not just declaration in procedure's header but also pointers to procedures/functions and such and will work just fine with embedded functions (just like in GCC).

I mean that changing the TYPE of both methods will cause other procedures to fail, causing an incompability with FV.

Keeping the argument a untyped pointer, and then typecasting to a proctype will probably not work, since the mechanics of passing of the "local" procedure is probably based on the parameter being a procedure type.

---

Remarks: - Only two TGROUP (foreach and firstthat) methods are affected, and both methods aren't listed under their own names in tp help, and only accessable via tgroup, so they could be meant as internals. - For Collection.FirstThat in objects.pas the same problem seems to be solved for GPC while keeping a pointer as parameter. Marco van de Voort (MarcoV@Stack.nl) http://www.stack.nl/~marcov/xtdlib.htm

...

I mean that changing the TYPE of both methods will cause other procedures to fail, causing an incompability with FV.

Keeping the argument a untyped pointer, and then typecasting to a proctype will probably not work, [...]

It does work.

How does it work effectively? So something like:

procedure proc1(x:longint);

procedure proc2(x:longint);

begin end;

begin end;

type myproctype=procedure(x:longint);

procedure proc3(x:pointer);

begin myproctype(x); end;

begin proc3(@proc1); proc3(@proc2); end;

Marco van de Voort (MarcoV@Stack.nl) http://www.stack.nl/~marcov/xtdlib.htm