delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp/1997/10/23/03:05:34

Message-Id: <199710230703.UAA23329@atlantis.actrix.gen.nz>
Subject: Re: Some comments and questions
To: salvador AT inti DOT edu DOT ar (Salvador Eduardo Tropea)
Date: Thu, 23 Oct 1997 20:03:39 +1300 (NZDT)
From: "Kris Heidenstrom" <kheidens AT actrix DOT gen DOT nz>
Cc: djgpp AT delorie DOT com
In-Reply-To: <m0xO00h-000S1kC@inti.gov.ar> from "Salvador Eduardo Tropea" at Oct 22, 97 03:41:18 pm
MIME-Version: 1.0

Salvador Eduardo Tropea wrote:

> "Kris Heidenstrom" <kheidens AT actrix DOT gen DOT nz> wrote:
> 
>> And it's free!  Wow!  The only thing missing is the editor, but any
>> programmer will have his/her own favourite editor already.
>
> Eli asked it very well, I'll add that: any  programmer will have his/her 
> own favourite editor already ... BUT if other editor behaves like your
> favorite and in addition have tons of usefull addtions you'll move to
> it ;-)

I would, if EMACS could work like my favourite editor, but I don't
think it can't be made to do some of the major things I like about
my favourite editor (scroll-lock, real-time program output capture,
scrollback through captured output and commands, and a few others).
These are fundamental design features and can't be added just by
binding keys :-)  Some time when I have a few days to spare I will
try it out, though :-)

>> The system and documentation all has a Unix/C flavour, which is
>> alien to me (my background is in PC real-mode assembler), but from
>> a simple "I want something that will compile my program" point of
>> view, I've had no problems so far.
>
> With RHIDE these alien files will become identical to Borland helps
> (much more slow but same look & feel).

Yes!  I just hope Borland don't try to sue RH for copying the look
and feel of Turbo Debugger!  He has done an excellent job!

>> My first test was a small (400 lines) file-sorting program that I
>> wrote for Borland C.  With very minor editing (removing 'far' and
>> 'huge' references),
>
> Did you used:
> #define far
> #define huge
> ? I'll recommend it for large sources.

I could have done that, but there were a few other issues such as
sizes of ints and longs, so for the best memory usage and execution
efficiency I added a few conditional compilation blocks with the
appropriate #defines and typedefs.  For example, farmalloc() under
Borland becomes plain malloc() under DJGPP.

>> Debugging with gdb was an experience!  I'm used to Borland's Turbo
>> Debugger and found gdb very awkward by comparison.  In fact I found
>> it quite painful to use.  It has most of the functionality of Turbo
>> Debugger (and some nice extra features) and seems to be powerful
>> enough, but the user interface is nasty (IMO).  At least it's a
>> good incentive not to write buggy programs :-)
>
> Eli pointed RHIDE & FSDB, I'll do the same.

Yes, RHIDE seems to be great.

>> Also I noticed that gdb doesn't allow you to print (or otherwise
>> access) word and byte registers - $eax works, $ax, $al and $ah
>> don't.  It says they are 'void'.
>
> RHIDE have a dissasebler window. IMPORTANT NOTE: RHIDE have gdb inside.

Right, I suspected that.  A very sensible thing to do - gdb knows all the
low-level stuff, and RHIDE "pretties it up" for the user.

>> My final program was 40KB stripped (vs. 16KB for real-mode with
>> Borland C) and the execution speed was 2.4 times that of the
>> Borland version!
>
> You can compress a DJGPP exe (making it close to 20K) use the mlp...
> program found under v2misc of the SimTel distribution.

Cool, I will try that, thanks.

>> djasm - what is it, and where is it documented?  It isn't mentioned
>> anywhere in the help, or in the (otherwise very helpful) FAQ!  Its
>> name appears in the exe stub, though :-)  Does it use Intel syntax?
>> (he asked hopefully :-)
>
> djasm is a tool to allow the creation of the whole DJGPP distribution without 
> the need of extra tools (like MASM and TASM). Isn't supposed to be used as a 
> regular tool, but can be. The syntax is close to Intel but isn't Intel. Look 
> the sources of the stub (in the sources of the libc).

Okay thanks.

>> Intel syntax support - is there a program that converts Intel-syntax
>> assembly to AT&T style?  
>
> Not usefull, normally you'll need to transalte 16 bits to 32 bits too 
> (impossible to make it automatically).

I don't agree that it wouldn't be useful.  First, there is already 32-bit
code written in Intel format.  Second, even for converting 16-bit Intel
code to AS format, converting 16-bit to 32-bit must be done manually but
is not tedious, whereas converting from Intel to AS would be tedious,
time-consuming and error-prone, and could be done by a program.  Don't
you think?

> You can use NASM or JASM to write code in Intel style and link it with
> DJGPP (for links go to my Home Page).

NASM isn't fully MASM/TASM compatible either (doesn't support ASSUME,
for starters :-), but I'll check out JASM, thanks.

>> Same questions for Intel-style disassembly for gdb.
> Hmmm... you can add it to RHIDE if you want ;-)

It already uses Intel style disassembly!

>> Info reader bug - when I invoke 'info' with a keyword it doesn't know
>> about (e.g. 'info djasm'), it reports 'bad command or filename'
>> (probably reported by command.com) then hangs.  I'm running MS-DOS
>> 6.20 and using CWSDPMI 0.90+ (r3) and info 2.16.  This seems like a
>> bug that would have been picked up by now - maybe there's something
>> strange about my setup.  Any suggestions?
>
> Use RHIDE to read info files is better for people acustomed to Borland
> tools.

Okay.  BTW Nate (I think) explained the 'bad command or file name', as
info was looking for 'man', but this doesn't explain the lockup.  It may
be a TSR incompatibity, I will investigate this.

>> CWSDPMI doesn't detect if already installed - if I install CWSDPMI when
>> it is already installed, it doesn't detect this, and installs a second
>> copy (and a third, etc if I keep installing it).  This isn't normally a
>> problem but is not good behaviour for a TSR.  Maybe it has to work like
>> this?
>
> Yes, no, why do you load CWSDPMI by hand? that isn't correct. Load it
> ones with the "permanent" switch or never and let the programs to load
> it automagically.

Well, yes and no.  Obviously CWSDPMI is designed to be able to be loaded
as a TSR as well as automagically, because it does install itself if
invoked from the command line, so what it does is still not good
behaviour.  But as I said, it's a minor point.  I shouldn't have even
mentioned it, it makes me look so ungrateful!

>> Language implementation info - the info file for the standard C library
>> is good, but I can't find any language implementation reference - for
>> example, something that will tell me what size a 'short' will be, etc.
>
> No body wrote such a text so isn't available.

Fair enough.

Thanks for your time.

Regards

Kris
-- 
Kris Heidenstrom   kheidens AT actrix DOT gen DOT nz   Wellington, New Zealand
               Electronic designer and programmer
       "Good sense is the most valuable good on the market"

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019