What's about Go32v2 or some other DOS port?
Will it supported in 2.0.x branch?

you wrote

What's about Go32v2 or some other DOS port? Will it supported in 2.0.x branch?

There is no maintainer for go32v2. Unless there is an user that steps forward to be the maintainer for go32v2 there will be no DOS release anymore.

Peter

Date sent: Sun, 22 May 2005 12:03:37 +0200
To: Ivan Shikhalev ,
"FPC developers' list"
From: Peter Vreman
Subject: Re: [fpc-devel] DOS Platforms
Copies to: Send reply to: FPC developers' list

To amend this - we're certainly willing to support such a volunteer to reasonable extent, but we just don't have sufficient bandwidth for full-featured support of this additional platform.

Tomas

Date sent: Sun, 22 May 2005 12:03:37 +0200
To: Ivan Shikhalev ,
"FPC developers' list"
From: Peter Vreman
Subject: Re: [fpc-devel] DOS Platforms

To amend this - we're certainly willing to support such a volunteer to reasonable extent, but we just don't have sufficient bandwidth for full-featured support of this additional platform.

Tomas

Alright. How much time would someone need for that task? Or, to be more specific: what is known to need high priority work to get the most basic stuff of a DOS-Compiler working?

I'm certainly willing to commit /some/ time to that task. DOS is a too-nice target, especially for embedded systems to just let it die, but I'm a little bit overworked to work on such task full time.

Vinzent.

Hard to say, since it is more getting deep knowledge and researching that is limiting. If you are very deeply intimate with DPMI and the various implementations, it will be way easier than if you are not.

Moreover, knowing the time to fix bugs, means knowing how to solve the bug,

Besides fixing the bugs, it means reading a busy internal maillist to react to new changes that also affect go32v2 so that it doesn't get behind again, and 1-2 times a year (or maybe 3-4 times a year if the new schedule keeps up) spend a day or two on building a release archive.

I'm certainly willing to commit /some/ time to that task. DOS is a too-nice target, especially for embedded systems to just let it die, but I'm a little bit overworked to work on such task full time.

The thing that needs most urgent fixing is exception handling (the various division by zero, rte 216 etc in the bugreport) I think.

Crashes with the dos extender, probably exception related, see also the go32v2 related bug reports. First step: get the 1.0.10 go32v2 compiler and try a make all with the 2.0.x branch and fix things which won't work.

I'm certainly willing to commit /some/ time to that task. DOS is a too-nice target, especially for embedded systems to just let it die,

I guess embedded systems aren't a big problem, the problem are modern windows.

The 2.0.x branch go32v2 can be build. Most problems are in the IDE being unstable and debugging (based on libgdb) not working.

I hope to start the go32v2 & win32 daily snapshots in next day or so for v2.0 & v2.1 John

This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you.

Peter Vreman said:

.
.

>> Alright. How much time would someone need for that task? Or, to be more >> specific: what is known to need high priority work to get the most >> basic stuff of a DOS-Compiler working?

.
.

The 2.0.x branch go32v2 can be build. Most problems are in the IDE being unstable and debugging (based on libgdb) not working.

Exactly. The best is to check unfixed bugs for GO32v2 target in our bug repository - the debugging problem is there, some exception handling related stuff too, plus there are some smaller issues like correction of the DiskSize implementation for LFN platforms to exclude the buggy check for DOS version being > 7.0 (it should only check availability of the particular DOS function).

Building of a more up to date libgdb might be nice, although not absolutely necessary.

Finally, if you are really brave (and have the other issues fixed), you could have a look at changes done in the latest DJGPP release to avoid problems with W2K incompatibilities (there were some changes related to memory allocation, exception handling and spawning of other programs which should supposedly cure the problems). However, we WNT/W2K/WXP are declared as unsupported environment for GO32v2, so this certainly isn't a priority (nice to have at most).

Tomas

Well, that particular one shouldn't be too much of a problem.

