Recommendation for Code/Text Editor?

In that period, say in 1968-1975+ timeframe, things were transitioning to hardware-supported stacks and stack frames. Machines dating prior to this period generally didn't have hardware support for stacks (at least, not very well thought out); machines dating after this period pretty much all did have some hardware support for stacks. And the PDP-11 was a master stroke of well-considered genius on this score and on crafting an instruction and register set around a 16-bit word and stacks.

But during this period, it was necessary to spend time educating programmers on the wide-ranging value of stacks and to provide some practical and theoretical insights into concepts such as coroutines and stack frames. So the document writers spent some serious effort in educating, as well as documenting. Modern documents just don't bother anymore, so this is a real loss in having widely available teaching materials. I still keep my old manuals for the PDP-11, PDP-8, and so on because of the great deal of teaching materials that was often included in them.

Regarding the PDP-11, I just checked my PDP-11 documentation and find that they *do* discuss (vaguely, not getting too specific) this issue of modifying the first location of a subroutine in a section on reentrancy, which is where they see a huge gain in using stacks to avoid "self modifying" code areas (which prevents the ability to have a single copy of a subroutine used by several programs.) So your memory seems generally right on this note.

These manuals discuss the intimate details of shared code among tasks and processes, coroutines, position independent code, stacks and subroutine linkage concepts, reentrancy, recursion, and so on. Modern manuals seem to tersely document details which, if you read between the lines, could arise to such an understanding. But the old docs take the time to gently lead you by the nose through all this, with pictures and examples in separate sections, so that it is quite clear and sensible. Too bad there aren't similarly good places to go in modern doc sets.

The PDP-11 post-dates the HP 21xx processors by a handful of years and represents the tour de force that changed the minds of any remaining stragglers on the subject of hardware stack support. It had powerful hardware support for the stack concept. But I still love the HP front panel. Soft but firm square momentary push-buttons with incandescent lights inside that indicated the address or data. To change a data value, you merely pressed the button and the bit value toggled and the light changed state. Direct, instant feedback, sensible for human use, easy on the hand.

Jon

IIRC, the PDP-11 JSR instruction had the link register specified in the instruction. The instruction pushed the register and copied the return link into the same register. If the register specified was the PC (r7), it was a simple return address push.

--

Tauno Voipio
tauno voipio (at) iki fi

I'm using CodeWright

I haven't found anything better. Visual Studio is not bad, its biggest problem is that it's made by Mircosoft. CodeWarrior just sucks.

If you don't wanna pay, you can try kdevelop ...

Toni.

If VS is "not bad", then on the same scale, Eclipse is "outstanding".

...and Eclipse is free:

I quite disagree. The DEC PDP-6 (and the follow-on, PDP-10) from 1964, not to mention the Burroughs B5000 from 1961 (designed to be programmed in Algol, not assembler), were stack-oriented and very elegant. More so than some later machines.

My own experience during that time is indeed limited. But for what it is worth, _many_ of the machines I worked on did NOT support stacks in hardware. So I know for a fact that the concept had NOT yet swept the field. By the mid-1970's, it had.

Jon

**** Post for FREE via your newsreader at post.usenet.com ****

Hi,

I recommend CodeWright 7.5. It is really powerful.

-- Mike Walters

StringDB - Localization Tools for Embedded Developers

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= *** Usenet.com - The #1 Usenet Newsgroup Service on The Planet! ***

Unlimited Download - 19 Seperate Servers - 90,000 groups - Uncensored

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

Does anyone know if the Watcom IDE editor is available as a separate, standalone program?

It's not just "available" as one, it *is* rather obviously a standalone program: viw.exe. That's why its integration with the rest of the IDE is so mind-bogglingly limited. The IDE doesn't even manage to bring the editor window to the front when you double-click a compiler error, nor can you run "build" on a keypress inside the editor window!

Why anyone would want viw instead of, say, gvim or ntemacs, though, evades me ;-)

--
Hans-Bernhard Broeker (broeker@physik.rwth-aachen.de)
Even if all the snow were burnt, ashes would remain.

It's better then edit?

Where does one find info about gvim and ntemacs?

Those are versions of /vi/ and /emacs/. A few words of experience (wisdom??) might be in order.

In twenty years, no matter what platform you end up using, there

*will* be a /vi/ and and /emacs/ of some kind. If you learn one of them now, in twenty years what you'll have is a *lot* of experience using an editor that can do anything you want.

