Mail Archives: djgpp/2011/11/28/18:45:09
Hi,
On Nov 28, 4:23 pm, tm <thomas DOT mer DOT DOT DOT AT gmx DOT at> wrote:
> On Nov 12, 6:08 am, Rugxulo <rugx DOT DOT DOT AT gmail DOT com> wrote:
>
> > On Nov 11, 4:20 pm, tm <thomas DOT mer DOT DOT DOT AT gmx DOT at> wrote:
>
> > > I have released a new version of Seed7: seed7_05_20111111.tgz
>
> BTW: Sorry for my delayed answer, I was off-net.
That's fine, I guessed as much. Hope you have been enjoying the
holiday season.
> I installed DJGPP under Windows XP, to test it.
> I use the original make.exe from DJGPP/bin to execute mk_djgpp.mak
> (with C:\DJGPP\bin\make -f mk_djgpp.mak). When I use your patch I
> get error messages.
Sadly, my XP machine died, so I can't (easily) test XP, so for now I'm
only testing native FreeDOS. Traditionally, MS-DOS and clones have
wimpy shells that don't support quoting in a consistent matter. Worse
is lack of "2>" stderr redirection, which is why DJGPP comes with
REDIR.EXE (though it has some oddball errors in some cases here). CMD,
Bash, and 4DOS all support stderr redirection natively, but most
people don't consistently use those, so it's hard to standardize on a
solution, which is why I recommend sticking to REDIR, DJECHO, etc.
(which all come with stock DJGPP by default) if at all possible.
I haven't checked too closely, but are *.cerrs files disabled for
DJGPP (or don't work) due to the above?
> About your other changes to "mk_djgpp.mak":
> - Is the option -g not supported by your DJGPP gcc?
> My DJGPP gcc supports it.
> - Why do you use the option -s (Remove all symbol table and
> relocation information from the executable)?
Ignore that, it was just a whim, not important here. It doesn't matter
for runtime memory anyways (IIRC).
> - Does the comment /* backslash (ASCII) */ make problems?
> I added this comment to show the meaning of the value 92.
It was being expanded into file names under Bash. I don't know why I
even used Bash, I guess I just expected it to behave better since your
development seems fairly POSIX / *nix heavy. I don't honestly think I
need Bash, though, and I've not used it in recent attempts here.
> - As I already mentioned \' and \" do cause problems under XP.
I don't know, it's easy to get confused, esp. because Make, Bash, and
COMMAND.COM are all fighting over who controls stdout.
> GET_CC_VERSION_INFO can be used to determine the version of the
> actual C compiler.
Don't know, it's confusing, I'd have to test some more. It was just
giving me "ambiguous redirect" error under Bash, but it may not be a
huge problem otherwise.
To capture (almost) all output messages, I just now did this (under
DOSEMU):
redir -eo hi chk_all | tee blah.txt
> > HI INTERPRETER Version 4.5.8856 Copyright (c) 1990-2011 Thomas Mertes
> > compiling the compiler - okay
> > chkint - okay
> > chkflt
> > *** The interpreted chkflt does not work okay:
>
> Some floating point functions should (according to IEEE 754), return
> NaN. Seed7 relies on the features of the C library. This error shows
> up, when the C floating point library does not work according to
> IEEE 754 rules.
Right, probably just a silly bug in DJGPP, probably not hugely
important here.
> > ***** NaN does not work correct
> > Negative zero does work correct.
> > chkstr - okay
> > chkprc - okay
> > chkbig
> > *** The interpreted compiler was not able to compile chkbig
>
> > *** The compiled compiler was not able to compile chkbig
>
> Probably this was caused by the "No swap space!" error you
> mentioned. To prove this you can call
>
> hi comp chkbig
>
> manually. The file tmp_chkbig.cerrs or tmp_chkbig.lerrs may
> contain helpful information. Please tell me, when the Seed7
> compiler (comp.sd7) itself crashes.
The compiler never crashed, or at least not in my book on how you'd
say "crash". It just uses a fair chunk of RAM, apparently, which is
causing (on my weird PC) some oddball errors from CWSDPMI r7 (DPMI
host). Old CWSDPMI r5 and HDPMI32 have different or no (!) errors,
respectively, in the same instance. Update: I also just now finally
tested again in DOSEMU, and there chkbig and chkset compile fine. N.B.
Under pure DOS, the interpreter seems to handle these tests fine, e.g.
"hi chkbig" or "hi chkset" with r7, but the "compiled compiler" (?) is
the one that confuses CWSDPMI r7 ("No swap space!", see its dalloc.c).
Charles seems vaguely interested, but I'd be surprised if he could
find time (and I have no idea). It may just be something dumb and/or
with silly workaround like limiting (!) total free RAM (as most other
DPMI hosts don't nearly recognize 4 GB like r7 claims to.)
P.S. I had to "dpmi -m 0x7f000" under DOSEMU else DJGPP would run out
of memory. (Sadly, 4.6.2 is a bloated pig and needs a lot, esp. with -
O2. But I'm not sure -O1 would help in this case, a few random tests a
week or so back may have actually performed worse or hung. Ugh, so
confusing.)
> > chkbool - okay
> > chkset
> > *** The interpreted compiler was not able to compile chkset
>
> > *** The compiled compiler was not able to compile chkset
>
> See my comment regarding compilation of chkbig above.
It's something to do with available memory. Though indeed I have the
space, it's not being allocated properly. I honestly don't think GCC +
Seed7 is using that much overall, and esp. since it succeeded under
DOSEMU with same toolset with only 500 MB RAM free, it must be just a
random allocation issue. I'm only running XMGR (XMSv3) and CWDPMI r7,
nothing else, no EMM386 (though I am also running UIDE cache driver,
which I doubt conflicts here).
> > chkexc
> > *** The interpreted chkexc does not work okay:
>
> > ***** gets from write only file succeeded
> > ***** gets from write only file succeeded
> > ***** getln from write only file succeeded
> > ***** getwd from write only file succeeded
> > ***** gets from UTF-8 write only file succeeded
> > ***** gets from UTF-8 write only file succeeded
> > ***** getln from UTF-8 write only file succeeded
> > ***** getwd from UTF-8 write only file succeeded
DOS doesn't have write-only files. ;-)
> > ***** length for pipe succeeded
> > ***** bigLength for pipe succeeded
> > ***** seek for pipe succeeded
> > ***** seek for pipe succeeded
> > ***** tell for pipe succeeded
> > ***** bigTell for pipe succeeded
> > ***** length for pipe succeeded
> > ***** bigLength for pipe succeeded
> > ***** seek for pipe succeeded
> > ***** seek for pipe succeeded
> > ***** tell for pipe succeeded
> > ***** bigTell for pipe succeeded
>
> This errors are caused by weaknesses in the underlying C library,
> respectively in DOS.
Right. DJGPP does have popen(), but I can't remember how well it works
(or if buggy). It's definitely a kludgy slow workaround here (for
DOS), sadly, but hey, it almost works sometimes. ;-)
> I really want to improve "mk_djgpp.mak", such that it works for you.
> But I think it should also work for DJGPP under Windows (that way I
> can test it also). Please help me, to reach that goal.
My aunts' live nearby and still have an XP computer, so I can
presumably test there. It's not hard, obviously, just confusing (silly
redirection and quoting quirks). It could be a Make issue as I think
DJGPP always tried to hide from / workaround COMMAND.COM whenever
possible.
- Raw text -