Mail Archives: djgpp/1997/10/23/03:05:34
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 -