Learning any other editor is a waste of time by comparison because those two are in a class all by themselves. Basically once you develop sufficient skill at using one of them, you'll never have a need to switch to another editor.

The problem then, is which one to use, and getting past the very steep learning curve that either of them can present. They are

*very* complex, and after years of use you probably will not have more than scratched the surface of what either can do.

Hence, try them both for long enough to get some concept of just how they actually work, then select the one that matches *you*.

/Vi/ has modes, which bothers some people, and doesn't build much into the editor so much as it allows macros that can do anything, using external programs. /Vi/ is less complex at a minimum, but an experienced user can use just a much complexity as desired.

/Emacs/ is modeless, but as a result has a very complex set of key bindings that use Control and Esc key sequences that bother some people. Plus it tends to build a lot into the editor itself (though that is usually done with a "macro language", which with GNU Emacs and XEmacs is eLisp), making the standard implementations of Emacs large and complex at a minimum. But there are several smaller variations (MicroEmacs, mg, and Jove for example) for places where the real thing isn't appropriate.

--
Floyd L. Davidson           
Ukpeagvik (Barrow, Alaska)                         floyd@barrow.com

Including column mode?

I don't use it, so I can't tell you how, but yes they both have "column" modes.

I personally use XEmacs. I do often use "picture-mode", which has a more extensive "column" mode command set than the regular editing modes that I normally use do. But I don't use those facilities often, so while I'm aware that they exist, a tutorial isn't within my range of ability. (And vi is virtually a complete mystery to me, since I simply don't get along with it at all.)

As for GNU Emacs and XEmacs, and I think that covers the mentioned ntemacs too, these newsgroups would be helpful,

comp.emacs comp.emacs.xemacs gnu.emacs.help

For vi, I don't really know... perhaps comp.editors?

Incidentally, if anyone is interested... I'm almost finished with a little project for something I'm calling "embedded emacs" at the moment. Specifically the Linksys WRT54G wifi/router runs Linux on a 200MHz MIPS cpu, and uses "busybox" to provide most unix utilities, and for an editor it provides vi. So what I needed was a little stripped down version of emacs. I started with the public domain 3.7 release of MicroEmacs. It does things the emacs' way, is small, links against uClibc, doesn't need ncurses, and is known to work with both MIPS and x86 platforms. The whole thing is setup for cross compiling, so it should be fairly easy to port to any target that can be compiled for on a Linux platform.

The x86 binary is about 50K, the MIPS binary is about 116K, and both can be made smaller with the easy configuration menu that allows selectively excluding a couple dozen features.

--
Floyd L. Davidson           
Ukpeagvik (Barrow, Alaska)                         floyd@barrow.com

and what about code folding ?

vim does fold code. I'm a vi/vim acolyte so I don't know about emacs.

RFM

Sure. As I've said before about Emacs: if you want your editor to do some trick, and Emacs doesn't appear to do it (not even with a third-party extension package), you're probably trying to do something silly.

--
Hans-Bernhard Broeker (broeker@physik.rwth-aachen.de)
Even if all the snow were burnt, ashes would remain.

Yep, that's true. I've been using vi ever since it first appeared in whatever it was (BSD v7 or something, am I mixing Unix distros?) in the very early eighties. Actually, I'm not sure that that was when it first appeared, but it's when we first had terminals that would support it with screen addressing. I have used it (as ex) on a hardcopy terminal, though, where it would move the carriage back and forth, and rewrite the line on a new line when it changed too much to be rewritten on the current line. Fantastic!

--
Nobby

[snip]

Not to mention, Emacs has rubber-banding line drawing modes.

And block-diagram-graph-drawing modes.

And it runs over a serial console, so you can *run it* on that deeply-embedded box you're working on.

cheers, Rich

(Only 10 years Emacs experience so far - newbie).

--
rich walker         |  Shadow Robot Company | rw@shadow.org.uk
technical director     251 Liverpool Road   |
need a Hand?           London  N1 1LX       | +UK 20 7700 2487
www.shadow.org.uk/products/newhand.shtml

Hans-Bernhard Broeker wrote in news: snipped-for-privacy@news.dfncis.de:

Yet, you can do a lot of silly things with Emacs, particularly if you start getting into extending it yourself significantly. It's been a fair number of years since I used Emacs, thankfully, it's been even longer since I've used vi.

--
Richard