Mail Archives: djgpp/2010/10/15/10:45:34
Hi, (and yes I meant to cc to djgpp group also, not just followup,
sorry)
On Oct 15, 5:48=A0am, tm <thomas DOT mer DOT DOT DOT AT gmx DOT at> wrote:
>
> It is a port of the P4 Pascal compiler not Pascal_S.
> All this things work, but the do not work with the
> officially released Seed7. Don't hold your breath. It will take some
> time.
That's fine, I was just curious, not impatient. BTW, I guess you also
know about Scott Moore's updating of P4 to full ISO 7185, aka P5. But
I digress ....
> > On Oct 12, 8:48 am, tm <thomas DOT mer DOT DOT DOT AT gmx DOT at> wrote:
>
> I will try to improve the next release so that fewer changes for DJGPP ar=
e necessary (see below).
In theory, it should be pretty easy, just disable stuff that doesn't
work, and hopefully at least a vanilla interpreter (without GUI
bindings, etc.) would be buildable. In practice, it takes some effort.
(Thankfully DJGPP + GCC etc. does most of this for us.)
> You are right, the interpreter does not need this things. The
> interpreter can definitely be provided as executable.
That's good, something easy to play with interactively without having
to build anything.
> > Of course, I would personally link statically if
> > at all possible, but I realize that's not probably going to happen.
>
> This is going to happen when I find a way to configure the Seed7
> compiler independent of the interpreter.
You probably already knew this, but the DJGPP one is indeed static.
(No, I didn't use DJELF, but that exists if you're really curious.
DXE3 is yet another ball of wax.) In particular, I was thinking of
Linux and *BSD, where I think sometimes dynamic libs are a burden,
esp. Linux with a billion semi-incompatible distros.
The advantage of DJGPP should be obvious: DOS, OS/2, Win32, Linux
(DOSEMU), DOSBox, QEMU, etc. But some people don't even like the
"idea" of DOS, even when it works!
> > TinyC/TCC works on Windows and is an extremely small download. You
> > could always bundle that.
>
> From time to time I think over bundling Seed7 with a C compiler.
> But this would IMHO lose more than it wins. Currently C is used
> as platform. When a C compiler is bundled the processor is the
> platform. And I dont want to maintain a C compiler on several
> processors and operating systems.
You shouldn't have to worry, but in reality it might be (slightly?)
easier to bundle TCC. It's small and works, at least more or
less. ;-) I'm just saying, if you're really concerned about
compiling, that would be easier. But it's not like Cygwin is (too)
hard to install either, just takes a lot longer (esp. on slow
connections). Even MinGW isn't that minimal anymore. (At one time it
was 15 MB minimum, I think, not sure nowadays.) EDIT: Oops, just to
remind you that OpenWatcom exists too (albeit with little POSIX
support, but it can't be worse than MinGW in that regard, can it?).
It's not that I expect you to bundle a compiler, the interpreter alone
is sufficient for most (or even all) purposes. Just it might make it
easier to have an easy-to-install compiler.
> > I also made a one-floppy DJGPP install (GCC
> > 2.95.3) with Make, but that's probably too old. But hey, if you can
> > get it working, that should be easy to bundle too. Those are much more
> > "minimal" than MinGW or Cygwin. But it depends on how much POSIX you
> > need / expect / want (2008? mmap?).
>
> mmap is used optionally and fork is not used, but some other POSIX
> stuff is used. Since you made the one-floppy DJGPP install you have
> probably much more knowledge about it.
Doubt it! ;-) All I did there was just 7zip as much as I could cram
in 1.4 MB. I think DJGPP supports (older) POSIX, circa 1992 standard,
except for obvious things like fork, which most DOSes lack. But of
course things like mmap (required by 2008?) don't work either. People
shouldn't forget that we can live without some of these "modern"
things. (Or at least nobody needed it bad enough to write their own.)
For the record, it's been said that DPMI 1.0 could handle / fake mmap,
but a). almost nobody fully supports DPMI 1.0, even Windows and OS/2,
b). nobody has bothered writing an mmap routine for DJGPP (probably
due to lack of OS support). It would probably be easier to hack
CWSDPMI (if I knew how, mind you), but like I said, then it will only
work in "pure" DOS (or DOSBox). Well, not sure about DOSEMU or
FreeDOS-32, they probably work. And DPMIONE is freeware (closed src)
at least. And HDPMI has some 1.0 stuff too. Okay, so it's not
impossible, but I personally am too dumb, and volunteers are low. :-
(
> When you send me results (like you did with the DJGPP port)
> I can do improvements for the next release to make it easier.
Not sure what results you want, you'll have to be more specific! I
7zip'd everything (very raw) for you. It was a "quick" hack. I kept
at it just in the hopes that "somehow" it might actually work! And
having a (mostly) working result was very good news, even for
me! :-)
> Is it okay to add your makefile to the next release as mk_djgpp.mak?
> When I have not time to try it I can add it to the release and
> mention it as experimental makefile.
You can add whatever you like. It's just that there are some things to
be aware of that DOS or DJGPP lack vs. Linux and Win32 (which have
everything and the kitchen sink thrown in). Like I said, even MinGW
isn't really "minimal" in my eyes.
> > Here's my (srcs + .o files + .EXE) built with DJGPP:
>
> >http://drop.io/bsbuwco
> >http://rapidshare.com/files/424908618/seed7-djgpp.7z
>
> > (if neither of those two work for you, email me)
>
> The first one worked. Maybe not everybody knows the .7z format (I
> know it, but on my Linux system it was necessary to install 7Zip).
> I did a diff to see your changes.
I would've done a diff for you, but I figured an actual build (in
fact, the exact same as I made) was better, temporarily, esp.
with .EXE. That way you could see if it's even worth diff'ing!
BTW, I figured .7z wasn't too exotic, so I wasn't worried. p7zip
provides Linux binaries on its SourceForge site. I don't want to say
it's "easy" to compile (G++, ugh), but it works. (Yeah, most distros
don't provide GCC/G++ by default, doh.) Heck, there's a port to DJGPP
too (hi Khusraw! and yes, even of 9.13, too bad nobody mirrored it for
FreeDOS yet, I don't have iBiblio FTP rights or else I would've
already done it). There's also 7zdecode (ANSI C, public domain!) from
the LZMA SDK, which I compiled with various compilers (though I
neglected Linux, mainly focused on DOS / Win32), which is much
smaller / easier to build.
> You obvously did symlinks for some *.s7i files from the seed7/prg
> directory to the seed7/lib directory. This links are not necessary
> when the file version.h contains
>
> =A0 #define SEED7_LIBRARY "<< insert absolute path of seed7/lib >>"
Well, either Seed7's HI has to live in its own directory or you have
to have a way to find the include files. Personally, I'd make it a
runtime environment variable, e.g. SEED7_INCLUDE, so you could change
it, instead of hardcoded. I didn't bother even checking if "make
install" was available since I just assumed it wouldn't do the right
thing anyways. (Normally they just do --prefix=3D/dev/env/DJDIR"). It
was just easier to symlink. (Normally I would just hard copy the
files, but luckily 2.04 doesn't need that, heh, saved some space. If
somebody cared for 2.03p2 though ....)
> In the file fil_rtl.c (function offsetSeek) you renamed the
> parameter offset to ofset. Is offset predefined? To avoid future
> problems with this parameter the next release will rename it to
> anOffset.
I don't remember, it might be. I know there was something else that I
had to change from "offsetOf" to "int" so GCC wouldn't bork. And some
other minor changes like that. It wasn't very professionally done, I
was just hacking to see if I could shut it up so to actually
build! ;-)
> In the files kbd_inf.c, kbd_poll.c, scr_inf.c and trm_inf.c you
> changed the line
>
> =A0 #include "ncurses/term.h"
>
> to
>
> =A0 #include "term.h"
>
> This is the job of INCL_NCURSES_TERM so the line
>
> =A0 #undef =A0INCL_NCURSES_TERM
>
> should be enough and the changes in the 4 files are unnecessary.
Normally DJGPP only uses PDcurses, which I had installed, but after
various errors that I didn't understand (perhaps my fault, I admit),
and once I saw ncurses mentioned (Linux favorite), I found it easier
to just temporarily install Blair's unofficial port. Of course, he
didn't stick to conventional DJGPP package layout (no *.mft, etc), so
I guess I installed it incorrectly, hence the tweaking of the files.
It didn't seem correct (in my mind) to put it in yet another subdir (/
ncurses/), so I didn't. I just put the libs in /lib/ and the includes
in /include/, seemed more obvious to me. But like I said, that's
probably non-standard, so my bad. I just wanted to get it working,
so ....
> The next release will add an empty function for drwGenPointList to
> the file drw_dos.c . This way your change in drw_drv.h should not
> be necessary.
I don't remember. It was just to stop GCC from whining, help it find
what it needed (kbdGetc or whatever). It seems obvious that you always
expect a GUI available, which slightly complicated things, even for
the little ol' interpreter. ;-)
> Many thanks for your effort. Please keep up with your work.
It wasn't much, but I'll help more (if possible). I'm not a POSIX
guru. I'm not able to write complex interrupt handlers. I just hack
and hack and hack until GCC shuts up. Yeah, C is not my favorite
language. Even all the *nix stuff kinda overcomplicates everything.
Unavoidable these days. It's hard to simplify when everything is
already so complex.
It's just that I feel silly when something supports POSIX and GCC and
doesn't work in DJGPP. It makes me wonder, "Why not?" That (blind)
hope is the only reason I tried (well, and some experience building
other things in the past few years). DOS might be weak, but if it runs
GCC + Emacs + p7zip + Quake, how bad can it be??
- Raw text -