Mail Archives: djgpp/2009/01/08/18:30:40
Hi again, :-)
On Jan 8, 3:24 pm, "Rod Pemberton" <do_not_h DOT DOT DOT AT nohavenot DOT cmm> wrote:
> "Rugxulo" <rugx DOT DOT DOT AT gmail DOT com> wrote in message
>
> news:886d17b9-399f-48ed-ac4d-45ca11d3879f AT s20g2000yqh DOT googlegroups DOT com...
>
> > The only problem I had is due to inexperience: I don't know how to
> > organize the actual compiler install to correctly work without -I and -
> > L hacks (i.e. I didn't want to make a C:\USR\LOCAL dir just to hope
> > it'd work). I mean, I'm wondering can you install it similar to a
> > default DJGPP install (C:\DJGPP\BIN, LIB, INCLUDE, etc.) or do you
> > have to run it like "..\i386-moss\i386-moss-gcc" ?? I'm sure somebody
> > knows, they're probably just too lazy^H^H^H^H busy. ;-)
>
> It seems Binutils 2.19 supports moss as does GCC upto 3.3.6. So, you should
> be able to build new enough versions to be useful.
3.4.x introduced optimizations for the Pentium4, I think. It's also
slower than 3.2.3 (which has some C99). And 2.95.3 supports PPro but
was the last of its branch (combined EGCS + GNU). And 3.0.2 etc. is
much bigger in size and slower. (2.96 was an unofficial patch by Red
Hat.) As you know, 2.8.1 was the first official GNU version to support
586 optimizations (since 2.7.2.1 was 486 only). Okay, enough history
lesson! :-)
I don't know what changes between releases of Binutils. Reading the
changelog a while back was unimpressive. At least for us (DOS / COFF)
I don't think anything has changed in a while. And I'm not using MMX
or SSE for this or rebuilding latest GCC, so I'm less interested in
newest. (Those probably take a lot longer to compile, too.) For this I
just used stock BinUtils srcs 2.10.1 from GNU since I don't think DJ
archives all old versions (e.g. no srcs for older than 2.15 in either /
current/ or /beta/).
EDIT: Actually, DJ's ftp seems to have older in /deleted/ (e.g. bnu27
[bs], bnu2951[bs], etc). bnu2951.README says MMX, SSE, and 3dnow! are
supported (and, surprisingly, claims to not need LFN environment to
compile).
In any case, I wanted something lean, small, and fast as well as old
enough to hopefully work but new enough to be useful. It's not that I
need Pentium-specific optimizations, but too old means new code won't
work (and vice versa). Oh, BTW, when was it that ".intel_syntax" was
added, 2.9? That is indeed worth having. :-)) This also means
the little assembly MOSS uses is AT&T (yuck).
OFFTOPIC: For instance, I recompiled GCC 2.95.3 and BinUtils 2.16.1
via "-Os" recently with the goal of producing a small 2.03p2-based
compiler that would fit on a floppy compressed. Anything older is too
moldy for my tastes, and anything newer is too big to fit. (7zdec
compiled by OpenWatcom comes in handy here. I have not yet released
the .7z on my site, though, still barely tweaking it, but it's done
and unpacks in lots less RAM now.) This was intended to be an EZ-GCC
for v2 (although I never tried v1, my first GCC was 2.7.2.1 and DJGPP
2.01? on my 486 in 1997, brrrr, compiling Allegro back then was kinda
slow, and actually 2.95.3 ain't any faster, but it's faster than 3.x
or 4.x, that's for sure.)
> But, I'm having problems. Neither DJGPP 3.4.1 nor 3.3.6 would cross-compile
> stock GCC 3.3.6 failing in the middle of compiling gcc.c complaining about
> an assignments to a read-only variable. Perhaps, I should try DJGPP GCC 3.3.6
> compiling DJGPP GCC 3.3.6 as a cross-compile, but I thought the code for GCC
> hadn't been changed for DJGPP...
I did use the stock DJGPP srcs for GCC 2.95.3, but I dunno if it
matters. Look for a \BUILD.DJG subdir with DJCONFIG.SH. I think I
modified it (barely) and then ran that. That may be your problem if
you're trying to run "configure" manually. You may also not have all
the tools it needs (cp, mv, sed). Also, GCC is pretty annoying in that
you do need specific versions to compile itself. As mentioned, try GCC
3.4.4 if later doesn't work. (I still say I could e-mail it to you.
But that path setup issue is so annoying! Anyways ....)
Comparing files djconfig.sh~ and DJCONFIG.SH
***** djconfig.sh~
export CONFIG_SHELL=bash
dft_target=i586-pc-msdosdjgpp
#
***** DJCONFIG.SH
export CONFIG_SHELL=bash
dft_target=i386-pc-moss
#
*****
***** djconfig.sh~
#
$srcdir/configure --srcdir=$srcdir --disable-shared --verbose \
--with-gxx-include-dir=\\\${prefix}/lang/cxx \
--with-gnu-ld --target=${target-${dft_target}} \
--host=${target-${dft_target}} \
--prefix=\\\$\$DJDIR
***** DJCONFIG.SH
#
$srcdir/configure --srcdir=$srcdir --verbose \
--with-gnu-ld --target=${target-${dft_target}} \
--host=i586-pc-msdosdjgpp \
--prefix=\\\$\$DJDIR
*****
I doubt the whole i386/i586 part makes a difference, but I did it
anyways. And I only wanted C, no C++, so I wiped that line and used
"sh djmake.sh LANGUAGES=c". BTW, I really suck at recompiling GCC, so
I don't honestly know what I'm doing. Or maybe it's that newer GCC has
trouble with older srcs, I dunno. In any event, I never got LIBGCC.A
to recompile, so I just used the original (old) one from the Linux
cross compiler (is that bad? is that wrong? seems to work, at least,
and I dunno what else to do).
> Binutils fails near the end of make with
> error 2. I know from past experience, that once everything is working
> correctly, those mysteriously go away. This is one reason why I prefer to
> always have binaries, but be able to get source instead of the GNU it's
> always source, and never binaries model. Even if the code won't compile
> anymore, the executable will work.
Yes, pre-built binaries are good. Of course, -static helps a lot too,
but GNU/Linux has some severe problems with bloat there (i.e. NetBSD
or Minix aren't nearly as big), dunno why (NLS? reentrancy?).
> > Anyways, I could always just e-mail you the binaries I compiled
>
> I'd rather get it to work on my machine. I've experienced similar problems
> trying to cross-build with DJGPP in the past.
There's probably a cross-build mailing list we could ask. I did
briefly e-mail Bryan (Ford) with a pretty wimpy "Hi, how's it going?"
just to see if he was still around (no response yet). That's a long
shot, though, I doubt he's still interested.
> > > If I can compile it, it should be easier to port or at
> > > least get the code to compile on newer versions. I'm not saying I can get
> > > it working or anything, just that I'll look into it.
>
> > I know, no pressure. It was all your idea anyways. Only try to have
> > some fun with it. ;-)
>
> Sorry, for some reason, I was thinking you compiled moss.exe... Actually,
> with the size of moss.exe being so small, I can't imagine all of the code he
> included actually being used. It's just a matter of determining what was
> used, since I'm not sure that it'll ever compile again in it's current form.
Recompiling MOSS.EXE doesn't give you any examples, so in order to
test it, I had to find a way to build. Of course, not sure which is
easier / better: DOS host or old BasicLinux w/ precompiled 2.7.2 /
2.6. Obviously I'm biased towards the former, but at least the latter
installs on top of DOS and is very lean.
> > You can ask
>
> ./configure --target=i386-moss
>
> ./configure --target=i386-moss --host=i386-pc-msdosdjgpp --build=i386-pc-msd
> osdjgpp
>
> What did you use or do? But, I think I might be using the wrong set of
> sources: stock GNU instead of DJGPP.
I dunno, does stock have BUILD.DJG\djconfig.sh? (GCC's SVN doesn't
have it or else I can't find it.) I would just use stock DJGPP srcs if
I were you.
> > > The MOSS version runs under MS-DOS v7.10, but has "'\n' -> '\r\n'
> issues."
>
> > I have no idea what that means.
>
> Ah, I quoted what you quoted. DOS uses both an ASCII carriage return (CR or
> \r) and linefeed (LF or \n) to move to the beginning of the next line. LF
> in DOS moves down a line. CR moves to the begining of the line. *NIX
> usually uses just LF to do both. Mac's use just CR to do both. This was a
> historical misunderstanding with early ASCII. DJGPP fixes this behind the
> scenes. So, when text just using LF is displayed, it moves down a line, but
> not to the start of the line. The text shows up as a staggered and
> wrap-around look. Think stack of domino's versus stack of domino's with a
> tilt.
I understand all that, just don't know what you're experiencing. Is
the text showing up on the screen incorrectly or being unpacked by
7ZDEC incorrectly or something else? It works in DOSBox, still haven't
tested on real hardware yet. (QEMU + FreeDOS seems to imply that
HIMEMX or JEMM386 won't work but others seem fine, go figure.)
> > Atari Lynx
>
> What? I thought you were younger than that... ;)
I'm 29. I never had a Lynx "back in the day" for whatever reason, but
it had some cool arcade ports. I even bought a used Lynx 2 on eBay a
few years ago (2004?) with games, but it eventually crapped out in
2006 or so (screen stopped working). That's what I get for buying
electronics made in 1991 !!
> >http://www.brynosaurus.com/
>
> I didn't realize he worked on vx32 also... I've read the papers and looked
> it over a few times. It, like many other open projects, has some features I
> like, but it isn't as developed as much as I'd like or going in the
> direction I'd like. In the case of vx32, they just do binary translation to
> implement their sandbox. But, with more development, vx32 could be used as
> an x86 emulator, possibly with much better performance than others.
It claims security, fast speed (even SSE supported), and portability.
He says, "porting to Windows XP should be possible", which would of
course be very very interesting. (Of course, they also intended to
port Inner Worlds to Windows 2000/NT/ME "eventually", and that never
happened.) At least the idea that FreeBSD, Linux, Linux 64-bit, Mac OS
X all work sounds pretty cool.
> > P.P.S. Sebastien, you cross-posted to the wrong group! :-P
>
> I threw on comp.os.msdos.programmer. He posted to the wrong thread there.
> His response was to Herbert Kleebauer in "Adding equal sign as a parameter."
Yeah, I didn't know you were cross posting until I saw that. Fitting
to cross post for a cross compiler. ;-)
BTW, the ELF output from MOSS doesn't run under BasicLinux, which I
vaguely hoped it would. Oh well, can't have it all.
- Raw text -