Ok, to round things up: I will take a look at it and come back to the mailing list later (within the next couple of days, I hope). Until then, I still can't promise anything. Probably the most time I will need in the beginning is to get familiar with the compiler sources...

Vinzent.

Op Mon, 23 May 2005, schreef Vinzent Hoefler:

... and setting up a comfortable environment to develop in. The compiler sources itself aren't that interresting, more the runtime environment end the IDE. But for now just try to run a make cycle. The Buildfaq documents it very nicely and if you've got questions, just ask.

Daniël

I can help on doing dos makes eg under win9x - I do them every day for dos snapshots.

Regards John

Ok, first status on the matter:

Tonight I've spent some time with the sources and my Win2K machine. For me it seems as the Makefile(.fpc)'s are not yet up to date for the go32v2 target (object files didn't get deleted on cleanall, some unit paths were missing, that sort of stuff) [FYI: I checked out the current 2.0.1 from CVS], but in the end I managed to make the compiler cycle manually. Hmm, well, let's see if I still remember how I did it, when I get back to it this evening ;).

Result: I get occasional seg faults (probably related to the ntvdm bug mentioned in the current djgpp, so this is definitely something to try). I can compile a simple hello world (huhu, what an achievement, but, hey, look at that matter when it's 3.30am).
Next test was to check some files from the tests/test stuff and those (very) few I checked seemed to compile quite ok. BTW, the tstring1.pp failed horribly (on successfull execution of the test, not on compilation) just like the current fpc does (don't you happen to actually run these tests?).

So it's definitely some more work to do, especially for building release version etc.pp., but at the first glance it doesn't look too hard.

I can help on doing dos makes eg under win9x - I do them every day for dos snapshots.

Well, if you could manage to send me a makefile, so that I don't have to hack it myself (using Pascal and Ada for years, I somehow got used to the fact that makefiles are mostly unnecessary complex and outdated C-related stuff), that would be nice.

It also seems, I'll get an old Win95 system up und running in the next few days, so I even can do tests for the most important environments.

... and setting up a comfortable environment to develop in. The compiler sources itself aren't that interresting, more the runtime environment end the IDE. But for now just try to run a make cycle.

Well, I just tested in on my linux box, there it runs just fine (well, with fpc2.0.0, that is). It *should* not make any difference if I use fpc1.0.10, should it? Or am I missing something here?

The Buildfaq documents it very nicely

Yes. Even I could understand it. ;-)

and if you've got questions, just ask.

Well, at the moment I'd say, I take look at the makefile, see what I do with those "error setting exception" messages and trying to compile something larger to test with. I expect hard-to-find effects soon enough.

Oh, yes. One question: Should I use the current fpc2.0.1 release from the CVS or would it be better to switch to the 2.1.x branch already to not get too far behind the current development? Just don't say "both". ;-)

Vinzent.

I've never been able to make go32v2 make work properly under w2k/xp, and neither has anyone else afaik - because of the well known bugs...Not worth trying imho - best to use real dos.

Current make cycle (just compiler & rtl) & go32v2zip (whole release) works fine under win9x - I use ME.

Both v20x and v21x and v20 release makes work at present for me, using the fpc.zip from ftp & unzipping into clear directories, using the make that's included, dos window under win me. The resulting compiler/rtl sort of works too...As you've heard exceptions cause a crash- they used to work but stopped around Feb 2005, probably when the asm calling conventions were changed for v19.

... I'd try v21x - v20x & v20 will probably then work anyway.

I'll upload v20x & v21x snapshots onto ftp.freepascal.org ... \snapshot\v21 & v20 soon.

Regards John

Our policy is to work and develop patches in the 2.1.x branch. As soon as they work, we merge them back to 2.0.x using the mechanisms of svn. But patches against 2.0.x are ok as well because I don't think that currently much people are changing the go32v2 in 2.1.x

Just put a v2.1.1 basedos.zip (compiler & rtl only) snapshot which I just made on win me, using supplied makes into ftp.freepascal.org .../snapshot/v21/. Used .../snapshot/v21/source/ . Not tested much, but it works for hello world program anyway...

Regards John

Vinzent Hoefler said:

First of all - make sure you don't use Win32 versions of the GNU tools (especially make.exe etc.) when trying to build for the GO32v2 target under WinXX. The best is to change your PATH setting within the given session. Then the existing makefiles should work out of the box.

In general, it _is_ possible to build under W2K under some conditions too (_not_ under WinNT due to missing LFN support for DOS sessions), but as you already found out, it isn't very stable and you get random crashes any time due to the NTVDM problems, so I certainly wouldn't recommend starting with this part (for building the compiler at least - Win2K etc. provide better error checking mechanisms, so e.g. SIGSEGVs can be completely undetected under W9x, whereas W2K shows them immediately; I suspect the problem with exception handlers is probably similar case, i.e. they don't work under W9x either, but this problem is only signalized under WinNT and above).

Well, at the moment I'd say, I take look at the makefile, see what I do with those "error setting exception" messages and trying to compile something larger to test with. I expect hard-to-find effects soon enough.

Makefile should be OK (see above). "Error setting exception" messages only appear under WinNT and above. That could be either result of better error checking (see above too), or an incompatibility of WinNT and above - just that you don't fall into a trap too early...

Oh, yes. One question: Should I use the current fpc2.0.1 release from the CVS or would it be better to switch to the 2.1.x branch already to not get too far behind the current development? Just don't say "both". ;-)

It shouldn't matter too much - I'd suggest to start with 2.1.x (in line with our policy as already mentioned by Florian); merging of your changes to 2.0.x should be rather easy to do later.

Tomas

Hello,

some notes on the compiler:

1.)
I tried to compile the compiler itself ("make win32zip") and found the following:

a)

