**** Post for FREE via your newsreader at post.usenet.com ****
Hi,
I recommend CodeWright 7.5. It is really powerful.
--
Mike Walters
www.swbox.com
StringDB - Localization Tools for Embedded Developers
"Paul Taylor" <pault_rem_.ngea@virgin.net> wrote in message
news:pan.2005.05.24.07.53.42.686611@virgin.net...
> On Mon, 23 May 2005 08:29:54 -0400, David T. Ashley wrote:
>
>> Can anyone recommend a text editor they are very hapy with (and why)?
>>
>> I'm tired of both Visual Studio and Metroworks CodeWarrior (for different
>> reasons).
>>
>> Thanks, Dave.
>
> JEdit is free/open source (www.jedit.org)
>
> Lightweight considering its written in Java
> Runs under windows/linux + others
> I like it because it has a good filesystem browser and also has split
> editing panes. There are lots of plugins too, although I haven't used too
> many of them.
>
> For screenshots see http://www.jedit.org/index.php?page=screenshots
>
> I use it mostly for writing c and html.
>
> Regards,
>
> Paul.
>
> --
> Remove _rem_ before replying by email.
>
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
*** Usenet.com - The #1 Usenet Newsgroup Service on The Planet! ***
http://www.usenet.com
Unlimited Download - 19 Seperate Servers - 90,000 groups - Uncensored
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Reply by Jonathan Kirwan●June 1, 20052005-06-01
On Wed, 01 Jun 2005 06:09:40 GMT, cstacy@news.dtpq.com (Christopher C.
Stacy) wrote:
>Jonathan Kirwan <jkirwan@easystreet.com> writes:
>> 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);
>
>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
Reply by ●June 1, 20052005-06-01
Jonathan Kirwan <jkirwan@easystreet.com> writes:
> 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);
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.
Reply by toby●May 30, 20052005-05-30
Toni76 wrote:
> I'm using CodeWright (http://www.borland.com/codewright/). I haven't
> found anything better. Visual Studio is not bad, its biggest problem is
> that it's made by Mircosoft.
If VS is "not bad", then on the same scale, Eclipse is "outstanding".
> CodeWarrior just sucks.
>
> If you don't wanna pay, you can try kdevelop ...
I'm using CodeWright (http://www.borland.com/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.
Reply by Tauno Voipio●May 28, 20052005-05-28
toby wrote:
>
> Jonathan Kirwan wrote:
>
>>...finding out the hard way why stacks are so nice to have
>>(the 2114/2116 didn't have stacks and stored the return address in the
>>first location of the subroutine.)
>
>
> I don't have the exact reference handy, but ISTR that even the PDP-11
> handbooks discussed that subroutine linkage mechanism. Knuth also used
> it in MIX, but that's less anachronistic.
>
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
Reply by Jonathan Kirwan●May 28, 20052005-05-28
On 27 May 2005 22:25:24 -0700, "toby" <toby@telegraphics.com.au>
wrote:
>Jonathan Kirwan wrote:
>> ...finding out the hard way why stacks are so nice to have
>> (the 2114/2116 didn't have stacks and stored the return address in the
>> first location of the subroutine.)
>
>I don't have the exact reference handy, but ISTR that even the PDP-11
>handbooks discussed that subroutine linkage mechanism. Knuth also used
>it in MIX, but that's less anachronistic.
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
Reply by toby●May 28, 20052005-05-28
Jonathan Kirwan wrote:
> ...finding out the hard way why stacks are so nice to have
> (the 2114/2116 didn't have stacks and stored the return address in the
> first location of the subroutine.)
I don't have the exact reference handy, but ISTR that even the PDP-11
handbooks discussed that subroutine linkage mechanism. Knuth also used
it in MIX, but that's less anachronistic.
>
> Jon
Reply by CBFalconer●May 27, 20052005-05-27
Scott Moore wrote:
> CBFalconer wrote:
>> Scott Moore wrote:
>>
>>> Interesting, I'll have to try compiling that.
>>>
>>> By the way, Turbo Pascal is NOT ISO Pascal, as the comments state.
>>
>> PascalP handles it:
>
> I thought you lost PascalP ?
> Jonathan Kirwan wrote:
>
> [lots of amusing lines edited out]
>
>> Regarding your comment about modems, I really did whistle into
>> the acoustic couplers to test communications! Honestly!
>
> I believe you. I recall an old mate from my company (even older
> than I) when, a few years ago, he was listening to a bicycle race
> program on the radio. It was the Spanish Tour. Then, suddenly,
> when the ciclysts where aproaching a town he already knew very
> well, a curious interference became audible and he jumped over
> his seat:
>
> - Hey! That's a [device he have programmed many years ago]!
> - How do you know it? It could be anything...
> - No, no, no! It IS a [device he have programmed many years ago]!
> It is calling the SCADA through its V.21 modem! I know the exact
> sequence of piooos and wooois!
>
> He also used to whistle into the couplers to call his beloved
> children, when testing a new communicaction link...
Back around 1970 we had contests to see who could fool which DTMF
(touch-tone) dialling decoders, by creating various wierd howls and
disgusting sounds. It was quite easy to cause false hits on the
expensive multiple band-pass filter types of the day. I was
developing a one-chip version for our own PBX system at the time,
which did much better.
My system split the incoming sound into high and low bands, and
then created zero crossings through two Schmidt triggers. The
trigger hysteresis was controlled by a peak rectifier in the other
band, thus controlling relative volumes, and that was the end of
analog processing. The rest depended on moving averages on the
period measurements, and was implementable in the (cheapest at the
time) P-channel dynamic MOS logic. The breadboards were built out
of the brand new CMOS logic family.
--
Some informative links:
news:news.announce.newusers
http://www.geocities.com/nnqweb/http://www.catb.org/~esr/faqs/smart-questions.htmlhttp://www.caliburn.nl/topposting.htmlhttp://www.netmeister.org/news/learn2quote.html