Mail Archives: djgpp/1997/10/23/13:53:56
"Kris Heidenstrom" <kheidens AT actrix DOT gen DOT nz> wrote:
> 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,
What scroll-lock does?
> real-time program output capture,
> scrollback through captured output and commands, and a few others).
RHIDE does it and EMACS too.
> 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 :-)
I wasn't talking about EMACS ;-)
RHIDE captures the errors and shows the line where the error is (the column too
in Ada ;-).
> >> 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!
RHIDE uses TVision, and Borland distributes it in your Web site. Additionally
we ,Robert and I, are registered Borland users, they can't sue anybody :-)
> >> 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.
Don't forget to test FSDB currently is harder to use but have some interesting
features like inspect de GDT and LDT (very pmode specific).
> >> 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.
No exactly true, gdb knows about the debug info format. The libdbg (part of
DJGPP) knows about the low level stuff. But is more or less like this.
> >> 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?
No, when I converted my MOD engine (90Kb asm) I found that the manual
convertion was the best. Anyways, if I remmember well I have a link to a
converter in my pages (I have over than 260 links).
> > 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.
JAS is derivated from NASM, just a little more flexible. Anyways both have
source so can be implemented. But ... wait a minute ... ASSUME?, that doesn't
have much sense in flat pmode ;-).
> >> Same questions for Intel-style disassembly for gdb.
> > Hmmm... you can add it to RHIDE if you want ;-)
>
> It already uses Intel style disassembly!
More or less, is Intel but with some AT&T details (is what FSDB does).
> >> 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.
Good.
> >> 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.
:-)).
Greetings, SET
------------------------------------ 0 --------------------------------
Visit my home page: http://www.geocities.com/SiliconValley/Vista/6552/
Salvador Eduardo Tropea (SET). (Electronics Engineer)
Alternative e-mail: set-sot AT usa DOT net - ICQ: 2951574
Address: Curapaligue 2124, Caseros, 3 de Febrero
Buenos Aires, (1678), ARGENTINA
TE: +(541) 759 0013
- Raw text -