the routine packages\extra\winunitsjwawownt16.pas contains the line (#55)

  {$WARN SYMBOL_PLATFORM OFF}

which is not recognized and gives an error.
I made a real comment out of it: { $WARN SYMBOL_PLATFORM OFF}

b)

the unit parabase.pas in the compiler, line# 240

    function ParaNrCompare(Item1, Item2: Pointer): Integer;

...

      begin
        Result := I1.paranr - I2.paranr ;
      end ;

gives an overflow (I compiled the whole thing with range check on, stack check on, overflow check on, and then the compler dies while compiling itself!!)

I then replace the assignment with:
   {$ifopt Q+}
     {$define OVERFLOW_ON}
     {$Q-}
   {$endif}
   {$ifopt R+}
     {$define RANGE_ON}
     {$R-}
   {$endif}
        Result:=I1.paranr-I2.paranr;
   {$ifdef OVERFLOW_ON}
     {$Q+}
     {$undef OVERFLOW_ON}
   {$endif}
   {$ifdef RANGE_ON}
     {$R+}
     {$undef RANGE_ON}
   {$endif}
This still is a hack, a cleaner solution would be:
    Result := sign ( longint ( l1.paranr ) - longint ( l2.paranr ) ) ) ;

With these modifications the "make win32zip" comes to an end and produces a lot of ZIP-files.

I wasn' able to find out why the compiler is compiled three times, the RTL even four times.

2.)

a)

The power operator (**) seems to be integrated in the compiler, but only partial. I didn't find a description of it in the Reference Manual.

I tried a little program
  PROGRAM x;
    BEGIN
     WRITELN ( 1 ** 2 ) ;
   END.
which died with the runtime error 221 (I didn't find a description of this
error, either).

Obviously the operator(s) are defined in the unit math, with a USES MATH the program runs.

Without the MATH unit the routine SYSTEM_starstar$VARIANT$VARIANT$$VARIANT is called, which seems not to work.

There are some optimizations for the power operator in nadd.pas (only for REAL ** REAL, not for INT ** INT). But since the operator is overloaded, this code is not reached...

