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" Cc: djgpp AT delorie DOT com In-Reply-To: from "Salvador Eduardo Tropea" at Oct 22, 97 03:41:18 pm MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Precedence: bulk Salvador Eduardo Tropea wrote: > "Kris Heidenstrom" 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"