There is missing an operator overload for REAL ** INT, which could be handled more optimized than converting it to REAL ** REAL.

b)

in pexpr.pas there is a declaration:

operator_levels:ARRAY[Toperator_precedence] OF SET OF ttoken= [_PLUS,_MINUS,_OP_OR,_PIPE,_OP_XOR],
[_CARET,_SYMDIF,_STARSTAR,_STAR,_SLASH,

_OP_AS,_OP_IS,_OP_AND,_AMPERSAND,_OP_DIV,_OP_MOD,_OP_SHL,_OP_SHR],
            [_STARSTAR] );

The _STARSTAR_ occurs two times in that sets; I assume the first occurence is a typing error.

c)

Operators of same precedence are evaluated from left to right: a - b + c - d
means:
( ( a - b ) + c ) - d
This follows the "natural" precedence of mathematical formulas. But with the power operator the "natural" precedence is from right to left: a ** b ** c ** d
normally means:
a ** ( b ** ( c ** d ) )
The FP compiler evaluates a ** b ** c ** d as:
( ( a ** b ) ** c ) ** d
This should be changed to the "natural" behaviour. Other programming languages (like FORTRAN; if I remember correctly, also the old ALGOLs) follow the right-to-left-scheme (for ** only, of course).

This can be implemented by (in PEXPR.PAS, about line# 2440):

old code:
      IF pred_level=highest_precedence THEN
        p2:=factor(False)
      ELSE
        p2:=sub_expr(Succ(pred_level),True);
new code:
      IF pred_level=highest_precedence THEN
{!!}    p2:=sub_expr(pred_level,True)
      ELSE
        p2:=sub_expr(Succ(pred_level),True);

That's all for today.

Greetings

Gerhard

Florian Klaempfl wrote

Our policy is to work and develop patches in the 2.1.x branch. As soon as they work, we merge them back to 2.0.x using the mechanisms of svn. But patches against 2.0.x are ok as well because I don't think that currently much people are changing the go32v2 in 2.1.x

Ok, if any patches get merged back into the 2.0.x tree anyway, I think it's better to start with 2.1.x already.

Vinzent.

Yeah, I did that.

I don't think so. It seems as under W2K the processor exception handlers don't get installed at all, so they can't go bogus. ;)

Makefile should be OK (see above). "Error setting exception" messages only appear under WinNT and above. That could be either result of better error checking (see above too), or an incompatibility of WinNT and above - just that you don't fall into a trap too early...

I did some checks, at the first glance it seems to be an incompatibility of the DPMI services. I'll look into that later when I get that bitchy thing working under Win9x hopefully.

Vinzent.

John wrote

Just put a v2.1.1 basedos.zip (compiler & rtl only) snapshot which I just made on win me, using supplied makes into ftp.freepascal.org .../snapshot/v21/. Used .../snapshot/v21/source/ . Not tested much, but it works for hello world program anyway...

Ok. Big thanks. I set up a Win98 yesterday. What a coincidence that a co-worker of mine just installed a new PC for his girl-friend, so he didn't need the old disk anymore. So everything is set and I can get to work. Hopefully I can report some success after the weekend or so...

Vinzent.

OK great - good luck! I've now tried v2.0.0 (the release), v2.0.x (the fixes) and v2.1.1 (latest) sources - all make 've had makes working with win95 & winme on several PCs so should be mostly ok... You may need > 128M of memory tho' 64M may work for make cycle. I've had it working for 128 up to 512M.

If you try to make go32v2zip or make cycle you may get a small problem with the supplied go32v2 gnu utilities. As part of make cycle there is a check that the current version of ppcn.exe (n=1..3) made is same as the previous one, using the diff utility. Under win9x this fails even tho' the exe's are same, except for a few odd bytes. I have a pascal version of diff which fixes this & ignores the errors - you may need this.

Also re the exception problem you'll see it if you ctrl/c out of a simple go32v2 program... it's an error in dpmiexcp.pp or system.pp caused by the assembler calling changes or system.pp changes made around v1.9.6- v1.9.8, we suspect.

To get gdb in the ide you can download libgdb for go32v2 5.2.1 from ftp fpc /contribs/libgdb... Re ide it sort of works but looks & behaves oddly in win 9x...

Regards John

Using the 2.0 compiler binaries from the website..

Free Pascal Compiler version 2.0.0 [2005/05/15] for i386

Code that compiled fine with 1.9.6 won't compile any longer. In specific, the select() routine is gone from the linux unit. I see that it still remains in the "oldlinux" unit.

Is select() no longer supported in the 2.0 branch?

Michael Preslar wrote

Is select() no longer supported in the 2.0 branch?

Try "fpselect" in "baseunix".

Vinzent.

It is.
The linux unit was replaced by the BaseUnix and Unix units, which are more cross-platform (work on all Unixes). To mark the difference, the prefix fp was prepended to all calls. So you should use fpSelect().

The baseunix/unix units are documented.

Michael.

Vinzent Hoefler said:

On Wednesday 25 May 2005 14:51, Tomas Hajny wrote:

.
.

What I meant here was that maybe W9x doesn't install them either, but doesn't provide any feedback about that failure (so you don't get these error messages when running under W9x, but the exceptions don't work there either).

Yes, either that (i.e. WinNT/2k specific issue, although I'm almost sure that these error messages were displayed when running under WinNT in the past, and I don't expect too many changes between WinNT and Win2k regarding DPMI), or some problem with calling of those DPMI services during installation of exception handlers in general (e.g. due to the different calling conventions in 1.9.2+).

Tomas

[ Charset ISO-8859-1 unsupported, converting... ]

1.9.6 didn't compile select() call in linux. This change predates 1.9.2

Thanks to Michael and Vinzent for pointing me in the right direction. :)

Op Thu, 26 May 2005, schreef Gerhard Scholz:

This unit was originally is a compatibility issue of FPC and will be fixed.

Thanks. No time to debug this at the moment :(

It was moved from the compiler to the math unit, but not properly it seems.

This was done by intention. Pascal uses a simplified order of precedence system, for example + and - are considered equal, just as * and /. After some discussion and checks what advanced calculators did, the left to right form was chosen. It cannot be changed without breaking existing code.

Daniël Mantione

Define "natural" please ? If I write 2**3**5, I probably mean 2^3^5 = (2^3)^5, not 2^(3^5). In this case, FP is "right".

Micha

Micha Nelissen wrote

Define "natural" please ? If I write 2**3**5, I probably mean 2^3^5 = (2^3)^5, not 2^(3^5). In this case, FP is "right".

Well, I guess he means that if you write it on paper, you write (view in fixed width font)

4
3
2

which indeed is 2^(3^4)

Jonas

yes, exactly like this.

and other compilers also follow this scheme, so people who convert code from other languages will have problems at a place they do not expect.

Gerhard

From: "Gerhard Scholz"
To: "FPC developers' list"
Date sent: Thu, 26 May 2005 11:18:52 +0200
Organization: gs
Subject: [fpc-devel] some little errors/notes Send reply to: FPC developers' list

Hello Gerhard

I applied this change as a temporary workaround now (plus added it to our testsuite, so that the issue doesn't get forgotten.

I wasn' able to find out why the compiler is compiled three times, the RTL even four times.

That is more or less a regression test to avoid faulty behaviour of the newly produced compiler, plus it ensures we always get the same RTL and compiler state regardless of the starting compiler and RTL versions.

Thanks for your comments/hints!

Tomas

Tomas Hajny, on Internet

On Thursday 26 May 2005 20:27, Gerhard Scholz wrote:

[**] operator precedence left-right, right-left

yes, exactly like this. and other compilers also follow this scheme,

Or doesn't compile it at all because of the possible ambiguity when there are no explicit parentheses.

Vinzent.