2 Feb
2010
2 Feb
'10
12:54 p.m.
On Mon, 1 Feb 2010 , ard at p850ug1.demon.co.uk (Tony Duell) wrote:
That sounds more like the Intel 8251 USART. IIRC on that chip you have to
send the reset command 3 times to ensure it's treated as a command and
not as data to be loadrd into one of the configuration registers.
-tony
Hmm, I must be getting old.
Between about 1983 and about 1990, I wrote a fair amount of software for
a communications board which I designed, and which used an 8088, an
8259, an 8253, 8255s, and, for some reason I cannot remember now, I
think it used 6850s for the serial ports. We started out with all
Motorola peripheral chips but found out that the timer chip wouldn't
work properly together with the Intel bus, so we switched to Intel. I do
have the distinct impression that we kept the 6850s for some reason,
probably price, and, I think, simplicity. We had no need for synchronous
communications so that would have been a reason.
We had an earlier all-Motorola design (6809-based) we got ideas from (I
had never designed any microprocessor circuitry before), and IIRC, I
started out sending a single reset command, which didn't work, and then
I looked at the other design and saw that their software sent 3 resets,
which I then understood the reason for.
I may be wrong, as this was 27 years ago, but it would be easy to test. I
can't, as I have nothing to test on. And Charlie C, had you asked me 27
years ago I could have told you exactly what to do ;-)
Whatever it was I did, it worked well, because we sold a number of those
boards, each of which used 4 serial interfaces. It annoys me that I
can't be sure whether we kept the ACIAs or changed to Intel.
Wh?t I do remember is that the Motorola chips were simple and elegant
compared to the Intel chips.
/Jonas
2 Feb
2 Feb
11:22 p.m.
On Feb 2, 2010, at 3:54 PM, Jonas Otter wrote:
--
Dave McGuire
Port Charlotte, FL
I may be wrong, as this was 27 years ago, but it would
be easy to
test. I
can't, as I have nothing to test on. And Charlie C, had you asked
me 27
years ago I could have told you exactly what to do ;-)
Whatever it was I did, it worked well, because we sold a number of
those
boards, each of which used 4 serial interfaces. It annoys me that I
can't be sure whether we kept the ACIAs or changed to Intel.
Wh?t I do remember is that the Motorola chips were simple and elegant
compared to the Intel chips.
This holds true for most of their chips. ;)
-Dave
3 Feb
3 Feb
9:50 a.m.
On 2 Feb 2010 at 20:54, Jonas Otter wrote:
Between about 1983 and about 1990, I wrote a fair
amount of software
for a communications board which I designed, and which used an 8088,
an 8259, an 8253, 8255s, and, for some reason I cannot remember now, I
think it used 6850s for the serial ports. We started out with all
Motorola peripheral chips but found out that the timer chip wouldn't
work properly together with the Intel bus, so we switched to Intel. I
do have the distinct impression that we kept the 6850s for some
reason, probably price, and, I think, simplicity. We had no need for
synchronous communications so that would have been a reason.
One of the more common chips used for async (as well as sync) back
then was the Signetics 2651 (and 2661). A 28 pin package, simple to
interface, with a built-in baud rate generator. The successful
orphan of the 2650 CPU family.
Another popular chip used was the Intel 8274 dual-channel chip,
basically a clone of the Z80 SIO chip.
There were many other comm chips by the major makers, but these two
packed a lot of bang-for-the-buck.
Cheers,
Chuck
10:01 a.m.
On Feb 3, 2010, at 12:50 PM, Chuck Guzis wrote:
Z8530. 'Nuff said.
Well, not quite 'nuff...it's an AMAZINGLY nice chip! I've done
quite a bit with it (both in my designs and in existing systems) and
have always been impressed with its capabilities.
-Dave
--
Dave McGuire
Port Charlotte, FL
Between about
1983 and about 1990, I wrote a fair amount of software
for a communications board which I designed, and which used an 8088,
an 8259, an 8253, 8255s, and, for some reason I cannot remember
now, I
think it used 6850s for the serial ports. We started out with all
Motorola peripheral chips but found out that the timer chip wouldn't
work properly together with the Intel bus, so we switched to Intel. I
do have the distinct impression that we kept the 6850s for some
reason, probably price, and, I think, simplicity. We had no need for
synchronous communications so that would have been a reason.
One of the more common chips used for async (as well as sync) back
then was the Signetics 2651 (and 2661). A 28 pin package, simple to
interface, with a built-in baud rate generator. The successful
orphan of the 2650 CPU family.
Another popular chip used was the Intel 8274 dual-channel chip,
basically a clone of the Z80 SIO chip.
There were many other comm chips by the major makers, but these two
packed a lot of bang-for-the-buck. 
10:29 a.m.
On 2/3/10, Dave McGuire <mcguire at neurotica.com> wrote:
Z8530. 'Nuff said.
Well, not quite 'nuff...it's an AMAZINGLY nice chip! I've done
quite a bit with it (both in my designs and in existing systems) and
have always been impressed with its capabilities.
We used the Z8530 on our later COMBOARD designs for bisync and SNA
comms. I did quite a bit of low-level programming in M68K assembler
for it. Except for the fact that we had an early system design (1985)
with a 4MHz chip on an 8MHz platform and needed to be careful about
how fast we hammered the registers, it was really fun to program.
One way we leveraged it in our embedded design was to keep the primary
SIO channel in sync mode and the secondary in async mode so we could
use the secondary channel for debugging/tracing.
If I needed more than a INS6402/RCA1854 or a 6850 could do in a new
hobby design, I'd happily reach for a Z8530.
-ethan
12:11 p.m.
Z8530. 'Nuff said.
Well, not quite 'nuff...it's an AMAZINGLY nice chip! I've done
quite a bit with it (both in my designs and in existing systems) and
have always been impressed with its capabilities.
It has one gotcha that I remember. As ever, they ran out of pins on the
package, and didn't have room for a reset pin. Instead you do a hardware
reset by asserting rd/ and wr/ at the same time.
This is only a problem if you're trying to produce rd/ and wr/ from a R/W
line and you don't realise a momentaruy overlap (and the 'glitch' from
one LS TTL gate is enough) will reset the Z8530, or worse still partially
reset it.
Please don't ask how I foudn that out...
-tony
12:32 p.m.
On 3 Feb 2010 at 13:01, Dave McGuire wrote:
Z8530. 'Nuff said.
Well, not quite 'nuff...it's an AMAZINGLY nice chip! I've done
quite a bit with it (both in my designs and in existing systems) and
have always been impressed with its capabilities.
It's not bad, but if you don't need the sync capabilities, Exar also
has some pretty amazing offerings, all based on the 16550 UART.
--Chuck
12:09 p.m.
One of the more common chips used for async (as well
as sync) back
then was the Signetics 2651 (and 2661). A 28 pin package, simple to
interface, with a built-in baud rate generator. The successful
orphan of the 2650 CPU family.
On the 6800/6809/6502 bus, I much prefered the 6551 to the 6850. The
former included a baud rate generator, and just needed an external crystal.
I seem to rememebr a Rockwell dual serial chip for this bus, but I can't
remmebr the number off the top of my head. AndI mentiond the 6852 and
6854 in an earlier message.
Another popular chip used was the Intel 8274
dual-channel chip,
basically a clone of the Z80 SIO chip.
I didn't think they were that similar... IIRC the 8274 is very similar to
the NEC7201.
There were many other comm chips by the major makers,
but these two
packed a lot of bang-for-the-buck.
There was obvisouly the 8250 (Intel) used in the original IBM PC Async
card, and its improved versiuons (16450, 16550, etc). For some
inexplicable (to me) reason, HP used the 8250 on the simple RS232 cards
for their HP9000/200 machines (which were 68000 based). The more
complcated serial card used a Z80-SIO with a Z80 CPU controlling it.
There were the well-known 40 pin dumb UARTs (6402, AY-5-1013, etc). They
had the advantage that they could easily be used without a procesor,
althogh interfaceing them to a microcomputer bus was very easy if you
wanted to do that.
There was a pair of chips from Western Digital, the PR1472 (receiver) and
PT1482 (transmitter). They were a bit like the dumb UART in that you
could easily configure them without a processor (but again you could
easily link them to a processor if you wanted to), but they did both sync
and async modes. HP used them in the fancy serial interface for the 9830
(HP11284 IIRC), and in the HP59403 HPIB common carrier (modem) interface.
-tony
12:52 p.m.
On 3 Feb 2010 at 20:09, Tony Duell wrote:
The uPD7201 *is* an 8474, just with NECs own part number. This
scheme obtained with most x80 and x86 support chipsets. Why NEC used
its own numbering is an unknown.
Compare the programming information for the Z80 SIO (Z8441) and the
8474. The register definitions line up virtually bit for bit. I
received a job to do some 8474 programming and noticed right away
that I could just about work from the Z80 SIO datasheet which I had
Another
popular chip used was the Intel 8274 dual-channel chip,
basically a clone of the Z80 SIO chip.
I didn't think they were that similar... IIRC the 8274 is very similar
to the NEC7201. from a previous job. I believe the same person
designed both chips.
In that respect, the Z8530 bears a certain family
resemblance.
There was obvisouly the 8250 (Intel) used in the
original IBM PC Async
card, and its improved versiuons (16450, 16550, etc). For some
inexplicable (to me) reason, HP used the 8250 on the simple RS232 cards
for their HP9000/200 machines (which were 68000 based). The
more complcated serial card used a Z80-SIO with a Z80 CPU.
ISTR that the 8250 was originally a National part, not an Intel part.
Televideo used the 8474 on its early RS-422 network system
(InfoShare, which I believe was done by Novell or whatever its
predecessor was named).
The brain-dead (async only) Z80 SIO is the Z80 DART. I don't think
there's a corresponding Intel part related to the 8474 with disabled
synchronous capabilities.
--Chuck
1:34 p.m.
On Feb 3, 2010, at 3:52 PM, Chuck Guzis wrote:
The brain-dead (async only) Z80 SIO is the Z80 DART.
I don't think
there's a corresponding Intel part related to the 8474 with disabled
synchronous capabilities.
I wouldn't exactly call the Z80 DART brain-dead...it's still a
pretty fancy chip, even without the sync hardware.
Perhaps "lobotomized". ;)
-Dave
--
Dave McGuire
Port Charlotte, FL
1:43 p.m.
On 3 Feb 2010 at 16:34, Dave McGuire wrote:
I wouldn't exactly call the Z80 DART
brain-dead...it's still a
pretty fancy chip, even without the sync hardware.
Perhaps "lobotomized". ;)
"Cost reduced?" What happens if one tries to put a DART into
synchronous mode? Always wondered, never got the opportunity to try.
--Chuck
4 Feb
4 Feb
11:17 a.m.
"Cost reduced?" What happens if one tries
to put a DART into
synchronous mode? Always wondered, never got the opportunity to try.
I always wondered (based on the register definitions) if the DART was a
SIO with a defect in the synchoronous section. Has anyone ever looked at
the 2 dice?
-tony
3 Feb
3 Feb
11:49 a.m.
Wh=E1t I do remember is that the Motorola chips were
simple and elegant
compared to the Intel chips.
That is almost always the case :-). In fact just about every Intel chip
I've ever used has had a major dsesign misfeature. Heck, they're the only
company that managed to screw up the design of a parallel interface chip.
-tony
12:19 p.m.
On Feb 3, 2010, at 2:49 PM, Tony Duell wrote:
The 8255 with its stupid reset-all-pin-states-on-mode-change
business?
-Dave
--
Dave McGuire
Port Charlotte, FL
Wh=E1t I do
remember is that the Motorola chips were simple and
elegant
compared to the Intel chips.
That is almost always the case :-). In fact just about every Intel
chip
I've ever used has had a major dsesign misfeature. Heck, they're
the only
company that managed to screw up the design of a parallel interface
chip.
4 Feb
4 Feb
11:15 a.m.
That is almost always the case :-). In fact just
about every Intel
chip
I've ever used has had a major dsesign misfeature. Heck, they're
the only
company that managed to screw up the design of a parallel interface
chip.
The 8255 with its stupid reset-all-pin-states-on-mode-change
business? from the time of the hardware rest right through the
programming of the
parallel port chip until you want to set a p[articular line
low.
-tony
1:20 p.m.
On 4 Feb 2010 at 19:15, Tony Duell wrote:
That's the one. A more stupid design decision is
hard to imagine!
Okay, in Intel's defense, are there any earlier peripheral chips for
the 8-bit bus (I don't count the 8212 and the 8205)?
...and here we are, more than 35 years down the road and you can
still buy the things new. Say what you want about it--it's probably
one of the most durable peripheral chips out there.
--Chuck
5 Feb
5 Feb
10:41 a.m.
On 4 Feb 2010 at 19:15, Tony Duell wrote:
When did the 6820 come out?
Even so, the knoweldge that TTL inputs float high, and can more easily be
pulled high than low was very well known at the time. Whoever designed
that chip was not thinkibng aobut how it was going to be used IMHO. I am
not talking aobut somebody finding an application later on for which the
original design wasn't perfect, but actually I can't think of a single
applicaiton where the behaviour of the 8255 is desireable. I can think of
some where it doens't matter, but none where you'd avtually want a chip
that behaves that way.
That's the one. A more stupid design decision
is hard to imagine!
Okay, in Intel's defense, are there any earlier peripheral chips for
the 8-bit bus (I don't count the 8212 and the 8205)?
...and here we are, more than 35 years down the road and you can
still buy the things new. Say what you want about it--it's probably
one of the most durable peripheral chips out there.
And I am still wondering why...
-tony
11:40 a.m.
On 5 Feb 2010 at 18:41, Tony Duell wrote:
Even so, the knoweldge that TTL inputs float high, and
can more easily
be pulled high than low was very well known at the time. Whoever
designed that chip was not thinkibng aobut how it was going to be used
IMHO. I am not talking aobut somebody finding an application later on
for which the original design wasn't perfect, but actually I can't
think of a single applicaiton where the behaviour of the 8255 is
desireable. I can think of some where it doens't matter, but none
where you'd avtually want a chip that behaves that way.
That being said, apparently few think that it's an issue, as a web
search doesn't turn up much in the way of grumbling. But how many
8255s are installed in an application where mode switching is used?
Darned few, I would guess.
The 8255 was obsolete years ago. It's slow and most of the desired
functionality can be gotten more easily with other means, either with
programmable logic or even SSI.
So we're really beating a dead horse.
--Chuck
2:01 p.m.
On Feb 5, 2010, at 2:40 PM, Chuck Guzis wrote:
8255s are frequently used to interface to IDE drives, and mode
switching is required in that application, and it does get in the
way. Mostly people have dealt with it by using inverters on some of
the lines.
Why people don't just choose a better chip for that is beyond me.
It's much easier to do with a Z80 PIO if you're using an appropriate
bus. I'm sure the 6821 would be easy too.
-Dave
--
Dave McGuire
Port Charlotte, FL
Even so, the
knoweldge that TTL inputs float high, and can more
easily
be pulled high than low was very well known at the time. Whoever
designed that chip was not thinkibng aobut how it was going to be
used
IMHO. I am not talking aobut somebody finding an application later on
for which the original design wasn't perfect, but actually I can't
think of a single applicaiton where the behaviour of the 8255 is
desireable. I can think of some where it doens't matter, but none
where you'd avtually want a chip that behaves that way.
That being said, apparently few think that it's an issue, as a web
search doesn't turn up much in the way of grumbling. But how many
8255s are installed in an application where mode switching is used?
Darned few, I would guess.
The 8255 was obsolete years ago. It's slow and most of the desired
functionality can be gotten more easily with other means, either with
programmable logic or even SSI.
So we're really beating a dead horse.
2:14 p.m.
On 5 Feb 2010 at 17:01, Dave McGuire wrote:
8255s are frequently used to interface to IDE
drives, and mode
switching is required in that application, and it does get in the
way. Mostly people have dealt with it by using inverters on some of
the lines.
Really? I don't think I've seen a single piece of modern gear made
in the last 10 years that uses an 8255 to interface to an IDE drive.
They do have specialized chips to do that...
If it's the hobbyist clan, well, that's a different matter. I'd
think even a small CPLD would do a better job.
--Chuck
2:17 p.m.
On Feb 5, 2010, at 5:14 PM, Chuck Guzis wrote:
The SBC6120 comes to mind. Considering the number of units sold
and the level of commercialization of the whole deal, I'm not sure
I'd consider it "hobbyist clan".
8255s are
frequently used to interface to IDE drives, and mode
switching is required in that application, and it does get in the
way. Mostly people have dealt with it by using inverters on some of
the lines.
Really? I don't think I've seen a single piece of modern gear made
in the last 10 years that uses an 8255 to interface to an IDE drive.
They do have specialized chips to do that...
If it's the hobbyist clan, well, that's a different matter. I'd think even a small CPLD would do a better
job.
That's what I'd have done on that board.
-Dave
--
Dave McGuire
Port Charlotte, FL
3:09 p.m.
Dave McGuire wrote:
The SBC6120 comes to mind. Considering the number of
units sold and the
level of commercialization of the whole deal, I'm not sure I'd consider
it "hobbyist clan".
With the short supply of 6120 chips, don't grumble about what you get.
I'd think even a small CPLD would do a better
job.
That's what I'd have done on that board. -Dave
Now if you had a small PDP-11 for board
for sale ... I'd buy one.
Ben.
3:22 p.m.
On Feb 5, 2010, at 6:09 PM, Ben wrote:
The use of the 8255 in that design has precisely zero to do with
the supply of 6120 chips.
And (in case Bob is listening) I didn't mean to grumble, just
state that were I the designer, I'd have used a different
chip...that's all.
-Dave
--
Dave McGuire
Port Charlotte, FL
The SBC6120
comes to mind. Considering the number of units sold
and the
level of commercialization of the whole deal, I'm not sure I'd
consider
it "hobbyist clan".
With the short supply of 6120 chips, don't grumble about what you get. I'd think even a small CPLD would do a better
job.
That's what I'd have done on that board.
2:27 p.m.
On 2/5/10, Chuck Guzis <cclist at sydex.com> wrote:
Really? I don't think I've seen a single
piece of modern gear made
in the last 10 years that uses an 8255 to interface to an IDE drive.
They do have specialized chips to do that...
If it's the hobbyist clan, well, that's a different matter. I'd
think even a small CPLD would do a better job.
The Spare Time Gizmos SBC6120 happens to use an 8255 for its IDE
interface. It has three GALs and no CPLDs. It is less than 10 years
old.
-ethan
2:59 p.m.
On 5 Feb 2010 at 17:27, Ethan Dicks wrote:
The Spare Time Gizmos SBC6120 happens to use an 8255
for its IDE
interface. It has three GALs and no CPLDs. It is less than 10 years
old.
You're still talking "retro hobbyist", aren't you? Or are new PDP-8
systems being deployed in commercial applications today?
--Chuck
3:21 p.m.
On Feb 5, 2010, at 5:59 PM, Chuck Guzis wrote:
Lack of "commercial applications" doesn't imply "hobbyist".
Every
Toys-R-Us store is filled to overflowing with proof of that.
-Dave
--
Dave McGuire
Port Charlotte, FL
The Spare Time
Gizmos SBC6120 happens to use an 8255 for its IDE
interface. It has three GALs and no CPLDs. It is less than 10 years
old.
You're still talking "retro hobbyist", aren't you? Or are new PDP-8
systems being deployed in commercial applications today?
3:30 p.m.
On Feb 5, 2010, at 6:21 PM, Dave McGuire wrote:
Lack of "commercial applications" doesn't imply "hobbyist".
Every Toys-R-Us store is filled to overflowing with proof of that.
[replying to my own post because I think I wasn't clear]
The product is produced by a professional organization that does
professional-grade work...and it has an 8255 in it. The fact that
the product is targeted primarily at the hobbyist market isn't
relevant here.
-Dave
--
Dave McGuire
Port Charlotte, FL
The Spare Time Gizmos SBC6120 happens to use an 8255
for its IDE
interface. It has three GALs and no CPLDs. It is less than 10
years
old.
You're still talking "retro hobbyist", aren't you? Or are new PDP-8
systems being deployed in commercial applications today?
4:14 p.m.
On Fri, Feb 5, 2010 at 5:59 PM, Chuck Guzis <cclist at sydex.com> wrote:
On 5 Feb 2010 at 17:27, Ethan Dicks wrote:
It's surely a matter of scale, but the order gates are once again open
for a minimum run of 50 SBC6120s w/FP6120s for $600. There are more
iPods and PS/3s and digital watches than SBC6120s, but I'd call $30K
(for just _this_ run) a commercial product, even if the audience is
hobbyists.
-ethan
The Spare Time Gizmos SBC6120 happens to use an
8255 for its IDE
interface. ?It has three GALs and no CPLDs. ?It is less than 10 years
old.
You're still talking "retro hobbyist", aren't you? ?Or are new PDP-8
systems being deployed in commercial applications today? 
3:17 p.m.
Ethan Dicks wrote:
On 2/5/10, Chuck Guzis <cclist at sydex.com>
wrote:
Using an 8255 makes it electrically simple and trades for programming.
However.. it's slower than sludge doing it that way. I have done it that
way (using BCC180 Micromint Z180 card) as it had 8255s on it and its
about 8x-10x slower than doing a real direct port IO.
NOTE: all the IDE interface is is a address decode and bus buffer
as all the intelligence is on the drive. Most System that use IDE
are 80x86 or other 16bit wide(or wider) systems. The reason to
use 8255 on small micros (8051, 8085, z80, z180, 6502 6809) is
that IDE data path is 16bits wide and the using two ports of the
8255 you can do the needed byte latch to transfer 16bits is two
reads or writes. Other designs use TTL or maybe a GAL (GIDE)
to perform that or as I did I just ignore the upper 8bits and treat
the device as 256bytes/sector rather than 512. However the
amount of TTL to do the latch the upper byte bidirectionally
is fairly small for those that wish a purist interface. But with
large hundreds of megabytes to small 10s of gigabytes throwing
every other byte away is a small to no cost. Also later drives
use LBA addressing which is far easier to work with then CHS.
One caveat.. USE CF and that does the 8bit transfer that IDE
documented but only a few old drives implemented. That works
well and require only two address blocks to work and near zero
logic beyond address selection and buffers where needed.
Anywho the IDE interface chips from the PC market are all basically
16bit wide bus, IDE drive 0,1 address decode and some extra logic
to do burst mode DMA, block DMA (Both required external DMA
support) or PIO. in the x86 space. FYI PIO unlike floppies is buffered
on the disk so the IO can be does as fast or slow as the programmer
wishes to the limits of ATAPI spec (all do minimally 33mbytes/sec
and later are faster).
Allison
Really? I don't think I've seen a single
piece of modern gear made
in the last 10 years that uses an 8255 to interface to an IDE drive.
They do have specialized chips to do that...
If it's the hobbyist clan, well, that's a different matter. I'd
think even a small CPLD would do a better job.
The Spare Time Gizmos SBC6120 happens to use an 8255 for its IDE
interface. It has three GALs and no CPLDs. It is less than 10 years
old.
-ethan
4:01 p.m.
On 5 Feb 2010 at 18:17, allison wrote:
Anywho the IDE interface chips from the PC market are
all basically
16bit wide bus, IDE drive 0,1 address decode and some extra logic to
do burst mode DMA, block DMA (Both required external DMA support) or
PIO. in the x86 space. FYI PIO unlike floppies is buffered on the
disk so the IO can be does as fast or slow as the programmer wishes to
the limits of ATAPI spec (all do minimally 33mbytes/sec and later are
faster).
Just about any IDE disk drive made in the last 20 years also has a 16-
bit data path (very old XTIDE drives could do 8 bit, but they're hard
to find. I don't know about microdrives). So that's a problem with
or without an interface chip if what you want to do is interface to
an 8-bit bus--and use all of the available space on the disk.
--Chuck
4:07 p.m.
On Feb 5, 2010, at 7:01 PM, Chuck Guzis wrote:
Microdrives conform to the CF standard, which requires that the 8-
bit mode be implemented.
-Dave
--
Dave McGuire
Port Charlotte, FL
Anywho the IDE
interface chips from the PC market are all basically
16bit wide bus, IDE drive 0,1 address decode and some extra logic to
do burst mode DMA, block DMA (Both required external DMA support) or
PIO. in the x86 space. FYI PIO unlike floppies is buffered on the
disk so the IO can be does as fast or slow as the programmer
wishes to
the limits of ATAPI spec (all do minimally 33mbytes/sec and later are
faster).
Just about any IDE disk drive made in the last 20 years also has a 16-
bit data path (very old XTIDE drives could do 8 bit, but they're hard
to find. I don't know about microdrives). So that's a problem with
or without an interface chip if what you want to do is interface to
an 8-bit bus--and use all of the available space on the disk.
3:15 p.m.
On 5 Feb 2010 at 17:01, Dave McGuire wrote:
An 8255 is a ridiculous choice to interface to an IDE drive!. I've never
seen it used for that either. The IDE card in this machine uses a few TTL
buffers and a couple oF PALs for address decoding, etc.
8255s are frequently used to interface to IDE
drives, and mode
switching is required in that application, and it does get in the
way. Mostly people have dealt with it by using inverters on some of
the lines.
Really? I don't think I've seen a single piece of modern gear made
in the last 10 years that uses an 8255 to interface to an IDE drive.
They do have specialized chips to do that...
If it's the hobbyist clan, well, that's a different matter. I'd
think even a small CPLD would do a better job.
This assumes you have the facilities to program the CPLD, the development
software _and somethign to run it on_. That is not always the case.
-tony
3:58 p.m.
On 5 Feb 2010 at 23:15, Tony Duell wrote:
This assumes you have the facilities to program the
CPLD, the
development software _and somethign to run it on_. That is not always
the case.
Both Xilinx and Altera offer free development software for their
devices. And Windows or Linux PCs aren't exactly uncommon.
Programmers can be little more than a couple of buffers connected to
a PCs parallel port--or (heaven forfend!) a USB interface.
--Chuck
6 Feb
6 Feb
3:42 a.m.
On 5 Feb 2010 at 23:15, Tony Duell wrote:
That's free as in beer, not as in speech. And my experience is that I
spend far too long getting software to work on my hardware if I don't
have the soruces.
This assumes you have the facilities to program
the CPLD, the
development software _and somethign to run it on_. That is not always
the case.
Both Xilinx and Altera offer free development software for their devices. And Windows or Linux PCs aren't exactly
uncommon.
That is not uiversally true.
-tony
11:22 a.m.
On Feb 6, 2010, at 6:42 AM, Tony Duell wrote:
Walk around the neighborhood on trash day, man. Half of my
neighbors are running computers that the other half of my neighbors
threw out because they're too clueless to properly maintain and/or
repair them when they get all crapped up with viruses and such.
-Dave
--
Dave McGuire
Port Charlotte, FL
devices. And
Windows or Linux PCs aren't exactly uncommon.
That is not uiversally true.
1:18 p.m.
New subject: Programmable devices, was: cctech Digest, Vol 78, Issue 3
On 6 Feb 2010 at 11:42, Tony Duell wrote:
That's free as in beer, not as in speech. And my
experience is that I
spend far too long getting software to work on my hardware if I don't
have the soruces.
I don't even know how to respond to this one on my 2-year old,
freecycled P4 system that I'm sitting in front of. Doubtless it
contains some devices that were developed using the "free beer"
tools, but if you don't have the source, it must not be any good.
So I won't bother.
--Chuck
devices. And Windows or Linux PCs aren't
exactly uncommon.
That is not uiversally true.
5 Feb
5 Feb
10:12 p.m.
Tony Duell wrote:
This assumes you have the facilities to program the
CPLD, the development
software _and somethign to run it on_. That is not always the case.
I don't know, old PC's are a dime a dozen. Still TTL buffers is all you
really
need for I/O if you don't mind wasting the high order byte.
-tony
6 Feb
6 Feb
4:02 a.m.
I don't know, old PC's are a dime a dozen. Still TTL buffers is all you
really
need for I/O if you don't mind wasting the high order byte.
OK, I actuially have a US dime somwhere. Please tell me where I can
exchange it for 12 PCs capable of running FPGA or CPLD development software.
-tony
5:18 p.m.
Tony Duell wrote:
Atmel software is still free the last time I looked, running on a modest
windows PC. PC's ... see your local dumpster.
http://www.atmel.com/dyn/products/tools.asp?family_id=653
Ben.
PS. They also sell 8051 products for the 'real' programmer. :)
I don't know, old PC's are a dime a dozen. Still TTL buffers is all you
really
need for I/O if you don't mind wasting the high order byte.
OK, I actuially have a US dime somwhere. Please tell me where I can
exchange it for 12 PCs capable of running FPGA or CPLD development software.
-tony
6:15 p.m.
On Feb 6, 2010, at 8:18 PM, Ben wrote:
Atmel software is still free the last time I looked, running on a
modest
windows PC. PC's ... see your local dumpster.
http://www.atmel.com/dyn/products/tools.asp?family_id=653
Ben.
PS. They also sell 8051 products for the 'real' programmer. :)
The best 8051 stuff is free, and has been for a long time. FYI.
-Dave
--
Dave McGuire
Port Charlotte, FL
I don't know, old PC's are a dime a dozen.
Still TTL buffers is
all you
really
need for I/O if you don't mind wasting the high order byte.
OK, I actuially have a US dime somwhere. Please tell me where I can
exchange it for 12 PCs capable of running FPGA or CPLD
development software.
-tony
7 Feb
7 Feb
10:23 a.m.
Tony Duell wrote:
Atmel software is still free the last time I looked, running on a modest
windows PC. PC's ... see your local dumpster.
As far as I know, you do not live in London (England). So I can't see how
you can tell me that PCs are available in the 'local dumpster'/
FWIW, dumpster diving is illegal in the UK. THat however, is secondary to
the fact that we have a WEEE direcrtive that means we have to recycle
electronic equipment and not throw it in the skip/dumpster. And I have
_never_ seen a PC in a skip/dumpster in London (and I am certainly not
going to trespass on various company sites to see if I can steal one).
Also, unless I missed something, Windows isn't free. I I doubt that if I
found a junked PC that happeend to have a runnable copy of Windows on the
hard drivce the ntat would count as a valid Windows license. I don't
particulalry care for Windows, or any Microsoft product for that matter,
but that doesn't give me the right to pirate them.
-tony
I don't know, old PC's are a dime a dozen. Still TTL buffers is all you
really
need for I/O if you don't mind wasting the high order byte.
OK, I actuially have a US dime somwhere. Please tell me where I can
exchange it for 12 PCs capable of running FPGA or CPLD development software.
-tony
10:37 a.m.
On Feb 7, 2010, at 1:23 PM, Tony Duell wrote:
Atmel software is still free the last time I looked, running on a
modest
windows PC. PC's ... see your local dumpster.
As far as I know, you do not live in London (England). So I can't
see how
you can tell me that PCs are available in the 'local dumpster'/
FWIW, dumpster diving is illegal in the UK.
That's...very weird to me.
I don't
know, old PC's are a dime a dozen. Still TTL buffers is
all you
really
need for I/O if you don't mind wasting the high order byte.
OK, I actuially have a US dime somwhere. Please tell me where I can
exchange it for 12 PCs capable of running FPGA or CPLD
development software. THat however, is secondary to
the fact that we have a WEEE direcrtive that means we have to recycle
electronic equipment and not throw it in the skip/dumpster. And I have
_never_ seen a PC in a skip/dumpster in London (and I am certainly not
going to trespass on various company sites to see if I can steal one).
I would. :) But I see PeeCees on the curb quite often.
Also, unless I missed something, Windows isn't
free. I I doubt that
if I
found a junked PC that happeend to have a runnable copy of Windows
on the
hard drivce the ntat would count as a valid Windows license. I don't
particulalry care for Windows, or any Microsoft product for that
matter,
but that doesn't give me the right to pirate them.
So don't run Windows. FPGA/CPLD/PAL software runs on other
platforms. Indeed, large-scale chip design in the real world isn't
typically done under Windows.
-Dave
--
Dave McGuire
Port Charlotte, FL
10:41 a.m.
New subject: PCs on the curbside
On Sun, 7 Feb 2010, Dave McGuire wrote:
So don't run Windows. FPGA/CPLD/PAL software runs
on other platforms.
Indeed, large-scale chip design in the real world isn't typically done under
Windows.
-Dave
--
Dave McGuire
Port Charlotte, FL
Indeed, the Xilinx webpack software runs fine on Linux
Peter Wallace
1:19 p.m.
New subject: PCs on the curbside
Peter C. Wallace wrote:
Indeed, the Xilinx webpack software runs fine on
Linux
Peter Wallace
Yeah, it works pretty good. I was surprised that it installs natively
on many different flavors on linux.
There are, of course, some gotchas, like recognizing on install into
CentOS to disable the Security-Enhanced Linux protections.
And the usb drivers for programming boards directly aren't
supported(read: don't work) on anything but a couple different versions
(like $$$ version of RHEL5,4). So you have to mess with libusb, fxload,
and a few other things.
Luckily, there is enough community support/forums for the common flavors
to get things working.
I installed it on Ubuntu 9.10 without (major) issue.
Keith
10:42 a.m.
On 2/7/2010 12:37 PM, Dave McGuire wrote:
I would. :) But I see PeeCees on the curb quite often.
Where are you located?
--
Jim Leonard (trixter at oldskool.org) http://www.oldskool.org/
Help our electronic games project: http://www.mobygames.com/
Or check out some trippy MindCandy at http://www.mindcandydvd.com/
A child borne of the home computer wars: http://trixter.wordpress.com/
10:54 a.m.
On 2/7/2010 12:42 PM, Jim Leonard wrote:
On 2/7/2010 12:37 PM, Dave McGuire wrote:
Never mind:
Dave McGuire
Port Charlotte, FL
I am located in Naperville, IL and I see a PC on the curb about once
every two years.
--
Jim Leonard (trixter at oldskool.org) http://www.oldskool.org/
Help our electronic games project: http://www.mobygames.com/
Or check out some trippy MindCandy at http://www.mindcandydvd.com/
A child borne of the home computer wars: http://trixter.wordpress.com/
I would. :) But I see PeeCees on the curb quite
often.
Where are you located?
11:06 a.m.
On Feb 7, 2010, at 1:54 PM, Jim Leonard wrote:
Never mind:
Dave McGuire
Port Charlotte, FL
I am located in Naperville, IL and I see a PC on the curb about
once every two years.
Granted I see them a lot less nowadays, now that everyone is
broke...more people are fixing (well, paying to have someone else
fix) their machines rather than just throwing them in the garbage
when Windows shits the bed. But I do still see them about every
other month or so, and usually grab them.
-Dave
--
Dave McGuire
Port Charlotte, FL
I would. :) But I see PeeCees on the curb quite often.
Where are you located?
10:58 a.m.
On 7 Feb 2010 at 13:37, Dave McGuire wrote:
I don't imagine that the UK has any sort of computer reuse/donation
organizations, either. So the moment you quit using a PC, the police
show up on your doorstep to make sure that you won't give/sell the
system to anyone else? As far as I know, the UK only requires that a
PC be licensed if it's used to view television content. Or has that
changed? And how can they tell?
The system that I'm typing this on was gained via the local Freecycle
network. Originally it came in a 4U rackmount case, but that's been
repurposed for a different ssystem.
--Chuck
THat however,
is secondary to
the fact that we have a WEEE direcrtive that means we have to
recycle electronic equipment and not throw it in the skip/dumpster.
And I have _never_ seen a PC in a skip/dumpster in London (and I am
certainly not going to trespass on various company sites to see if I
can steal one).
I would. :) But I see PeeCees on the curb quite often.
11:29 a.m.
On 7 Feb 2010 at 13:37, Dave McGuire wrote:
I don't imagine that the UK has any sort of computer reuse/donation
organizations, either. So the moment you quit using a PC, the police
Charity shops (the equivalent of thrift stores) don't normally accept and
sell mains-powered electrical devies, because there's another silly law
that sats that all electrical devices sold in that way have to be
safety-tested by a suitable elecrrician. _Occasionally_ the shops break
that rule (which is how I got my Amiga 500) or sell wall-wart powered
devices without the PSU (I got a nice Acorn Atom that way).
THat
however, is secondary to
the fact that we have a WEEE direcrtive that means we have to
recycle electronic equipment and not throw it in the skip/dumpster.
And I have _never_ seen a PC in a skip/dumpster in London (and I am
certainly not going to trespass on various company sites to see if I
can steal one).
I would. :) But I see PeeCees on the curb quite often. show up on your doorstep to make sure that you
won't give/sell the
As far as I know there's nothing to stop people giving or selling PCs to
friends.. But my friends never seem to have old PCs...
system to anyone else? As far as I know, the UK only
requires that a
PC be licensed if it's used to view television content. Or has that
changed? And how can they tell?
That has nothing to do with it.
The system that I'm typing this on was gained via the local Freecycle
network. Originally it came in a 4U rackmount case, but that's been
repurposed for a different ssystem.
We do have freecycle over here, but I've never seen any desirable
computer stuff listed on it locally.
-tony
11:37 a.m.
I don't imagine that the UK has any sort of
computer reuse/donation
organizations, either. So the moment you quit using a PC, the police
show up on your doorstep to make sure that you won't give/sell the
system to anyone else?
I don't think I've ever seen a PC out with the garbage: they almost
certainly
wouldn't be accepted. You get to take them to the tip or give them away.
You could hang around the tip and hope, but you'd have to not fall foul
of some arbitrary rules (you certainly cannot take stuff away ... so
you'd
have to persuade someone to give you their PC right out of the car
boot).
As far as I know, the UK only requires that a
PC be licensed if it's used to view television content. Or has that
changed? And how can they tell?
I assume this is still tongue firmly in cheek. If not, then nothing is
licenced. If you purchase anything that is on the list of "might be
a TV" (such a a graphics card with TV Out) the retailer takes your name
and address. If the TV Licensing folks don't find that combination on
their database they send you a letter. If you don't reply they send you
a letter telling you that they'll show up on the doorstep. If you
happen to have purchased the item over the web and had it delivered to
your work address, they'll show up at your work address. If you happen
to be out (because, maybe it's lunchtime!), they'll leave you a note
saying (essentially) "See, we *did* call" and you never hear from them
again.
Oh, and you only need a licence to view content "live" (any contents,
not just BBC or even any UK channels, satellite stuff too ...) on
any device (TV, PC, phone, maybe even your fillings if you happen
to be an oddball synaesthete).
Antonio
8 Feb
8 Feb
12:05 p.m.
New subject: TV Licensing (Re: cctech Digest, Vol 78, Issue 3)
Is that one license per item (e.g. we have two TV's and a Sega Game Gear
with (analogue) TV Tuner), or one license per house?
Regards,
Andrew B
aliensrcooluk at yahoo.co.uk
----- Original Message -----
From: <arcarlini at iee.org>
To: "'General Discussion: On-Topic and Off-Topic Posts'"
<cctalk at classiccmp.org>
Sent: Sunday, February 07, 2010 7:37 PM
Subject: RE: cctech Digest, Vol 78, Issue 3
Oh, and you only need a licence to view content "live" (any contents,
not just BBC or even any UK channels, satellite stuff too ...) on
any device (TV, PC, phone, maybe even your fillings if you happen
to be an oddball synaesthete).
Antonio
3:04 p.m.
New subject: TV Licensing (Re: cctech Digest, Vol 78, Issue 3)
cctalk-bounces at classiccmp.org wrote:
Is that one license per item (e.g. we have two
TV's and a
Sega Game Gear with (analogue) TV Tuner), or one license per house?
Ring them and ask :-)
Assuming single occupancy, then one per house.
Tenants, students, hotels etc, and it becomes more complex.
GameGear will presumably drop off the list of notifiable devices
sometime after 2012 :-)
BTW: can you successfully feed it from a set top box?
Antonio
9 Feb
9 Feb
10:48 a.m.
New subject: TV Licensing (Re: cctech Digest, Vol 78, Issue 3)
----- Original Message -----
From: <arcarlini at iee.org>
To: "'General Discussion: On-Topic and Off-Topic Posts'"
<cctalk at classiccmp.org>
Sent: Monday, February 08, 2010 11:04 PM
Subject: RE: TV Licensing (Re: cctech Digest, Vol 78, Issue 3)
cctalk-bounces at classiccmp.org wrote:
I haven't actually tried... but since it has a small extendable aerial (like
you'd find on a radio/ghettoblaster) I can't see it being easy connecting it
to a set top box (but probably not impossible). It's not something I can
test, as we don't have a set top box (no satellite TV here). My parents have
freeview which is built-in to a DVD recorder they got just over a year ago.
I just have terrestrial TV in my bedroom, but I don't watch that much TV
anyway.
Regards,
Andrew B
aliensrcooluk at yahoo.co.uk
Is that one license per item (e.g. we have two
TV's and a
Sega Game Gear with (analogue) TV Tuner), or one license per house?
Ring them and ask :-)
Assuming single occupancy, then one per house.
Tenants, students, hotels etc, and it becomes more complex.
GameGear will presumably drop off the list of notifiable devices
sometime after 2012 :-)
BTW: can you successfully feed it from a set top box?
Antonio
8 Feb
8 Feb
3:30 p.m.
New subject: TV Licensing (Re: cctech Digest, Vol 78, Issue 3)
From: <arcarlini at iee.org>
To: "'General Discussion: On-Topic and Off-Topic Posts'"
<cctalk at classiccmp.org>
Sent: Sunday, February 07, 2010 7:37 PM
Subject: RE: cctech Digest, Vol 78, Issue 3
Oh, and you only need a licence to view content "live" (any contents,
not just BBC or even any UK channels, satellite stuff too ...) on
any device (TV, PC, phone, maybe even your fillings if you happen
to be an oddball synaesthete).
Actually no, I believe it's a licence to recieve, not to view, which is
why when you could still get a black and white licence at a cheaper
price than colour, you still needed a colour license even if you had a
black and white TV, if you also had a video recorder. The reason being
that the video recorder could recieve and record a colour signal, even
though you could only view it in black and white.
Though that is a moot point now as I believe it's been about 5 years
since the black and white license was phased out.
Cheers.
Phill.
--
Phill Harvey-Smith, Programmer, Hardware hacker, and general eccentric !
"You can twist perceptions, but reality won't budge" -- Rush.
3:48 p.m.
New subject: TV Licensing (Re: cctech Digest, Vol 78, Issue 3)
On 8 Feb 2010 at 23:30, Phill Harvey-Smith wrote:
Actually no, I believe it's a licence to recieve,
not to view, which
is why when you could still get a black and white licence at a cheaper
price than colour, you still needed a colour license even if you had a
black and white TV, if you also had a video recorder. The reason being
that the video recorder could recieve and record a colour signal, even
though you could only view it in black and white.
Though that is a moot point now as I believe it's been about 5 years
since the black and white license was phased out.
Really?
According to this:
http://www.tvlicensing.co.uk/check-if-you-need-one/
The B&W animal is still available. You may have to special-order it,
however.
--Chuck
4:32 p.m.
New subject: TV Licensing (Re: cctech Digest, Vol 78, Issue 3)
Chuck Guzis wrote:
On 8 Feb 2010 at 23:30, Phill Harvey-Smith wrote:
Well I seem to remember reading a story somewhere that they where
phasing them out obviously they didn't in the end, but cirtainly they're
no longer as available. Also they seem to have over doubled in price
since last time I had a B&W it was only ?21ish in 1992 :)
Cheers.
Phill.
--
Phill Harvey-Smith, Programmer, Hardware hacker, and general eccentric !
"You can twist perceptions, but reality won't budge" -- Rush.
Though that is a moot point now as I believe
it's been about 5 years
since the black and white license was phased out.
Really?
According to this:
http://www.tvlicensing.co.uk/check-if-you-need-one/
The B&W animal is still available. You may have to special-order it,
however.
4:07 p.m.
New subject: TV Licensing (Re: cctech Digest, Vol 78, Issue 3)
What I find really strange is this:
"A blind concession TV Licence costs ?71.25 for colour and ?24.00 for
a black and white TV Licence."
--Chuck
4:35 p.m.
New subject: TV Licensing (Re: cctech Digest, Vol 78, Issue 3)
Chuck Guzis wrote:
What I find really strange is this:
"A blind concession TV Licence costs ?71.25 for colour and ?24.00 for
a black and white TV Licence."
Well presumably if you say live in a house with a sighted person they
are still capable of watching in colour or black and white, but if you
are the person paying the license but blind.
Just a guess that is :)
Phill.
--
Phill Harvey-Smith, Programmer, Hardware hacker, and general eccentric !
"You can twist perceptions, but reality won't budge" -- Rush.
11:31 p.m.
New subject: TV Licensing (Re: cctech Digest, Vol 78, Issue 3)
On 09/02/2010 00:35, Phill Harvey-Smith wrote:
Chuck Guzis wrote:
True, but the real reason for the concession is that in this case
"blind" includes many that the rest of us might describe as "partially
sighted". So those who can't take full advantage of the full colour
moving picture experience pay less.
--
Pete Peter Turnbull
Network Manager
University of York
What I find really strange is this:
"A blind concession TV Licence costs ?71.25 for colour and ?24.00 for
a black and white TV Licence."
Well presumably if you say live in a house with a sighted person they
are still capable of watching in colour or black and white, but if you
are the person paying the license but blind.
9 Feb
9 Feb
11:54 a.m.
New subject: TV Licensing (Re: cctech Digest, Vol 78, Issue 3)
What I find really strange is this:
"A blind concession TV Licence costs =A371.25 for colour and =A324.00 for
a black and white TV Licence."
Why? Blind does not necessarily mean 'can't see anything at all'.
At one time we had to have radio (receiving) licences over here. Again
one per house, although I think a car radio needed a separate licence
(!). Registerd blind people got a free radio licence. When the radio
licence was abolished, they got a discount on a TV licence of the same
amount as the final cost of the radio license (I think it was either
\pounds 1.25 or \pounds 1.50 in decimal currency, but I might be wrong).
This discount stayed the same for many years, even though the TV
licence went up several times.
-tony
11:48 a.m.
New subject: TV Licensing (Re: cctech Digest, Vol 78, Issue 3)
Actually no, I believe it's a licence to recieve,
not to view, which is
why when you could still get a black and white licence at a cheaper
price than colour, you still needed a colour license even if you had a
black and white TV, if you also had a video recorder. The reason being
that the video recorder could recieve and record a colour signal, even
though you could only view it in black and white.
I wonder if that's acutally true. The TV licensing people couldn't tell
me what license would be required for a monochrome-only video recorder
(such things exist, I have one. It's a Sony reel-to-reel machine...). Or
for a video recorder that had been modified to record only in monochrome
(for example a Philips N1500 with the colour-killer switch hard wired in
the appropriate state).
Mind you, they also didn't know what, if any, licesnse is required for a
TV sound-only receiver. Or for a teletext-only receiver (such as the
units used with the BBC micro). For such devices, does 'colour' mean it
uses a colour monitor, or that it decodes the attribute bytes, or what?
The did tell me that if I modified a TV receiver so that it no longer
received TV, then it diddn't need a license. If I took a TV set,
desoldered the tuner module, and used the rest of it as a monitor, then I
didn't need a license. Even if I kepty the tuner module in my spares box.
The fact I had parts that could be assembled into a TV set did not mean I
had a TV set.
Many years ago I assembled the Maplin NICAM TV tuner kits. I bought said
kits in one of their shops (back when Maplin shops stocked interesting
items), and they didn't take my name or address. I was told that although
a lincense was needed to use the assembled kit, there was no license
check in buying a box of parts. The parts were not a TV receiver, they
could be used for all sorts of other things.
FWIW, all the above devies are used in a house that has a valid TV
license, so it didn;t really matter. Byt as=king annoying questions is a
hobby of mine...
-tony
4:46 p.m.
New subject: TV Licensing (Re: cctech Digest, Vol 78, Issue 3)
On 9 February 2010 19:48, Tony Duell <ard at p850ug1.demon.co.uk> wrote:
Mind you, they also didn't know what, if any, licesnse is required for a
TV sound-only receiver.
That one I can answer - no licence required:
"If you only use your digital box to produce sounds (i.e. you don't
use it to display programmes), then you don't need a TV Licence."
http://www.tvlicensing.co.uk/check-if-you-need-one/topics/technology-top8/
Or for a teletext-only receiver (such as the
units used with the BBC micro). For such devices, does 'colour' mean it
uses a colour monitor, or that it decodes the attribute bytes, or what?
It definitely used to be the monitor you used to display it. Given,
w.r.t. digital boxes they say:
"A black and white TV Licence does not cover the use of colour TV
receiving equipment, such as a digital box. The only exception is if
it's only used with a black and white TV set and the equipment can?t
record TV."
http://www.tvlicensing.co.uk/check-if-you-need-one/topics/understanding-you…
I suggest that the situation is the same.
The did tell me that if I modified a TV receiver so
that it no longer
received TV, then it diddn't need a license. If I took a TV set,
desoldered the tuner module, and used the rest of it as a monitor, then I
didn't need a license. Even if I kepty the tuner module in my spares box.
The fact I had parts that could be assembled into a TV set did not mean I
had a TV set.
You don't even need to go that far - just don't use it:
"You don't need a licence if you don't use any of these devices to
watch or record television programmes as they're being shown on TV -
for example, if you use your TV only to watch DVDs or play video
games, or you only watch programmes on your computer after they have
been shown on TV." [rather than as-live]
http://www.tvlicensing.co.uk/check-if-you-need-one/topics/what-if-a-tv-lice…
Many years ago I assembled the Maplin NICAM TV tuner kits. I bought said
kits in one of their shops (back when Maplin shops stocked interesting
items), and they didn't take my name or address. I was told that although
a lincense was needed to use the assembled kit, there was no license
check in buying a box of parts. The parts were not a TV receiver, they
could be used for all sorts of other things.
FWIW, all the above devies are used in a house that has a valid TV
license, so it didn;t really matter. Byt as=king annoying questions is a
hobby of mine...
Hotels and the like are only covered for 15 devices - then you need to
buy another licence for each five devices... so, in certain
circumstances it can be advantageous to know what needs a licence and
what doesn't.
http://www.tvlicensing.co.uk/check-if-you-need-one/topics/tv-licence-types-…
Rob
7 Feb
7 Feb
11:23 a.m.
As far as I
know, you do not live in London (England). So I can't
see how
you can tell me that PCs are available in the 'local dumpster'/
FWIW, dumpster diving is illegal in the UK.
That's...very weird to me.
11:41 a.m.
I don't know if anyone has ever been convicted
under this
law, and I am
darn sure that dumpster diving goes on with or without
permision. But if
there are no PCs in the skips, it doesn't matter whether it's
legal to
take them.
Given WEEE regs, companies are required to "properly dispose of"
all electrical equipment. These days we have a company come
round specifically to collect WEEE stuff (some of which can
be quite big at times :-)).
Before that we were only allowed to put electrical stuff in a
skip when we'd contaced the people who take the skip away to
make sure that they were doing the right things with WEEE
(or, more likely, to make sure that we had the right paperwork).
So intercepting stuff if you are on the outside is AFAICT
much harder than it used to be if not downright impossible.
Antonio
11:50 a.m.
On Feb 7, 2010, at 2:23 PM, Tony Duell wrote:
I beleive (from what I've read) that it's illegal to dumpster-dive
if the
dumpster is on private land in the States.
I think it "sort of" is...if it is in fact illegal, it's one of
those laws that's never enforced. Everyone dumpster-dives.
As far as I know, you do not live in London (England).
So I can't
see how
you can tell me that PCs are available in the 'local dumpster'/
FWIW, dumpster diving is illegal in the UK.
That's...very weird to me. I don't know if anyone has ever been convicted
under this law, and
I am
darn sure that dumpster diving goes on with or without permision.
But if
there are no PCs in the skips, it doesn't matter whether it's legal to
take them.
Indeed. And yes, it does go on all the time, at least around here.
-Dave
--
Dave McGuire
Port Charlotte, FL
12:31 p.m.
New subject: cctech Digest, Vol 78, Issue 3 or free computers in the rubbish/trash
I beleive that in the UK, stuff in a skip/dumpster is deemed to belong to
whoever owns the dumpster, and that it's technically stealing to remove
it (whether it is stealing to remove it if you put it there in the first
place -- e.g. if you threw somethign out that you didn't mean to -- I
don't know. But knowing our crazy laws I could well believe it is).
Well dont tell West Sussex county council where i get lots of tech junk...
i.e. Crawley recycling depot, its just sitting there in metal cages and
noone seems bothered it you take a bit.
Two weeks ago i found a nice 1970's Bang Olufsen Stereo..
Amstrads, Sun, junk generic PC's alsorts. I suspect a lot of businesses
near there (London Gatwick Airport is 2 miles away) drop off there
excess weee stuff there.
Rog
3:04 p.m.
New subject: Free computers in the rubbish/trash (was: Re: cctech Digest, Vol 78, Issue 3)
Roger Pugh wrote:
Well dont tell West Sussex county council where i get
lots of tech junk...
i.e. Crawley recycling depot, its just sitting there in metal cages and
noone seems bothered it you take a bit.
Some local councils have gone really anal recently. Last time I was down
at the recycling/household waste depot, they had a weighbridge on the
"in" road, and one on the "out" road. Your car is weighed going in and
coming out. If the car weighs more coming out, you get to explain to the
knuckle-dragging rent-a-droid why that happens to be the case.
Good fun, especially when the "out" weighbridge is out of calibration
relative to the "in" weighbridge.... "But we had it calibrated four
years ago!"
--
Phil.
classiccmp at philpem.me.uk
http://www.philpem.me.uk/
4:43 p.m.
New subject: Free computers in the rubbish/trash (was: Re: cctech Digest, Vol 78, Issue 3)
One must be sure to carry some bricks on the inbound trip, in such cases,
to implement the "Indiana Jones" method.
At 11:04 PM 2/7/2010 +0000, you wrote:
Roger Pugh wrote:
-----
1033. E clunibus tractum ("I pulled this out of my butt...")
--... ...-- -.. . -. ----. --.- --.- -...
tpeters at nospam.mixcom.com (remove "nospam") N9QQB (amateur radio)
"HEY YOU" (loud shouting) WEB: http://www.mixcom.com/tpeters
43? 7' 17.2" N by 88? 6' 28.9" W, Elevation 815', Grid Square
EN53wc
WAN/LAN/Telcom Analyst, Tech Writer, MCP, CCNA, Registered Linux User 385531
Well dont tell West Sussex county council where i
get lots of tech junk...
i.e. Crawley recycling depot, its just sitting there in metal cages and
noone seems bothered it you take a bit.
Some local councils have gone really anal recently. Last time I was down
at the recycling/household waste depot, they had a weighbridge on the "in"
road, and one on the "out" road. Your car is weighed going in and coming
out. If the car weighs more coming out, you get to explain to the
knuckle-dragging rent-a-droid why that happens to be the case.
Good fun, especially when the "out" weighbridge is out of calibration
relative to the "in" weighbridge.... "But we had it calibrated four years
ago!"
--
Phil.
classiccmp at philpem.me.uk
http://www.philpem.me.uk/ 
5:27 p.m.
New subject: Free computers in the rubbish/trash (was: Re: cctech Digest, Vol 78, Issue 3)
On Sun, 7 Feb 2010, Philip Pemberton wrote:
Roger Pugh wrote:
"Bethselamin is now so worried about the cumulative erosion by ten billion
visiting tourists a year that any net imbalance between the amount you eat
and the amount you excrete whilst on the planet is surgically removed from
your bodyweight when you leave: so every time you go to the lavatory it is
vitally important to get a receipt."
-- Douglas Adams
--
David Griffith
dgriffi at cs.csubak.edu
A: Because it fouls the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?
Well dont tell West Sussex county council where i
get lots of tech junk...
i.e. Crawley recycling depot, its just sitting there in metal cages and
noone seems bothered it you take a bit.
Some local councils have gone really anal recently. Last time I was down at
the recycling/household waste depot, they had a weighbridge on the "in" road,
and one on the "out" road. Your car is weighed going in and coming out. If
the car weighs more coming out, you get to explain to the knuckle-dragging
rent-a-droid why that happens to be the case.
Good fun, especially when the "out" weighbridge is out of calibration
relative to the "in" weighbridge.... "But we had it calibrated four years
ago!"
1:55 p.m.
>>> OK, I actuially have a US dime somwhere.
Please tell me where I can
>>> exchange it for 12 PCs capable of running FPGA or CPLD development
>>> software.
>>
I would. :) But I see PeeCees on the curb quite often.
Also, unless I missed something, Windows
isn't free. I I doubt that if I
found a junked PC that happeend to have a runnable copy of Windows on the
hard drivce the ntat would count as a valid Windows license. I don't
particulalry care for Windows, or any Microsoft product for that matter,
but that doesn't give me the right to pirate them.
So don't run Windows. FPGA/CPLD/PAL software runs on other platforms.
Indeed, large-scale chip design in the real world isn't typically done
under Windows. -Dave
PS. I have a design concept with about the
same number of gates as 6809
or a Z80.
2:05 p.m.
On Feb 7, 2010, at 4:55 PM, Ben wrote:
What happened to the saying "you give a inch, they take a mile"?
Huh?
Also, unless I missed something, Windows isn't
free. I I doubt
that if I
found a junked PC that happeend to have a runnable copy of
Windows on the
hard drivce the ntat would count as a valid Windows license. I don't
particulalry care for Windows, or any Microsoft product for that
matter,
but that doesn't give me the right to pirate them.
So don't run Windows. FPGA/CPLD/PAL software runs on other platforms.
Indeed, large-scale chip design in the real world isn't typically
done
under Windows. The whole point is FPGA/CPLD/PAL design is available
for the average
working person. Large scale chip design is *not* to my knowledge[1].
But FPGA/CPLD/PAL design *is*...and why wouldn't you want to use
professional tools instead of toys? Real tools are available.
PS. I have a design concept with about the same number
of gates as
6809 or a Z80.
Cool! Describe?
-Dave
--
Dave McGuire
Port Charlotte, FL
2:36 p.m.
Dave McGuire wrote:
See: CPLD design. This current design is CPLD/2901 bitslice design.
The ALU is 12 bits, double clocked to give a 24 bit CPU on a 6800/6502
style memory cycle.One CPLD is for high speed decoding and the other
for the MAR and MBR data paths. A 8 bit refresh counter is for DRAM's. A
2.5 MHZ (top speed)clock gives a 800 ns memory cycle. 3 2901's make
up the data path.
A LSI version would have 24 bits in the ALU, but with a 3 bit carry
skip adder. The logic design is slow but simple, with decoding taking
the first clock cycle and the second cycle for alu operations.
The whole
point is FPGA/CPLD/PAL design is available for the average
working person. Large scale chip design is *not* to my knowledge[1].
But FPGA/CPLD/PAL design *is*...and why wouldn't you want to use
professional tools instead of toys? Real tools are available.
PS. I have a design concept with about the same
number of gates as
6809 or a Z80.
Cool! Describe? -Dave
Ben.
2:57 p.m.
Ben wrote:
See: CPLD design. This current design is CPLD/2901
bitslice design.
The ALU is 12 bits, double clocked to give a 24 bit CPU on a 6800/6502
style memory cycle.One CPLD is for high speed decoding and the other
for the MAR and MBR data paths. A 8 bit refresh counter is for DRAM's. A
2.5 MHZ (top speed)clock gives a 800 ns memory cycle. 3 2901's make
up the data path.
A LSI version would have 24 bits in the ALU, but with a 3 bit carry
skip adder. The logic design is slow but simple, with decoding taking
the first clock cycle and the second cycle for alu operations.
Neat. Is this on the order of 2000 gates +/-? I was trying to lookup
the number of gates on the Z80 and 680x, and this is the closest I could
come. :)
Are you using verilog, VHDL, or something else? I have a Spartan-3e
starter kit that contains a CoolRunner?-II CPLD (XC2C64A-5VQ44C). I'm
in the process of using the FPGA, but haven't touched the CPLD. I
barely know how to spell it. :)
Keith
-Dave
Ben.
3:13 p.m.
New subject: cpld design
KeithM wrote:
Ben wrote:
I was doing it the other way. I have 8 24 bit registers and both
the Z80/6809 have about 6 16 bit registers, so I am in the ballpark
here.
See: CPLD design. This current design is
CPLD/2901 bitslice design.
The ALU is 12 bits, double clocked to give a 24 bit CPU on a 6800/6502
style memory cycle.One CPLD is for high speed decoding and the other
for the MAR and MBR data paths. A 8 bit refresh counter is for DRAM's.
A 2.5 MHZ (top speed)clock gives a 800 ns memory cycle. 3 2901's make
up the data path.
A LSI version would have 24 bits in the ALU, but with a 3 bit carry
skip adder. The logic design is slow but simple, with decoding taking
the first clock cycle and the second cycle for alu operations.
Neat. Is this on the order of 2000 gates +/-? I was trying to lookup the
number of gates on the Z80 and 680x, and this is the closest I could
come. :) -Dave
Ben. Are you using verilog, VHDL, or something else? I have
a Spartan-3e
starter kit that contains a CoolRunner?-II CPLD (XC2C64A-5VQ44C). I'm in
the process of using the FPGA, but haven't touched the CPLD. I barely
know how to spell it. :)
I am using 128 cell CPLD's, from Atmel with CPUL (wincpul) for
logic design. This language is at the gate level, but easy to use
compared to the other two design languages.
Keith
Ben.
4:31 p.m.
New subject: cpld design
Ben wrote:
I am using 128 cell CPLD's, from Atmel with CPUL
(wincpul) for
logic design. This language is at the gate level, but easy to use
compared to the other two design languages.
Interesting. I find Verilog easier to use than CUPL. Certainly for
register-based logic it makes the function of the code a bit more
obvious; for combinational logic it really doesn't matter (although
Verilog uses C-style expressions and thus might be a little easier for
your average software geek to understand... ahem :P )
VHDL on the other hand is evil, distilled into its purest form. In my
experience, what can be said in half a dozen lines of Verilog takes 30
or so in VHDL. CUPL seems to sit somewhere in the middle.
I was forced to learn to read VHDL at a previous job (some idiot lost
the register documentation for a glue-logic PLD, I got to rewrite it
from source). That experience and one or two like it
have put me off
VHDL for life!
I do, however, still use CUPL on occasion for creating fusemaps for
GALs... I think I've still got half a tube of DIL-packaged Lattice
GAL16V8s in my spares bin...
--
Phil.
classiccmp at philpem.me.uk
http://www.philpem.me.uk/
4:45 p.m.
New subject: cpld design
On 8 Feb 2010 at 0:31, Philip Pemberton wrote:
VHDL on the other hand is evil, distilled into its
purest form. In my
experience, what can be said in half a dozen lines of Verilog takes 30
or so in VHDL. CUPL seems to sit somewhere in the middle.
VHDL is the ADA of EDA languages--almost no one ever uses it because
they *want* to. I like Verilog very much; it's straightforward and
not too "dirty".
--Chuck
4:56 p.m.
New subject: cpld design
Chuck Guzis wrote:
VHDL is the ADA of EDA languages--almost no one ever
uses it because
they *want* to. I like Verilog very much; it's straightforward and
not too "dirty".
Agreed. I started using Verilog because it uses C style expressions (and
most of the operator precedence rules are the same), and the language
structure follows similar conventions. The keywords, OTOH, are more like
Pascal...
This does (IME) occasionally "lead you down the garden path" sometimes.
I've found myself thinking in terms of how I'd implement something in
software, then realising that I was writing HDL code and describing
hardware... Makes for some fun design quirks.
(Thankfully I think I've eliminated most of the ones that crept into the
DiscFerret disc analyser -- which is in the first stage of prototyping
at the moment. I'm currently prototyping and stress-testing the power
supply / voltage regulation circuitry)
--
Phil.
classiccmp at philpem.me.uk
http://www.philpem.me.uk/
10:28 p.m.
New subject: VHDL vs Verilog
Chuck Guzis wrote:
On 8 Feb 2010 at 0:31, Philip Pemberton wrote:
VHDL vs Verilog is another holy war, and about as useful as a 6502 vs
Z80 discussion. Thus I continue :
Personally I pity those who never get into VHDL and stay with Verilog,
and I will choose VHDL over Verilog any day.
Oh the agony when forced to use a Verilog testbench from our US
collegues.....
Jos Dreesen
VHDL on the other hand is evil, distilled into
its purest form. In my
experience, what can be said in half a dozen lines of Verilog takes 30
or so in VHDL. CUPL seems to sit somewhere in the middle.
VHDL is the ADA of EDA languages--almost no one ever uses it because
they *want* to. I like Verilog very much; it's straightforward and
not too "dirty".
--Chuck
8 Feb
8 Feb
8:50 a.m.
New subject: VHDL vs Verilog
On 8 Feb 2010 at 7:28, Jos Dreesen wrote:
VHDL vs Verilog is another holy war, and about as
useful as a 6502 vs
Z80 discussion. Thus I continue : Personally I pity those who never
get into VHDL and stay with Verilog, and I will choose VHDL over
Verilog any day. Oh the agony when forced to use a Verilog testbench
from our US collegues.....
I remember the Algol-FORTRAN cross-pond war of the 60s and 70s. :)
Now I wonder, "who won?" :)
--Chuck
11:26 a.m.
New subject: VHDL vs Verilog
AFAIK, all of our HDL stuff at work is done in VHDL.
________________________________
From: Jos Dreesen <jdr_use at bluewin.ch>
To: On-Topic and Off-Topic Posts <cctalk at classiccmp.org>
Sent: Mon, February 8, 2010 12:27:48 PM
Subject: Re: VHDL vs Verilog
I remember the Algol-FORTRAN cross-pond war of the 60s
and 70s. :)
Now I wonder, "who won?" :)
--Chuck
Nobody won....
For the HDL languages, both VHDL and Verilog are US creations.
I have no idea why Europe prefers VHDL, and US prefers Verilog.
Jos
10:42 a.m.
New subject: Algol vs Fortran was RE: VHDL vs Verilog
>>>
I remember the Algol-FORTRAN
cross-pond war of the 60s and 70s. :)
Now I wonder, "who won?" :)
<<<<
The easy answer is "C" :-)
You can look at it at least two ways:
* C has the structure of Algol with most of the dirty tricks and efficiency
of FORTRAN.
* C derives from multiple paths -
One of these ia PL/I (which derives from Fortran, Algol, and COBOL)
Another is from B which comes from BCPL which comes from CPL which was
essentially an extended Algol
However it seems that the saying: "I don't know what language engineers will
use in the future, but I know they'll call it Fortran." has mostly
turned-out mistaken.
Andy
1:10 p.m.
New subject: Algol vs Fortran was RE: VHDL vs Verilog
On 8 Feb 2010 at 18:42, Andy Holt wrote:
I remember the Algol-FORTRAN cross-pond war of the 60s
and 70s. :)
Now I wonder, "who won?" :)
The easy answer is "C" :-)
The curious thing is that the "structured" languages of the 70s
(Pascal and Modula-2) seem to have regressed to minority languages.
If anything, the language battles taught me that it's possible to
write unintelligible code in *any* language.
But I'd say that FORTRAN probably won the FORTRAN-Algol war in at
least one respect. Most of the nuclear arms race software was done
in it (or in dialects of it, such as LRLTRAN). I do not know what
the Soviets used, but it probably wasn't FORTRAN.
Let's see--the last standard revision to FORTRAN was Fortran 2003;
that to Algol was, what, Algol-68?
--Chuck
2:05 p.m.
New subject: Algol vs Fortran was RE: VHDL vs Verilog
Chuck Guzis wrote:
Let's see--the last standard revision to FORTRAN
was Fortran 2003;
that to Algol was, what, Algol-68?
Umm I still like Fortran IV. I know you can get II or IV for the PDP8.
Back on topic. The main advantage is Fortran's memory addressing does
not require local variables like Algol type languages.C is in the
middle, stack but not multi level indexing for simple variables.
Only with mini-computer architecture - PDP 11 for example did other
languages develop, other than LISP that never seems to have a practical
form but always R&D type stuff.
--Chuck
Ben.
3:50 p.m.
New subject: Algol vs Fortran was RE: VHDL vs Verilog
-----Original Message-----
From: bfranchuk at jetnet.ab.ca
Sent: Mon, 08 Feb 2010 15:05:16 -0700
To:
Subject: Re: Algol vs Fortran was RE: VHDL vs Verilog
Chuck Guzis wrote:
Here, here. The thing that impressed me about FORTRAN (well, as
as science major, anyway) was that it could do complex numbers as
a *NATIVE* datatype!! Now, I know for you OOP and C++ guys, custom,
exotic datatypes are a dime a dozen. But in 1980, I was sure glad
I could do complex math without all of the extra baggage that would
have been necessary if I had to use, say, BASIC-Plus.
Now I'm all nostalgic. Time to dredge up the the ol' 11/73 from
storage . . . .
-Jeff
Let's see--the last standard revision to
FORTRAN was Fortran 2003;
that to Algol was, what, Algol-68?
Umm I still like Fortran IV. I know you can get II or IV for the PDP8.
3:58 p.m.
New subject: Algol vs Fortran was RE: VHDL vs Verilog
On Feb 8, 2010, at 6:50 PM, N0body H0me wrote:
Here, here. The thing that impressed me about FORTRAN (well, as
as science major, anyway) was that it could do complex numbers as
a *NATIVE* datatype!! Now, I know for you OOP and C++ guys, custom,
exotic datatypes are a dime a dozen. But in 1980, I was sure glad
I could do complex math without all of the extra baggage that would
have been necessary if I had to use, say, BASIC-Plus.
Yeah, but how often do those C++ custom exotic datatypes map to
real datatypes supported by the hardware? (in other words, which
ones will actually be FAST?)
Let's see--the last standard revision to FORTRAN
was Fortran 2003;
that to Algol was, what, Algol-68?
Umm I still like Fortran IV. I know you can get II or IV for the
PDP8. Now I'm all nostalgic. Time to dredge up the the
ol' 11/73 from
storage . . . .
That sounds like the Right Thing To Do(tm).
-Dave
--
Dave McGuire
Port Charlotte, FL
4:27 p.m.
New subject: Algol vs Fortran was RE: VHDL vs Verilog
On 8 Feb 2010 at 18:58, somebody wrote:
> Here, here. The thing that impressed me about
FORTRAN (well, as as
> science major, anyway) was that it could do complex numbers as a
> *NATIVE* datatype!! Now, I know for you OOP and C++ guys, custom,
> exotic datatypes are a dime a dozen. But in 1980, I was sure glad I
> could do complex math without all of the extra baggage that would
> have been necessary if I had to use, say, BASIC-Plus.
Consider the vintage of FORTRAN--mainframes did not universally enjoy
computation in binary, much less ones' versus twos' complement.
Character sets were of differing content, collating sequence and
character length. Recursion as a permissable construct did not enter
the language until fairly late (some systems lacked native stack
facilities; the CDC 6000 series, like the PDP-8, simply stored a jump
to the return address at the entry point of a subroutine). I/O
implementation could be wildly different.
ANSI X3 committee meetings were more like political conventions in
some respects. I recall that when vector language features were being
proposed for Fortran 8X (to become Fortran 90), the DEC and IBM
contingent threatened to walk out of the proceedings because the
committee decided not to simply assume IBM VECTRAN as its basis.
It's really amazing that FORTRAN/Fortran is still around.
--Chuck
5:19 p.m.
New subject: Algol vs Fortran was RE: VHDL vs Verilog
-----Original Message-----
From: cclist at sydex.com
Sent: Mon, 08 Feb 2010 16:27:50 -0800
To: cctalk at classiccmp.org
Subject: Re: Algol vs Fortran was RE: VHDL vs Verilog
On 8 Feb 2010 at 18:58, somebody wrote:
Point taken: There is only so much you can do to facilitate
portability when such fundamental differences exist. This
diversity doesn't exist today, and I think we are the worse
for it. I suspect each of those approaches gave their machines
some advantage or suitability for different tasks.
Today, we just throw more MIPS at our one-cpu-fits-all approach.
> Here, here. The thing that impressed me
about FORTRAN (well, as as
> science major, anyway) was that it could do complex numbers as a
> *NATIVE* datatype!! Now, I know for you OOP and C++ guys, custom,
> exotic datatypes are a dime a dozen. But in 1980, I was sure glad I
> could do complex math without all of the extra baggage that would
> have been necessary if I had to use, say, BASIC-Plus.
Consider the vintage of FORTRAN--mainframes did not universally enjoy
computation in binary, much less ones' versus twos' complement.
Character sets were of differing content, collating sequence and
character length. Recursion as a permissable construct did not enter
the language until fairly late (some systems lacked native stack
facilities; the CDC 6000 series, like the PDP-8, simply stored a jump
to the return address at the entry point of a subroutine). I/O
implementation could be wildly different. ANSI X3 committee meetings were more like political
conventions in
some respects. I recall that when vector language features were being
proposed for Fortran 8X (to become Fortran 90), the DEC and IBM
contingent threatened to walk out of the proceedings because the
committee decided not to simply assume IBM VECTRAN as its basis.
Sigh. That's what happens when the focus shifts away from the
science of computing and on to marketing. I'll never deny marketing's
role in making computing accessible to everyone; but I'm holding
it accountable for seriously messing up good ideas and consigning
them to oblivion because they don't think it will sell.
It's really amazing that FORTRAN/Fortran is still
around.
I think maybe that speaks more of the solidity of the earlier
implementations of that language, rather than 'advances' made
since the PC era.
-Jeff
____________________________________________________________
Receive Notifications of Incoming Messages
Easily monitor multiple email accounts & access them with a click.
Visit http://www.inbox.com/notifier and check it out!
8:23 p.m.
New subject: Algol vs Fortran was RE: VHDL vs Verilog
FORTRAN is an example of a targeted solution to a problem space and, as such, is still
quite useful. I consider C to be my 'mother tongue' (despite having learned
FORTRAN years earlier), but if I were doing straight numeric work I'd much rather do
it in something like FORTRAN because I don't have to spend my time building program
'infrastructure' instead of writing math algorithms. -- Ian
________________________________________
From: cctalk-bounces at classiccmp.org [cctalk-bounces at classiccmp.org] On Behalf Of
Chuck Guzis [cclist at sydex.com]
Sent: Monday, February 08, 2010 4:27 PM
To: General Discussion: On-Topic and Off-Topic Posts
Subject: Re: Algol vs Fortran was RE: VHDL vs Verilog
On 8 Feb 2010 at 18:58, somebody wrote:
> Here, here. The thing that impressed me about
FORTRAN (well, as as
> science major, anyway) was that it could do complex numbers as a
> *NATIVE* datatype!! Now, I know for you OOP and C++ guys, custom,
> exotic datatypes are a dime a dozen. But in 1980, I was sure glad I
> could do complex math without all of the extra baggage that would
> have been necessary if I had to use, say, BASIC-Plus.
Consider the vintage of FORTRAN--mainframes did not universally enjoy
computation in binary, much less ones' versus twos' complement.
Character sets were of differing content, collating sequence and
character length. Recursion as a permissable construct did not enter
the language until fairly late (some systems lacked native stack
facilities; the CDC 6000 series, like the PDP-8, simply stored a jump
to the return address at the entry point of a subroutine). I/O
implementation could be wildly different.
ANSI X3 committee meetings were more like political conventions in
some respects. I recall that when vector language features were being
proposed for Fortran 8X (to become Fortran 90), the DEC and IBM
contingent threatened to walk out of the proceedings because the
committee decided not to simply assume IBM VECTRAN as its basis.
It's really amazing that FORTRAN/Fortran is still around.
--Chuck
10 p.m.
New subject: Algol vs Fortran was RE: VHDL vs Verilog
On 8 Feb 2010 at 20:23, Ian King wrote:
FORTRAN is an example of a targeted solution to a
problem space and,
as such, is still quite useful. I consider C to be my 'mother tongue'
(despite having learned FORTRAN years earlier), but if I were doing
straight numeric work I'd much rather do it in something like FORTRAN
because I don't have to spend my time building program
'infrastructure' instead of writing math algorithms.
Few remember that many early microprocessor cross-assemblers were
written in FORTRAN to execute on whatever mini- or mainframe you had
available, be it a Data General Nova or CDC 7600. Inevitably, these
programs would start with a READ of a statement using A1 format into
an array to obtain the character set of the host. Character
manipulation was then handled by referencing this array.
At the time, FORTRAN was probably the most portable language that
there was, as long as one wasn't tempted to give in to using a
vendor's unique language extensions.
Was COBOL 75 the first ANSI language standard that prohibited such
extensions? Not that anyone paid much attention other than
implementing a "strict ANSI checking" compiler switch.
--Chuck
4:32 p.m.
New subject: Algol vs Fortran was RE: VHDL vs Verilog
-----Original Message-----
From: mcguire at neurotica.com
Sent: Mon, 8 Feb 2010 18:58:57 -0500
To: cctalk at classiccmp.org
Subject: Re: Algol vs Fortran was RE: VHDL vs Verilog
On Feb 8, 2010, at 6:50 PM, N0body H0me wrote:
Here, here. The thing that impressed me about FORTRAN (well, as
as science major, anyway) was that it could do complex numbers as
a *NATIVE* datatype!! Now, I know for you OOP and C++ guys, custom,
exotic datatypes are a dime a dozen. But in 1980, I was sure glad
I could do complex math without all of the extra baggage that would
have been necessary if I had to use, say, BASIC-Plus.
Yeah, but how often do those C++ custom exotic datatypes map to
real datatypes supported by the hardware? (in other words, which
ones will actually be FAST?)
That's certainly an issue. I wonder how many applications are slower and more
overweight due to their being crafted with OOP than they would be if they were coded using
more traditional methods.
Our school didn't have a float point unit on our PDP-11; I was
*certain* that DEC's FORTRAN compiler could generate much faster
code than anything I could bodge together using BASIC (of any stripe),
and I could code it in less time.
My principal fascination with FORTRAN from the beginning, was
that it had this 'purpose built' feature to easily handle complex
math (and it did it quite well, IIRC). I have great respect for
individuals who insist on purpose-built tools.
-Jeff
Let's see--the last standard revision to FORTRAN
was Fortran 2003;
that to Algol was, what, Algol-68?
Umm I still like Fortran IV. I know you can get II or IV for the
PDP8. Now I'm all nostalgic. Time to dredge up the
the ol' 11/73 from
storage . . . .
That sounds like the Right Thing To Do(tm).
-Dave
--
Dave McGuire
Port Charlotte, FL
9 Feb
9 Feb
12:02 a.m.
New subject: Algol vs Fortran was RE: VHDL vs Verilog
On Feb 8, 2010, at 7:32 PM, N0body H0me wrote:
That's certainly an issue. I wonder how many applications are
slower and more overweight due to their being crafted with OOP than
they would be if they were coded using more traditional methods.
"More traditional methods"? Just "the way processors execute
code" would be a good start. Processors aren't object-oriented in
nature. This is one of the reasons why we have computers with multi-
GHz processors that barely get out of their own way. The constructs
commonly used in OO programming don't come anywhere close to mapping
to hardware efficiently.
Here, here. The thing that impressed me about FORTRAN
(well, as
as science major, anyway) was that it could do complex numbers as
a *NATIVE* datatype!! Now, I know for you OOP and C++ guys, custom,
exotic datatypes are a dime a dozen. But in 1980, I was sure glad
I could do complex math without all of the extra baggage that would
have been necessary if I had to use, say, BASIC-Plus.
Yeah, but how often do those C++ custom exotic datatypes map to
real datatypes supported by the hardware? (in other words, which
ones will actually be FAST?) Our school didn't have a float point unit on our
PDP-11; I was
*certain* that DEC's FORTRAN compiler could generate much faster
code than anything I could bodge together using BASIC (of any stripe),
and I could code it in less time.
Indeed. What model of -11 was it? My first PDP-11, an 11/34a
around 1985 or so, came with an FP-11A. I spent many a late night
hacking on fun stuff like fractal algorithms and such, much to my
grandmother's annoyance. It'd be 2AM on a school night, she'd trudge
by my bedroom door in her slippers and bathrobe, and I'd look up from
my terminal and see her glaring at me, her annoyed face illuminated
only by the "ready" lights of the RL02s and RK07, and the KY11-LB
displays on the 11/34a. The FP-11A was one of my favorite parts of
that system.
My principal fascination with FORTRAN from the
beginning, was
that it had this 'purpose built' feature to easily handle complex
math (and it did it quite well, IIRC). I have great respect for
individuals who insist on purpose-built tools.
It was built to solve problems that often involved complex
numbers. I respect it for the same reason. I'm also impressed with
it because it's *fast* for Big Math.
-Dave
--
Dave McGuire
Port Charlotte, FL
1:10 a.m.
New subject: Algol vs Fortran was RE: VHDL vs Verilog
Dave McGuire wrote:
On Feb 8, 2010, at 7:32 PM, N0body H0me wrote:
What "commonly used" constructs are these that are so horribly
inefficient that they would make a multi-GHz processor stumble? (And in
what language(s)?)
- Josh
That's certainly an issue. I wonder how many applications are slower
and more overweight due to their being crafted with OOP than they
would be if they were coded using more traditional methods.
"More traditional methods"? Just "the way processors execute code"
would be a good start. Processors aren't object-oriented in nature.
This is one of the reasons why we have computers with multi-GHz
processors that barely get out of their own way. The constructs
commonly used in OO programming don't come anywhere close to mapping
to hardware efficiently.
-Dave
10 a.m.
New subject: Algol vs Fortran was RE: VHDL vs Verilog
On Feb 9, 2010, at 4:10 AM, Josh Dersch wrote:
What "commonly used" constructs are these that are so horribly
inefficient that they would make a multi-GHz processor stumble?
(And in what language(s)?)
OBJECTS!
Our processors have registers, ALUs, and memory locations...not
objects. (iAPX432 notwithstanding) Constructs that don't map to
that paradigm are going to be inefficient, to a degree that
corresponds to how badly they match the paradigm. And objects don't
map to it at all.
-Dave
--
Dave McGuire
Port Charlotte, FL
That's certainly an issue. I wonder how many
applications are
slower and more overweight due to their being crafted with OOP
than they would be if they were coded using more traditional
methods.
"More traditional methods"? Just "the way processors execute
code" would be a good start. Processors aren't object-oriented in
nature. This is one of the reasons why we have computers with
multi-GHz processors that barely get out of their own way. The
constructs commonly used in OO programming don't come anywhere
close to mapping to hardware efficiently. 
10:06 a.m.
New subject: Algol vs Fortran was RE: VHDL vs Verilog
What
"commonly used" constructs are these that are so horribly
inefficient that they would make a multi-GHz processor stumble?
(And in what language(s)?)
OBJECTS!
Our processors have registers, ALUs, and memory locations...not
objects. (iAPX432 notwithstanding) Constructs that don't map to
that paradigm are going to be inefficient, to a degree that
corresponds to how badly they match the paradigm. And objects don't
map to it at all.
10:16 a.m.
New subject: Algol vs Fortran was RE: VHDL vs Verilog
On Feb 9, 2010, at 1:06 PM, Cameron Kaiser wrote:
Rekursiv!
I liked a lot of the ideas in the 432. Too bad it was a pig.
Me too. I wonder if enough architectural information is out there
to resurrect the design. Intel will surely never do it. (not that
they necessarily should)
-Dave
--
Dave McGuire
Port Charlotte, FL
What "commonly used" constructs are these
that are so horribly
inefficient that they would make a multi-GHz processor stumble?
(And in what language(s)?)
OBJECTS!
Our processors have registers, ALUs, and memory locations...not
objects. (iAPX432 notwithstanding) Constructs that don't map to
that paradigm are going to be inefficient, to a degree that
corresponds to how badly they match the paradigm. And objects don't
map to it at all.
10:37 a.m.
New subject: Algol vs Fortran was RE: VHDL vs Verilog
Dave McGuire wrote:
Me too. I wonder if enough architectural information
is out there to
resurrect the design. Intel will surely never do it. (not that they
necessarily should)
I think the problem is the machine has *too small* a memory.
The other problem is several languages: FORTH LISP come to mind as
they don't cache or pipe-line well.
-Dave
Ben.
PS. The only small portable compiler I can find
is Small C - version 1.0.
11:09 a.m.
New subject: Algol vs Fortran was RE: VHDL vs Verilog
e.stiebler wrote:
Ben wrote:
no... for a small machine Z80/6809 ect. Hmm time to change the subject line.
How did that work back then to get software created for a new machine?
8080's had PLM compiled on a VAX or something along the same lines.
Ben.
PS. The only small portable compiler I can find
is Small C - version 1.0.
For the iapx432 ?
11:21 a.m.
New subject: Algol vs Fortran was RE: VHDL vs Verilog
On Feb 9, 2010, at 2:09 PM, Ben wrote:
no... for a small machine Z80/6809 ect. Hmm time to change the
subject line.
How did that work back then to get software created for a new machine?
8080's had PLM compiled on a VAX or something along the same lines.
Cross-assemblers too. There was a very nice suite of cross-
assemblers that ran on PDP-11s under RT-11 and targeted many
different microprocessors. That cross-assembler suite was later
ported to UNIX and now lives on in many embedded toolchains, not the
least of which is SDCC.
Speaking of SDCC...if you're looking for a good Z80 C compiler, it
does target that architecture, among others. It's mature, quite
popular and has a quick development pace. Its primary target is the
mcs51 architecture, but it supports several others.
-Dave
--
Dave McGuire
Port Charlotte, FL
PS. The only small portable compiler I can find
is Small C - version 1.0.
For the iapx432 ?
11:23 a.m.
New subject: Algol vs Fortran was RE: VHDL vs Verilog
no... for a small machine Z80/6809 ect. Hmm time to
change the subject line.
How did that work back then to get software created for a new machine?
8080's had PLM compiled on a VAX or something along the same lines.
Hand-coded it, I would imagine. I've handcoded runtimes before for
compilers yet to be ported, created a cross-compiler, and had the compiler
compile itself for the target. Not exactly trivial, of course.
--
------------------------------------ personal: http://www.cameronkaiser.com/ --
Cameron Kaiser * Floodgap Systems * www.floodgap.com * ckaiser at floodgap.com
-- If your troubles are deep seated and of long-standing, try kneeling. -------
11:35 a.m.
New subject: Algol vs Fortran was RE: VHDL vs Verilog
On 9 Feb 2010 at 12:09, Ben wrote:
no... for a small machine Z80/6809 ect. Hmm time to
change the subject
line. How did that work back then to get software created for a new
machine? 8080's had PLM compiled on a VAX or something along the same
lines. Ben.
Cross-compilation/assembly. My first assemblers for the 8008 and
8080 ran on a mainframe and were coded in--wait for it--FORTRAN.
Before that, well, have you ever coded in machine code? IBM even
used to have coding forms for a few machines that were used to
facilitate that.
--Chuck
11:50 a.m.
New subject: Algol vs Fortran was RE: VHDL vs Verilog
On Tue, Feb 9, 2010 at 2:35 PM, Chuck Guzis <cclist at sydex.com> wrote:
On 9 Feb 2010 at 12:09, Ben wrote:
The first 68000 assembler I ever used was written in Whitesmiths C and
ran on VMS 3.4. It was long in use when I ran into it in 1984 - I
think it was written around 1982 or so.
We did run PALASM (written in FORTRAN) on that same VAX.
no... for a small machine Z80/6809 ect. Hmm time
to change the subject
line. How did that work back then to get software created for a new
machine? 8080's had PLM compiled on a VAX or something along the same
lines. Ben.
Cross-compilation/assembly. ?My first assemblers for the 8008 and
8080 ran on a mainframe and were coded in--wait for it--FORTRAN. Before that, well, have you ever coded in machine
code?
Yep. Did that on the 6502 before I got a line-at-a-time
assembler/monitor ROM. Also did that on the Elf - toggled in the
bits, too. By the time I was working on the aforementioned VAX, it
was no big deal for me to whip out 10-20 instruction programs in ODT
on our 11/03 and 11/04 testbeds. I also worked with a guy at UW that
could enter 1802 programs right into the EPROM programmer as sequences
of bytes in hex.
PITA for larger programs, especially branch calculations, but when you
don't have abstract development tools, it's one way to bootstrap
yourself up.
?IBM even used to have coding forms for a few machines
that were used to
facilitate that.
I've got a pad of those, I think, for an early-1960s IBM machine (IBM
1401?). They came in a computer correspondence course lesson pack.
The instructions were represented as EBCDIC characters (letters,
numbers, punctuation), and you drew up the program as streams of BCD
entities that would get manually punched onto cards later.
-ethan
12:03 p.m.
New subject: Algol vs Fortran was RE: VHDL vs Verilog
On 9 Feb 2010 at 14:50, Ethan Dicks wrote:
I've got a pad of those, I think, for an
early-1960s IBM machine (IBM
1401?). They came in a computer correspondence course lesson pack.
The instructions were represented as EBCDIC characters (letters,
numbers, punctuation), and you drew up the program as streams of BCD
entities that would get manually punched onto cards later.
Probably 1401 autocoder. Not EBCDIC--that didn't come along until
S/360. Most likely just plain old "BCD" punch card code.
I used to have a pad labeled "IBM 1620 Absolute Coding System" (they
were the reverse sides of the SPS coding form pages. One column (5
positions) to record the address of the instruction, another for the
opcode (2 positions), and one each (5 positions) for the P- and Q-
address. You coded it up and then punched it, remembering that a
record mark was an 0-8-2 multipunch and a numeric blank was an 8-4.
Add an 11-punch (minus sign) for any flagged digits.
--Chuck
noon
New subject: Algol vs Fortran was RE: VHDL vs Verilog
Chuck Guzis wrote:
Cross-compilation/assembly. My first assemblers for the 8008 and
8080 ran on a mainframe and were coded in--wait for
it--FORTRAN.
I had access to a IBM-1130. Fortran was favored over ASM.
Before that, well, have you ever coded in machine
code? IBM even
used to have coding forms for a few machines that were used to
facilitate that.
I am building a 12/24 bit cpu. I may have to hack together
a Cross-Compiler for my machine in Fortran IV for the the PDP-8
(SBC6120) I have here. Back to downloading more PDF manuals from
bitsavers and figuring how to configure my software.
--Chuck
Good time to buy more vintage hardware
stuff. :)
Ben.
10:59 a.m.
New subject: iapx432, was : Re: Algol vs Fortran was RE: VHDL vs Verilog
Dave McGuire wrote:
[ iapx432]
Me too. I wonder if enough architectural information is out there to
resurrect the design. Intel will surely never do it. (not that they
necessarily should)
Eric has a pretty page about it :
http://www.brouhaha.com/~eric/retrocomputing/intel/iapx432/#documentation
looks good enough to start ...
;-)
11:22 a.m.
New subject: iapx432, was : Re: Algol vs Fortran was RE: VHDL vs Verilog
On Feb 9, 2010, at 1:59 PM, e.stiebler wrote:
Hooboy. Not this week!
--
Dave McGuire
Port Charlotte, FL
[ iapx432]
Me too. I wonder if enough architectural information is out there
to resurrect the design. Intel will surely never do it. (not
that they necessarily should)
Eric has a pretty page about it :
http://www.brouhaha.com/~eric/retrocomputing/intel/iapx432/
#documentation
looks good enough to start ...
;-)
10:44 a.m.
New subject: Algol vs Fortran was RE: VHDL vs Verilog
Dave McGuire wrote:
On Feb 9, 2010, at 4:10 AM, Josh Dersch wrote:
What "commonly used" constructs are these that are so horribly
inefficient that they would make a multi-GHz processor stumble? (And
in what language(s)?)
OBJECTS!
Our processors have registers, ALUs, and memory locations...not
objects. (iAPX432 notwithstanding) Constructs that don't map to that
paradigm are going to be inefficient, to a degree that corresponds to
how badly they match the paradigm. And objects don't map to it at all.
That's not answering my question. What part of implementing OBJECTS!
are modern compilers for OO-language-du-jour incapable of translating
efficiently to native machine code? And why? And what exactly is the
performance hit in the cases you're thinking of?
How, precisely, do objects NOT map to registers or memory locations in
modern OO languages? Where does the inefficiency come in? How much
faster than a Sparc IPX running FVWM would my machine be if my existing
software had been written in C instead of
horribly-inefficient-language? Details, please.
Josh
That's certainly an issue. I wonder how many
applications are
slower and more overweight due to their being crafted with OOP than
they would be if they were coded using more traditional methods.
"More traditional methods"? Just "the way processors execute
code" would be a good start. Processors aren't object-oriented in
nature. This is one of the reasons why we have computers with
multi-GHz processors that barely get out of their own way. The
constructs commonly used in OO programming don't come anywhere close
to mapping to hardware efficiently. -Dave
10:56 a.m.
New subject: Algol vs Fortran was RE: VHDL vs Verilog
On Feb 9, 2010, at 1:44 PM, Josh Dersch wrote:
That's not answering my question. What part of implementing
OBJECTS! are modern compilers for OO-language-du-jour incapable of
translating efficiently to native machine code? And why? And what
exactly is the performance hit in the cases you're thinking of?
How, precisely, do objects NOT map to registers or memory locations
in modern OO languages? Where does the inefficiency come in?
Ok. Show me a processor that has an "object" data type, that has
subtypes like "member" and "method" and such. There aren't any.
Translating from such incredibly high-level constructs to registers,
stacks, and memory locations is not without a lot of overhead. Try
to envision what happens in the instruction stream during things like
virtual function lookups in C++, for example.
It's similar to using floating-point math on a processor with no
floating-point support. It all has to be implemented in software,
and it's slow. Going a bit farther back, processors lacking hardware
multiply and divide...we ended up using subroutines and macros, and
it was a lot slower.
What "commonly used" constructs are these
that are so horribly
inefficient that they would make a multi-GHz processor stumble?
(And in what language(s)?)
OBJECTS!
Our processors have registers, ALUs, and memory locations...not
objects. (iAPX432 notwithstanding) Constructs that don't map to
that paradigm are going to be inefficient, to a degree that
corresponds to how badly they match the paradigm. And objects
don't map to it at all.
How much faster than a Sparc IPX running FVWM would
my machine be
if my existing software had been written in C instead of horribly-
inefficient-language? Details, please.
Why are you asking this question?
-Dave
--
Dave McGuire
Port Charlotte, FL
11:19 a.m.
New subject: Algol vs Fortran was RE: VHDL vs Verilog
Dave McGuire wrote:
On Feb 9, 2010, at 1:44 PM, Josh Dersch wrote:
That's not answering my question. What part of implementing OBJECTS!
are modern compilers for OO-language-du-jour incapable of translating
efficiently to native machine code? And why? And what exactly is
the performance hit in the cases you're thinking of?
How, precisely, do objects NOT map to registers or memory locations
in modern OO languages? Where does the inefficiency come in?
Ok. Show me a processor that has an "object" data type, that has
subtypes like "member" and "method" and such. There aren't any.
Translating from such incredibly high-level constructs to registers,
stacks, and memory locations is not without a lot of overhead. Try to
envision what happens in the instruction stream during things like
virtual function lookups in C++, for example.
Ok, I'm envisioning it. A few
instructions to do a vtable lookup and a
jump to the correct virtual function. Wow. So those extra instructions
are what's making every machine in the world (apparently) very very slow?
In C#, virtual lookups are cached at runtime so the cost of the first
virtual call to a function goes through the vtable routine; future calls
are very fast.
Objects in their raw form are not "incredibly high-level." In C++, an
object is referenced via a pointer; data fields are accessed via offsets
just like in C. There is a small overhead for virtual function
dispatch. I fail to see how this overhead is somehow responsible for
performance problems in computers today.
What other overheads/inefficiencies are you thinking of?
What "commonly used" constructs are these
that are so horribly
inefficient that they would make a multi-GHz processor stumble?
(And in what language(s)?)
OBJECTS!
Our processors have registers, ALUs, and memory locations...not
objects. (iAPX432 notwithstanding) Constructs that don't map to
that paradigm are going to be inefficient, to a degree that
corresponds to how badly they match the paradigm. And objects don't
map to it at all.
It's similar to using floating-point math on a processor with no
floating-point support. It all has to be implemented in software, and
it's slow. Going a bit farther back, processors lacking hardware
multiply and divide...we ended up using subroutines and macros, and it
was a lot slower.
You keep talking about how OO programming is the reason that software
today is so inefficient but you offer no data to back it up other than
"it doesn't map to the hardware."
And you brought it up in another response:
How much faster than a Sparc IPX running FVWM
would my machine be
if my existing software had been written in C instead of
horribly-inefficient-language? Details, please.
Why are you asking this question? A modern multi-GHz Linux box running GTK is far less
"responsive"-feeling than my old SPARCstation-IPX running fvwm when
just tooling around the GUI. A little more time spent by the
programmers, ignoring the "easy way out" or heavy OO programming and
it'd be FAR faster.
So it finally comes out: it's the *bad progammers* at fault here. I
knew it all along! Don't confuse poor programmers with programming
languages. There are always efficiency tradeoffs in programming
languages and a good programmer knows how to make the right choices.
Josh
-Dave
12:28 p.m.
New subject: Algol vs Fortran was RE: VHDL vs Verilog
On Feb 9, 2010, at 2:19 PM, Josh Dersch wrote:
Yes, to a large degree! You're talking about it as if it happens
ONCE, and you know it doesn't. Would you care to estimate how many
of those vtable lookup happen when someone simply clicks a mouse in a
modern OS? I don't know for certain, but I'm willing to bet that
it's thousands.
Yes, I have to acknowledge this; you'll get no argument from me
there. But bad programmers are the rule, not the exception. Code
written by bad programmers constitutes 90% of the code written
today. It's possible to write fast, compact C++ or Java code; we've
both seen it. But it's not the norm. KDE, OS X (and several of its
apps, Mail.app comes to mind) *are* the norm, and they're both
horribly slow for the hardware they're typically run on.
In an ideal world, one in which all programmers were competent, OO
languages wouldn't be such a problem. So I guess what I really mean
is, "Bad programmers are even more detrimental to computing when
armed with OO languages".
-Dave
--
Dave McGuire
Port Charlotte, FL
Ok. Show me
a processor that has an "object" data type, that
has subtypes like "member" and "method" and such. There aren't
any. Translating from such incredibly high-level constructs to
registers, stacks, and memory locations is not without a lot of
overhead. Try to envision what happens in the instruction stream
during things like virtual function lookups in C++, for example.
Ok, I'm envisioning it. A few instructions to do a vtable lookup
and a jump to the correct virtual function. Wow. So those extra
instructions are what's making every machine in the world
(apparently) very very slow? In C#, virtual lookups are cached at runtime so the
cost of the
first virtual call to a function goes through the vtable routine;
future calls are very fast.
That's nice. Now if only C# weren't a proprietary product from
one company which happens to be obsessed with creating vendor lock-in
situations. ;)
(though actually, hmm, that IS rather nice...)
Objects in their raw form are not "incredibly
high-level." In C++,
an object is referenced via a pointer; data fields are accessed via
offsets just like in C. There is a small overhead for virtual
function dispatch. I fail to see how this overhead is somehow
responsible for performance problems in computers today.
There's a bit of congruity between C's structs and C++/C#/Java/etc
objects, but..
What other overheads/inefficiencies are you thinking
of?
...what happens when someone uses an Integer instead of an int? A
whole object gets created when all one likely needed was a memory
location. What happens when one adds that Integer to another
Integer? Add in the address offset calculations to find out where
the actual int is stored within the Integer object, what would those
be on most architectures...two or three instructions? So our nice
single-instruction add turns into at least five instructions.
So you're arguing that increasing the number of instructions
required to execute a simple operation by a factor of five doesn't
involve overhead? Ok, howabout when it happens all the time, which
additions tend to in most programs?
In C (for example), there's no motivation at all to wrap a struct
around an int just for the sake of doing so, so it doesn't happen.
And howabout template programming. I've never seen executables so
big as the ones in which templates were overused. (yes, here I have
to give a nod to your point about bad programmers below!) All in the
name of "saving programmer time", as if that's such a big deal,
consequences be damned.
Note well, however, that I'm talking about more than just the
number of instructions required to accomplish a given task. Sure,
that in itself has bad side effects when you think about what it does
to the instruction cache hit rates...the principal of locality of
reference is blown out the window. But what about memory
utilization? How big, in bytes, is an Integer compared to an int?
Ok, the difference may be only a few bytes, but what about the
program (which would be "most of them") with tens of thousands of
them? (I'm typing this on a Mac, into Mail.app, which is currently
eating 1.73GB of memory)
You keep talking about how OO programming is the
reason that
software today is so inefficient but you offer no data to back it
up other than "it doesn't map to the hardware."
I'm sorry, but knowing how processors work, it's pretty obvious to
me. The data that backs it up is lots of programs (some of which are
operating systems) that I use every day, written in OO languages,
including (perhaps especially!) OS X, are far slower than they should
be given the hardware they're running on. YOU know how processors
work too, I know you do, so I know you see my point.
A modern
multi-GHz Linux box running GTK is far less "responsive"-
feeling than my old SPARCstation-IPX running fvwm when just
tooling around the GUI. A little more time spent by the
programmers, ignoring the "easy way out" or heavy OO programming
and it'd be FAR faster.
So it finally comes out: it's the *bad progammers* at fault here.
I knew it all along! Don't confuse poor programmers with
programming languages. There are always efficiency tradeoffs in
programming languages and a good programmer knows how to make the
right choices.
12:49 p.m.
New subject: Algol vs Fortran was RE: VHDL vs Verilog
On Feb 9, 2010, at 12:28 PM, Dave McGuire <mcguire at neurotica.com> wrote:
Depends greatly on the language. Don't confuse one implementation
with ALL OO programming languages. In C++ an integer maps to a
register. Same in C#. Same in objc. Java does this differently.
This is only a valid argument if you have an OS X written in plain C
and an OS X written in OO that you can do a real comparison between.
Anything else is speculation. OO does have its overheads, I disagree
that they are anywhere nearly as bad as you claim them to be.
Speculating that OS foo is far slower than it "should be" based on
anecdotal evidence is not proof.
Yes, I have to acknowledge this; you'll get no argument from me
there. But bad programmers are the rule, not the exception. Code
written by bad programmers constitutes 90% of the code written
today. It's possible to write fast, compact C++ or Java code; we've
both seen it. But it's not the norm. KDE, OS X (and several of its
apps, Mail.app comes to mind) *are* the norm, and they're both
horribly slow for the hardware they're typically run on.
In an ideal world, one in which all programmers were competent, OO
languages wouldn't be such a problem. So I guess what I really mean
is, "Bad programmers are even more detrimental to computing when
armed with OO languages".
You really think these same programmers would somehow write better
code if only they would stop using OO?
Josh
On Feb 9, 2010, at 2:19 PM, Josh Dersch wrote:
Yes, to a large degree! You're talking about it as if it happens
ONCE, and you know it doesn't. Would you care to estimate how many
of those vtable lookup happen when someone simply clicks a mouse in
a modern OS? I don't know for certain, but I'm willing to bet that
it's thousands.
I'm not going to speculate on things I have no knowledge of. Even if
it were thousands, that would mean an overhead of tens of thousands
of instructions. On a modern CPU, in a user-interaction scenario,
that doesn't even begin to be noticable to the user. If it's millions
of calls in a tight loop doing some heavy calculation then it will
have an impact; but anyone calling a virtual function in such a
scenario is doing it wrong.
Ok.
Show me a processor that has an "object" data type, that has
subtypes like "member" and "method" and such. There aren't any.
Translating from such incredibly high-level constructs to
registers, stacks, and memory locations is not without a lot of
overhead. Try to envision what happens in the instruction stream
during things like virtual function lookups in C++, for example.
Ok, I'm envisioning it. A few instructions to do a vtable lookup
and a jump to the correct virtual function. Wow. So those extra
instructions are what's making every machine in the world
(apparently) very very slow? In C#, virtual lookups are cached at runtime so
the cost of the
first virtual call to a function goes through the vtable routine;
future calls are very fast.
That's nice. Now if only C# weren't a proprietary product from one
company which happens to be obsessed with creating vendor lock-in
situations. ;)
(though actually, hmm, that IS rather nice...)
Objects in their raw form are not
"incredibly high-level." In C++,
an object is referenced via a pointer; data fields are accessed via
offsets just like in C. There is a small overhead for virtual
function dispatch. I fail to see how this overhead is somehow
responsible for performance problems in computers today.
There's a bit of congruity between C's structs and C++/C#/Java/etc
objects, but..
What other overheads/inefficiencies are you
thinking of?
...what happens when someone uses an Integer instead of an int? A
whole object gets created when all one likely needed was a memory
location. What happens when one adds that Integer to another
Integer? Add in
the address offset calculations to find out where the actual int is
stored within the Integer object, what would those be on most
architectures...two or three instructions? So our nice single-
instruction add turns into at least five instructions.
So you're arguing that increasing the number of instructions
required to execute a simple operation by a factor of five doesn't
involve overhead? Ok, howabout when it happens all the time, which
additions tend to in most programs?
See above.
In C (for example), there's no motivation at all to wrap a struct
around an int just for the sake of doing so, so it doesn't happen.
And howabout template programming. I've never seen executables so
big as the ones in which templates were overused.
Template programming is another paradigm altogether, it's basically C+
+ specific and it has very little to do with OO. (It's also an
abomination along with most of C++.)
(yes, here I have to give a nod to your point about
bad programmers
below!) All in the name of "saving programmer time", as if that's
such a big deal, consequences be damned.
Note well, however, that I'm talking about more than just the
number of instructions required to accomplish a given task. Sure,
that in itself has bad side effects when you think about what it
does to the instruction cache hit rates...the principal of locality
of reference is blown out the window. But what about memory
utilization? How big, in bytes, is an Integer compared to an int?
Ok, the difference may be only a few bytes, but what about the
program (which would be "most of them") with tens of thousands of
them? (I'm typing this on a Mac, into Mail.app, which is currently
eating 1.73GB of memory)
I beleive tha in Objective C, ints are still registers, no magical
Integer objects here. Sounds like Mail.app is poorly written. I'm
running Outlook here (written in a mix of c and c++) and it's using
100mb (with an inbox size of 10gb...).
You keep talking about how OO programming is the
reason that
software today is so inefficient but you offer no data to back it
up other than "it doesn't map to the hardware."
I'm sorry, but knowing how processors work, it's pretty obvious to
me. The data that backs it up is lots of programs (some of which
are operating systems) that I use every day, written in OO
languages, including (perhaps especially!) OS X, are far slower than
they should be given the hardware they're running on. YOU know how
processors work too, I know you do, so I know you see my point. A modern
multi-GHz Linux box running GTK is far less "responsive"-
feeling than my old SPARCstation-IPX running fvwm when just
tooling around the GUI. A little more time spent by the
programmers, ignoring the "easy way out" or heavy OO programming
and it'd be FAR faster.
So it finally comes out: it's the *bad progammers* at fault here.
I knew it all along! Don't confuse poor programmers with
programming languages. There are always efficiency tradeoffs in
programming languages and a good programmer knows how to make the
right choices.
-Dave
--
Dave McGuire
Port Charlotte, FL
1:58 p.m.
New subject: Algol vs Fortran was RE: VHDL vs Verilog
On Feb 9, 2010, at 3:49 PM, Josh Dersch wrote:
Yes, to a large degree! You're talking about it as if it happens
ONCE, and you know it doesn't. Would you care to estimate how
many of those vtable lookup happen when someone simply clicks a
mouse in a modern OS? I don't know for certain, but I'm willing
to bet that it's thousands.
I'm not going to speculate on things I have no knowledge of. Even
if it were thousands, that would mean an overhead of tens of
thousands of instructions. On a modern CPU, in a user-interaction
scenario, that doesn't even begin to be noticable to the user.
You're speaking from the standpoint of running one program, once,
alone on one computer. That's not how (most) computers are used.
How many processes are running, right now, on your Windows box? 146
right now on my Mac, *nearly seven hundred* on the central computer
here (a big Sun). Those "this code is only 20% slower"
inefficiencies that allowed us to get back on the golf course fifteen
minutes sooner do add up.
I'm going to go dig into a C++ implementation and look at the in-
memory composition of an integer object. I sure hope you're right.
C# has a form of templates, if memory serves. I believe they're
called "generics". Name one non-OO language that has such a
construct. I don't know of any.
Again I'm going to try to find the in-memory representation of
those integer objects. Regardless, however, this was just an
example...I'm sure you see my point. You're suggesting that OO
programming involves no runtime overhead over procedural/imperative
languages when run on processors whose architecture is arguably
procedural/imperative.
This is only a valid argument if you have an OS X written in plain
C and an OS X written in OO that you can do a real comparison
between. Anything else is speculation. OO does have its
overheads, I disagree that they are anywhere nearly as bad as you
claim them to be. Speculating that OS foo is far slower than it
"should be" based on anecdotal evidence is not proof.
It may be, at least in part, speculation...but with lots of
experience to back it up. Quite simply, almost everything I've seen
written in C++ and Java (even with native compilation) is slow, and
most everything I've seen written in C, assembler, and Forth is
fast. One such example in which the functionality is similar is
groff vs. nroff. Big speed difference between the two on similar
hardware performing similar functions.
Speculating that OS foo is far slower than it "should be" is
something that I think I can get a pretty good feel for, having used
dozens of operating systems on dozens of types of computers over
dozens of years. You're suggesting that my argument is completely
illegitimate because I'm not willing to spend the next two weeks
cooking up some sort of a benchmark suite to prove to you, by the
numbers, something that I've never heard anyone else disagree with,
ever?
Yes, absolutely. Most OO languages give bad programmers more code-
inflating features to misunderstand and abuse. If they don't know
how to write good code in C, which is a tiny, very fast, very low-
overhead, very simple language with very few features, how can they
be expected to write good code in C++, C# or Java, which are anything
but?
Handing an idiot a loaded rifle is dangerous. Handing an idiot a
loaded rifle with a loaded grenade launcher is MORE dangerous.
-Dave
--
Dave McGuire
Port Charlotte, FL
Ok. Show me
a processor that has an "object" data type, that
has subtypes like "member" and "method" and such. There aren't
any. Translating from such incredibly high-level constructs to
registers, stacks, and memory locations is not without a lot of
overhead. Try to envision what happens in the instruction
stream during things like virtual function lookups in C++, for
example.
Ok, I'm envisioning it. A few instructions to do a vtable lookup
and a jump to the correct virtual function. Wow. So those extra
instructions are what's making every machine in the world
(apparently) very very slow? If it's millions of calls in a tight loop doing
some heavy
calculation then it will have an impact; but anyone calling a
virtual function in such a scenario is doing it wrong.
...which happens ALL THE TIME. I've seen (and fixed) code like
that in every programming job I've ever had. Loop strength reduction
is something that nearly all optimizing compilers do, but the fact
that compilers have optimizers doesn't give us free license to write
sloppy code. There will always be situations in which the compiler
can't reduce the strength of a loop, and they will always get right
by you when you're writing that code if you don't pay attention.
...what
happens when someone uses an Integer instead of an int?
A whole object gets created when all one likely needed was a
memory location.
Depends greatly on the language. Don't confuse one implementation
with ALL OO programming languages. In C++ an integer maps to a
register. Same in C#. Same in objc. Java does this differently. And howabout
template programming. I've never seen executables
so big as the ones in which templates were overused.
Template programming is another paradigm altogether, it's basically
C++ specific and it has very little to do with OO. (It's also an
abomination along with most of C++.) Note well,
however, that I'm talking about more than just the
number of instructions required to accomplish a given task. Sure,
that in itself has bad side effects when you think about what it
does to the instruction cache hit rates...the principal of
locality of reference is blown out the window. But what about
memory utilization? How big, in bytes, is an Integer compared to
an int? Ok, the difference may be only a few bytes, but what
about the program (which would be "most of them") with tens of
thousands of them? (I'm typing this on a Mac, into Mail.app,
which is currently eating 1.73GB of memory)
I beleive tha in Objective C, ints are still registers, no magical
Integer objects here. Sounds like Mail.app is poorly written. I'm
running Outlook here (written in a mix of c and c++) and it's using
100mb (with an inbox size of 10gb...). You keep talking about how OO programming is the
reason that
software today is so inefficient but you offer no data to back it
up other than "it doesn't map to the hardware."
I'm sorry, but knowing how processors work, it's pretty obvious
to me. The data that backs it up is lots of programs (some of
which are operating systems) that I use every day, written in OO
languages, including (perhaps especially!) OS X, are far slower
than they should be given the hardware they're running on. YOU
know how processors work too, I know you do, so I know you see my
point. In an ideal
world, one in which all programmers were competent,
OO languages wouldn't be such a problem. So I guess what I really
mean is, "Bad programmers are even more detrimental to computing
when armed with OO languages".
You really think these same programmers would somehow write better
code if only they would stop using OO? 
2:18 p.m.
New subject: Algol vs Fortran was RE: VHDL vs Verilog
It was thus said that the Great Dave McGuire once stated:
It really depends upon the implementation of objects. I've done enough
"manual object oriented programming in C" to guess what C++ does under the
hood. For the "objects" that had fixed methods (not real sure of the
terminology here, as I don't program in C++) the overhead is just one
additional parameter (the object itself, or "this"). If the compiler can
figure out the method to call at compile time, there's very little overhead.
I counter that argument with PHP pre 5x. Not OO at all, and the code
quality, is ... um ... let's just say that osCommerce (a shopping cart
written in PHP) has been stuck at version 2.2 for several years because it's
too hideous to maintain ...
-spc (Might even suggest Perl, but then the counter to that is Forth ... )
On Feb 9, 2010, at 3:49 PM, Josh Dersch wrote:
Heh ... I've done templates in C. Portably too! Of course, it would win
the "Biggest Abuser of the C Preprocessor" Award, but I did it (back in
college---it seemed like a good idea at the time).
Template programming is another paradigm
altogether, it's basically
C++ specific and it has very little to do with OO. (It's also an
abomination along with most of C++.)
C# has a form of templates, if memory serves. I believe they're
called "generics". Name one non-OO language that has such a
construct. I don't know of any. I beleive tha
in Objective C, ints are still registers, no magical
Integer objects here. Sounds like Mail.app is poorly written. I'm
running Outlook here (written in a mix of c and c++) and it's using
100mb (with an inbox size of 10gb...).
Again I'm going to try to find the in-memory representation of
those integer objects. Regardless, however, this was just an
example...I'm sure you see my point. You're suggesting that OO
programming involves no runtime overhead over procedural/imperative
languages when run on processors whose architecture is arguably
procedural/imperative. You really
think these same programmers would somehow write better
code if only they would stop using OO?
Yes, absolutely. Most OO languages give bad programmers more code-
inflating features to misunderstand and abuse. If they don't know
how to write good code in C, which is a tiny, very fast, very low-
overhead, very simple language with very few features, how can they
be expected to write good code in C++, C# or Java, which are anything
but?
2:51 p.m.
New subject: Algol vs Fortran was RE: VHDL vs Verilog
I'm not so sure that the overhead for C++ objects is quite a bad as everyone's
making them out to be. Most of it boils down to simple pointer math and in other cases the
compiler itself can abstract away some of the offset calculations. If variables live on
the stack anyway, you'd have to do these offset calculations to get the data as well.
________________________________
From: Sean Conner <spc at conman.org>
To: General Discussion: On-Topic and Off-Topic Posts <cctalk at classiccmp.org>
Sent: Tue, February 9, 2010 4:18:31 PM
Subject: Re: Algol vs Fortran was RE: VHDL vs Verilog
It was thus said that the Great Dave McGuire once stated:
It really depends upon the implementation of objects. I've done enough
"manual object oriented programming in C" to guess what C++ does under the
hood. For the "objects" that had fixed methods (not real sure of the
terminology here, as I don't program in C++) the overhead is just one
additional parameter (the object itself, or "this"). If the compiler can
figure out the method to call at compile time, there's very little overhead.
I counter that argument with PHP pre 5x. Not OO at all, and the code
quality, is ... um ... let's just say that osCommerce (a shopping cart
written in PHP) has been stuck at version 2.2 for several years because it's
too hideous to maintain ...
-spc (Might even suggest Perl, but then the counter to that is Forth ... )
On Feb 9, 2010, at 3:49 PM, Josh Dersch wrote:
Heh ... I've done templates in C. Portably too! Of course, it would win
the "Biggest Abuser of the C Preprocessor" Award, but I did it (back in
college---it seemed like a good idea at the time).
Template programming is another paradigm
altogether, it's basically
C++ specific and it has very little to do with OO. (It's also an
abomination along with most of C++.)
C# has a form of templates, if memory serves. I believe they're
called "generics". Name one non-OO language that has such a
construct. I don't know of any. I beleive tha
in Objective C, ints are still registers, no magical
Integer objects here. Sounds like Mail.app is poorly written. I'm
running Outlook here (written in a mix of c and c++) and it's using
100mb (with an inbox size of 10gb...).
Again I'm going to try to find the in-memory representation of
those integer objects. Regardless, however, this was just an
example...I'm sure you see my point. You're suggesting that OO
programming involves no runtime overhead over procedural/imperative
languages when run on processors whose architecture is arguably
procedural/imperative. You really
think these same programmers would somehow write better
code if only they would stop using OO?
Yes, absolutely. Most OO languages give bad programmers more code-
inflating features to misunderstand and abuse. If they don't know
how to write good code in C, which is a tiny, very fast, very low-
overhead, very simple language with very few features, how can they
be expected to write good code in C++, C# or Java, which are anything
but? 
5 p.m.
New subject: Algol vs Fortran was RE: VHDL vs Verilog
geoffrey oltmans wrote:
I'm not so sure that the overhead for C++ objects
is quite a bad as everyone's making them out to be. Most of it boils down to simple
pointer math and in other cases the compiler itself can abstract away some of the offset
calculations. If variables live on the stack anyway, you'd have to do these offset
calculations to get the data as well.
I think the bigger point is that there are _many_ places in modern apps
where TONS of time is being wasted such that the overhead of vtables (or
more importantly, the lost functionality by doing away with them) is
relatively minor (depends in large part on the app of course). Heck, in
a modern OS, every time I type a character, like in this email, there
are about a bazillion things that happen (proper font/face chosen,
rendered, line formatting checked, spell checking, text identification
and highlighting (e.g. urls), etc, etc, etc) compared to a character
mode editor on a CLI. All that is obviously going to drain huge
cycles. Now you could certainly make that entire chain more efficient
by minimizing the effects of the vtable, but it's the features itself
that factor into the overall feeling that the modern OS is less
responsive (or at the least no more responsive) than those of days gone by.
I happen to work at a job where we _do_ count clock cycles and we'll
spend much time shaving microseconds from our code. We even study and
understand the effects of processor groupings in modern
multiprocessor/core computers. That said, we still code in C++ but we
understand when it's worthwhile to shave, when it's not worthwhile
getting that detailed and when it's worthwhile to change the algorithm
vs trying to shave a few nanoseconds by avoiding vtables or aligning
your memory accesses.
I grew up doing assembler and C. That said, the biggest issue with
software today (imho) isn't really speed (the folks at places like Intel
and nVidia will help us there) it's really stability and functionality.
The goal of a lot of the bloat is to attempt to help in those areas
(with varying levels of success of course).
5:18 p.m.
New subject: Algol vs Fortran was RE: VHDL vs Verilog
I agree with this. I think C++ is a powerful tool, but as the joke goes, "When you
shoot yourself in the foot with C, you blow a hole in your foot. When you shoot your foot
in C++, your foot is obliterated." I'm sure the presentation of the original is
funnier. ;)
On Feb 9, 2010, at 7:00 PM, George Currie wrote:
geoffrey oltmans wrote:
I'm not so sure that the overhead for C++
objects is quite a bad as everyone's making them out to be. Most of it boils down to
simple pointer math and in other cases the compiler itself can abstract away some of the
offset calculations. If variables live on the stack anyway, you'd have to do these
offset calculations to get the data as well.
I think the bigger point is that there are _many_ places in modern apps where TONS of
time is being wasted such that the overhead of vtables (or more importantly, the lost
functionality by doing away with them) is relatively minor (depends in large part on the
app of course). Heck, in a modern OS, every time I type a character, like in this email,
there are about a bazillion things that happen (proper font/face chosen, rendered, line
formatting checked, spell checking, text identification and highlighting (e.g. urls), etc,
etc, etc) compared to a character mode editor on a CLI. All that is obviously going to
drain huge cycles. Now you could certainly make that entire chain more efficient by
minimizing the effects of the vtable, but it's the features itself that factor into
the overall feeling that the modern OS is less responsive (or at the least no more
responsive) than those of days gone by.
I happen to work at a job where we _do_ count clock cycles and we'll spend much time
shaving microseconds from our code. We even study and understand the effects of processor
groupings in modern multiprocessor/core computers. That said, we still code in C++ but we
understand when it's worthwhile to shave, when it's not worthwhile getting that
detailed and when it's worthwhile to change the algorithm vs trying to shave a few
nanoseconds by avoiding vtables or aligning your memory accesses.
I grew up doing assembler and C. That said, the biggest issue with software today (imho)
isn't really speed (the folks at places like Intel and nVidia will help us there)
it's really stability and functionality. The goal of a lot of the bloat is to attempt
to help in those areas (with varying levels of success of course).
2:22 p.m.
New subject: Algol vs Fortran was RE: VHDL vs Verilog
On Feb 9, 2010, at 1:58 PM, Dave McGuire <mcguire at neurotica.com> wrote:
So again, the problem is the programmers, not the programming paradigm.
I'm going to go dig into a C++ implementation and look at the in-
memory composition of an integer object. I sure hope you're right.
C++ definitely has no concept of an integer object. (it offers no
built/in object types, not even a base Object class.)
C# has a form of templates, if memory serves. I believe they're
called "generics". Name one non-OO language that has such a
construct. I don't know of any.
C# generics and C++ template metaprogramming are nowhere near the same
thing. They both let you easily define reusable container objects
(and for that use, they are efficient.). C++ templates actually
provide a Turing-complete language (an ugly one) that runs at compile
time. You can do clever things with it, you can also do horrible
things with it.
C++ metaprogramming is very much a paradigm unto itself.
Again I'm going to try to find the in-memory representation of
those integer objects. Regardless, however, this was just an
example...I'm sure you see my point. You're suggesting that OO
programming involves no runtime overhead over procedural/imperative
languages when run on processors whose architecture is arguably
procedural/imperative.
Never said that. My argument has and will continue to be that the
performance impact is not nearly as bad as you are implying.
This is only a valid argument if you have an OS X written in plain
C and an OS X written in OO that you can do a real comparison
between. Anything else is speculation. OO does have its
overheads, I disagree that they are anywhere nearly as bad as you
claim them to be. Speculating that OS foo is far slower than it
"should be" based on anecdotal evidence is not proof.
It may be, at least in part, speculation...but with lots of
experience to back it up. Quite simply, almost everything I've seen
written in C++ and Java (even with native compilation) is slow, and
most everything I've seen written in C, assembler, and Forth is fast.
I could argue that I've also seen the exact opposite, but I'm not
sure what that would prove.
Yes, absolutely. Most OO languages give bad programmers more code-
inflating features to misunderstand and abuse. If they don't know
how to write good code in C, which is a tiny, very fast, very low-
overhead, very simple language with very few features, how can they
be expected to write good code in C++, C# or Java, which are
anything but?
I suppose we'll have to agree to disagree here.
On Feb 9, 2010, at 3:49 PM, Josh
Yes, to a large degree! You're talking
about it as if it happens
ONCE, and you know it doesn't. Would you care to estimate how
many of those vtable lookup happen when someone simply clicks a
mouse in a modern OS? I don't know for certain, but I'm willing
to bet that it's thousands.
I'm not going to speculate on things I have no knowledge of. Even
if it were thousands, that would mean an overhead of tens of
thousands of instructions. On a modern CPU, in a user-interaction
scenario, that doesn't even begin to be noticable to the user.
You're speaking from the standpoint of running one program, once,
alone on one computer. That's not how (most) computers are used.
How many processes are running, right now, on your Windows box? 146
right now on my Mac, *nearly seven hundred* on the central computer
here (a big Sun). Those "this code is only 20% slower"
inefficiencies that allowed us to get back on the golf course
fifteen minutes sooner do add up.
So you're clicking every button in every process running on your
machine constantly? My point is that for *many* operations (like user-
interactions which typically are gated on the response time of humans)
virtual call overhead is acceptable.
If it's millions of calls in a tight loop
doing some heavy
calculation then it will have an impact; but anyone calling a
virtual function in such a scenario is doing it wrong.
...which happens ALL THE TIME. I've seen (and fixed) code like
that in every programming job I've ever had. Loop strength
reduction is something that nearly all optimizing compilers do, but
the fact that compilers have optimizers doesn't give us free license
to write sloppy code. There will always be situations in which the
compiler can't reduce the strength of a loop, and they will always
get right by you when you're writing that code if you don't pay
attention. ...what
happens when someone uses an Integer instead of an int? A
whole object gets created when all one likely needed was a memory
location.
Depends greatly on the language. Don't confuse one implementation
with ALL OO programming languages. In C++ an integer maps to a
register. Same in C#. Same in objc. Java does this differently. And
howabout template programming. I've never seen executables so
big as the ones in which templates were overused.
Template programming is another paradigm altogether, it's basically
C++ specific and it has very little to do with OO. (It's also an
abomination along with most of C++.) Note
well, however, that I'm talking about more than just the
number of instructions required to accomplish a given task. Sure,
that in itself ehas bad side effects when you think about what it
does to the instruction cache hit rates...the principal of
locality of reference is blown out the window. But what about
memory utilization? How big, in bytes, is an Integer compared to
an int? Ok, the difference may be only a few bytes, but what
about the program (which would be "most of them") with tens of
thousands of them? (I'm typing this on a Mac, into Mail.app,
which is currently eating 1.73GB of memory)
I beleive tha in Objective C, ints are still registers, no magical
Integer objects here. Sounds like Mail.app is poorly written. I'm
running Outlook here (written in a mix of c and c++) and it's using
100mb (with an inbox size of 10gb...). You keep talking about howi OO programming is the
reason that
software today is so inefficient but you offer no data to back it
up other than "it doesn't map to the hardware."
I'm sorry, but knowing how processors work, it's pretty obvious to
me. The data that backs it up is lots of programs (some of which
are operating systems) that I use every day, written in OO
languages, including (perhaps especially!) OS X, are far slower
than they should be given the hardware they're running on. YOU
know how processors work too, I know you do, so I know you see my
point. One such example in which the functionality is similar
is groff vs.
nroff. Big speed difference between the two on similar hardware
performing similar functions.
Speculating that OS foo is far slower than it "should be" is
something that I think I can get a pretty good feel for, having used
dozens of operating systems on dozens of types of computers over
dozens of years. You're suggesting that my argument is completely
illegitimate because I'm not willing to spend the next two weeks
cooking up some sort of a benchmark suite to prove to you, by the
numbers, something that I've never heard anyone else disagree with,
ever?
I'm suggesting that you are exaggerating the performance impact and
that you keep basing these projections on feelings.
In an
ideal world, one in which all programmers were competent, OO
languages wouldn't be such a problem. So I guess what I really
mean is, "Bad programmers are even more detrimental to computing
when armed with OO languages".
You really think these same programmers would somehow write better
code if only they would stop using OO?
Handing an idiot a loaded rifle is dangerous. Handing an idiot a
loaded rifle with a loaded grenade launcher is MORE dangerous
Yes. Programming languages are just like firearms.
If you want to discuss this further, feel free to contact me
offlist, I'm already feeling guilty for dragging this thread wayyyy
off topic.
Josh
-Dave
--
Dave McGuire
Port Charlotte, FL
2:46 p.m.
New subject: Algol vs Fortran was RE: VHDL vs Verilog
On Feb 9, 2010, at 5:22 PM, Josh Dersch wrote:
Of course not. But don't assume I'm the only person using this
machine. It's sitting there receiving and doing spam filtering on
about 90K emails per day, serving web pages for a small stack of web
sites, being a database server with about 20GB of data behind
it...The machine isn't sitting there idle waiting for me to click on
something. That machine doesn't even have a graphical console.
There's more to what computers do than run whatever app one
particular user is clicking at at any given time.
C++ definitely has no concept of an integer object. (it offers no
built/in object types, not even a base Object class.)
Again, it was an example, taken from Java, because I know Java
much better than I know C++.
Everything I've read about generics describes them as a form of
templates. Everything. You're asserting that they're completely
different? If so, I will stand corrected, and chalk it up to a lot
of bad info on peoples' web sites. I myself don't have a Windows
computer so I don't use C#, so I can't speak from direct experience
there.
You have? Seriously?
Feelings? No, experience. Big difference. Experience with and
knowledge of the past. There is NO RATIONAL REASON why a GUI-based
OS should need more than a billion bytes of memory and a billion-plus
clock cycles per second just to boot. You and I (and many others on
this list) have plenty of examples of machines that do the same thing
with a tiny fraction of those resources.
Windows, OS X, and Linux (but only with Gnome or KDE) are fat,
bloated, slow, lumbering pigs, and it's due to sloppy programming and
misapplication of tools. That is my assertion. My proof is that I
use my dual 1.8GHz PPC with 4GB of RAM for the EXACT SAME STUFF every
day that I used my 40MHz SPARC with 32MB of RAM to do every day, and
I bump up against the performance limitations of both to essentially
the same degree.
Playing music, playing video files, telnetting, sshing, editing,
compiling, browsing the web, etc etc etc. The apps are a bit
prettier now, certainly moreso than with fvwm, but I'd happily live
without that.
Yes, absolutely. Most OO languages give bad programmers more
code-inflating features to misunderstand and abuse. If they don't
know how to write good code in C, which is a tiny, very fast, very
low-overhead, very simple language with very few features, how can
they be expected to write good code in C++, C# or Java, which are
anything but?
I suppose we'll have to agree to disagree here.
I'm fine with that.
Wow. So I'm not allowed to use analogies here?
-Dave
--
Dave McGuire
Port Charlotte, FL
You're
speaking from the standpoint of running one program, once,
alone on one computer. That's not how (most) computers are used.
How many processes are running, right now, on your Windows box?
146 right now on my Mac, *nearly seven hundred* on the central
computer here (a big Sun). Those "this code is only 20% slower"
inefficiencies that allowed us to get back on the golf course
fifteen minutes sooner do add up.
So you're clicking every button in every process running on your
machine constantly? My point is that for *many* operations (like
user-interactions
which typically are gated on the response time of humans) virtual
call overhead is acceptable.
If that's the only thing, or one of a very small number of things,
running on the (very very fast) machine, sure.
Depends greatly on the language. Don't confuse
one
implementation with ALL OO programming languages. In C++ an
integer maps to a register. Same in C#. Same in objc. Java
does this differently.
I'm going to go dig into a C++ implementation and look at the in-
memory composition of an integer object. I sure hope you're right. C# has a form
of templates, if memory serves. I believe they're
called "generics". Name one non-OO language that has such a
construct. I don't know of any.
C# generics and C++ template metaprogramming are nowhere near the
same thing. They both let you easily define reusable container
objects (and for that use, they are efficient.). C++ templates
actually provide a Turing-complete language (an ugly one) that runs
at compile time. You can do clever things with it, you can also do
horrible things with it.
C++ metaprogramming is very much a paradigm unto itself. It may be, at
least in part, speculation...but with lots of
experience to back it up. Quite simply, almost everything I've
seen written in C++ and Java (even with native compilation) is
slow, and most everything I've seen written in C, assembler, and
Forth is fast.
I could argue that I've also seen the exact opposite, but I'm not
sure what that would prove. One such
example in which the functionality is similar is groff
vs. nroff. Big speed difference between the two on similar
hardware performing similar functions.
Speculating that OS foo is far slower than it "should be" is
something that I think I can get a pretty good feel for, having
used dozens of operating systems on dozens of types of computers
over dozens of years. You're suggesting that my argument is
completely illegitimate because I'm not willing to spend the next
two weeks cooking up some sort of a benchmark suite to prove to
you, by the numbers, something that I've never heard anyone else
disagree with, ever?
I'm suggesting that you are exaggerating the performance impact and
that you keep basing these projections on feelings. In an ideal
world, one in which all programmers were competent,
OO languages wouldn't be such a problem. So I guess what I
really mean is, "Bad programmers are even more detrimental to
computing when armed with OO languages".
You really think these same programmers would somehow write
better code if only they would stop using OO? Handing an
idiot a loaded rifle is dangerous. Handing an idiot a
loaded rifle with a loaded grenade launcher is MORE dangerous
Yes. Programming languages are just like firearms.
3 p.m.
New subject: Algol vs Fortran was RE: VHDL vs Verilog
The same things? Doubtful. How fancy a GUI does your SPARCstation run compared to your
more modern PPC?
________________________________
From: Dave McGuire <mcguire at neurotica.com>
To: General Discussion: On-Topic and Off-Topic Posts <cctalk at classiccmp.org>
Sent: Tue, February 9, 2010 4:46:33 PM
Subject: Re: Algol vs Fortran was RE: VHDL vs Verilog
Feelings? No, experience. Big difference. Experience with and knowledge of the past.
There is NO RATIONAL REASON why a GUI-based OS should need more than a billion bytes of
memory and a billion-plus clock cycles per second just to boot. You and I (and many
others on this list) have plenty of examples of machines that do the same thing with a
tiny fraction of those resources.
Windows, OS X, and Linux (but only with Gnome or KDE) are fat, bloated, slow, lumbering
pigs, and it's due to sloppy programming and misapplication of tools. That is my
assertion. My proof is that I use my dual 1.8GHz PPC with 4GB of RAM for the EXACT SAME
STUFF every day that I used my 40MHz SPARC with 32MB of RAM to do every day, and I bump up
against the performance limitations of both to essentially the same degree.
3:06 p.m.
New subject: Algol vs Fortran was RE: VHDL vs Verilog
Yes, the same things. Here, quoted from the message that you
trimmed:
"Playing music, playing video files, telnetting, sshing, editing,
compiling, browsing the web, etc etc etc."
I'll add "viewing PDF files and generating documentation" since
they came to mind since I sent that. About the only thing I do on my
system now that I didn't back then was run CPU emulators and edit
pictures.
Yes, the GUI is prettier, and it supports drag-and-drop (which I
almost never use), but other than that, there's not much difference.
The OS *supports* the apps. I spend most of my time in the apps.
-Dave
On Feb 9, 2010, at 6:00 PM, geoffrey oltmans wrote:
The same things? Doubtful. How fancy a GUI does your
SPARCstation
run compared to your more modern PPC?
________________________________
From: Dave McGuire <mcguire at neurotica.com>
To: General Discussion: On-Topic and Off-Topic Posts
<cctalk at classiccmp.org>
Sent: Tue, February 9, 2010 4:46:33 PM
Subject: Re: Algol vs Fortran was RE: VHDL vs Verilog
Feelings? No, experience. Big difference. Experience with and
knowledge of the past. There is NO RATIONAL REASON why a GUI-based
OS should need more than a billion bytes of memory and a billion-
plus clock cycles per second just to boot. You and I (and many
others on this list) have plenty of examples of machines that do
the same thing with a tiny fraction of those resources.
Windows, OS X, and Linux (but only with Gnome or KDE) are fat,
bloated, slow, lumbering pigs, and it's due to sloppy programming
and misapplication of tools. That is my assertion. My proof is
that I use my dual 1.8GHz PPC with 4GB of RAM for the EXACT SAME
STUFF every day that I used my 40MHz SPARC with 32MB of RAM to do
every day, and I bump up against the performance limitations of
both to essentially the same degree.
--
Dave McGuire
Port Charlotte, FL
3:10 p.m.
New subject: Algol vs Fortran was RE: VHDL vs Verilog
You don't have any problems viewing HD movies on your 40MHz SPARC? How about encoding
video, how long does that take?
________________________________
From: Dave McGuire <mcguire at neurotica.com>
To: General Discussion: On-Topic and Off-Topic Posts <cctalk at classiccmp.org>
Sent: Tue, February 9, 2010 5:06:30 PM
Subject: Re: Algol vs Fortran was RE: VHDL vs Verilog
Yes, the same things. Here, quoted from the message that you trimmed:
"Playing music, playing video files, telnetting, sshing, editing, compiling,
browsing the web, etc etc etc."
I'll add "viewing PDF files and generating documentation" since they came
to mind since I sent that. About the only thing I do on my system now that I didn't
back then was run CPU emulators and edit pictures.
Yes, the GUI is prettier, and it supports drag-and-drop (which I almost never use), but
other than that, there's not much difference. The OS *supports* the apps. I spend
most of my time in the apps.
-Dave
On Feb 9, 2010, at 6:00 PM, geoffrey oltmans wrote:
The same things? Doubtful. How fancy a GUI does your
SPARCstation run compared to your more modern PPC?
________________________________
From: Dave McGuire <mcguire at neurotica.com>
To: General Discussion: On-Topic and Off-Topic Posts <cctalk at classiccmp.org>
Sent: Tue, February 9, 2010 4:46:33 PM
Subject: Re: Algol vs Fortran was RE: VHDL vs Verilog
Feelings? No, experience. Big difference. Experience with and knowledge of the past.
There is NO RATIONAL REASON why a GUI-based OS should need more than a billion bytes of
memory and a billion-plus clock cycles per second just to boot. You and I (and many
others on this list) have plenty of examples of machines that do the same thing with a
tiny fraction of those resources.
Windows, OS X, and Linux (but only with Gnome or KDE) are fat, bloated, slow, lumbering
pigs, and it's due to sloppy programming and misapplication of tools. That is my
assertion. My proof is that I use my dual 1.8GHz PPC with 4GB of RAM for the EXACT SAME
STUFF every day that I used my 40MHz SPARC with 32MB of RAM to do every day, and I bump up
against the performance limitations of both to essentially the same degree.
--Dave McGuire
Port Charlotte, FL
3:14 p.m.
New subject: Algol vs Fortran was RE: VHDL vs Verilog
Of course there are things that my old SPARCstation wouldn't be
able to do, and those are two good examples. They also happen to be
things that weren't on my list, and things that I've NEVER done, on
any computer, and don't see any desire to. I view HD movies on my A/
V system in my living room, and I've never had a need to encode my
own video.
Please read my list.
-Dave
On Feb 9, 2010, at 6:10 PM, geoffrey oltmans wrote:
You don't have any problems viewing HD movies on
your 40MHz SPARC?
How about encoding video, how long does that take?
________________________________
From: Dave McGuire <mcguire at neurotica.com>
To: General Discussion: On-Topic and Off-Topic Posts
<cctalk at classiccmp.org>
Sent: Tue, February 9, 2010 5:06:30 PM
Subject: Re: Algol vs Fortran was RE: VHDL vs Verilog
Yes, the same things. Here, quoted from the message that you
trimmed:
"Playing music, playing video files, telnetting, sshing, editing,
compiling, browsing the web, etc etc etc."
I'll add "viewing PDF files and generating documentation" since
they came to mind since I sent that. About the only thing I do on
my system now that I didn't back then was run CPU emulators and
edit pictures.
Yes, the GUI is prettier, and it supports drag-and-drop (which I
almost never use), but other than that, there's not much
difference. The OS *supports* the apps. I spend most of my time
in the apps.
-Dave
On Feb 9, 2010, at 6:00 PM, geoffrey oltmans wrote:
--
Dave McGuire
Port Charlotte, FL
The same things? Doubtful. How fancy a GUI does
your SPARCstation
run compared to your more modern PPC?
________________________________
From: Dave McGuire <mcguire at neurotica.com>
To: General Discussion: On-Topic and Off-Topic Posts
<cctalk at classiccmp.org>
Sent: Tue, February 9, 2010 4:46:33 PM
Subject: Re: Algol vs Fortran was RE: VHDL vs Verilog
Feelings? No, experience. Big difference. Experience with and
knowledge of the past. There is NO RATIONAL REASON why a GUI-
based OS should need more than a billion bytes of memory and a
billion-plus clock cycles per second just to boot. You and I (and
many others on this list) have plenty of examples of machines that
do the same thing with a tiny fraction of those resources.
Windows, OS X, and Linux (but only with Gnome or KDE) are fat,
bloated, slow, lumbering pigs, and it's due to sloppy programming
and misapplication of tools. That is my assertion. My proof is
that I use my dual 1.8GHz PPC with 4GB of RAM for the EXACT SAME
STUFF every day that I used my 40MHz SPARC with 32MB of RAM to do
every day, and I bump up against the performance limitations of
both to essentially the same degree.
--Dave McGuire
Port Charlotte, FL
4:56 p.m.
New subject: Algol vs Fortran was RE: VHDL vs Verilog
You seemed to be arguing that there was absolutely no benefit to the added complexity
(bloat you said) of modern systems. Just because there's some application that you
don't want doesn't mean that it's necessarily wasteful though.
On Feb 9, 2010, at 5:14 PM, Dave McGuire wrote:
Of course there are things that my old SPARCstation wouldn't be able to do, and
those are two good examples. They also happen to be things that weren't on my list,
and things that I've NEVER done, on any computer, and don't see any desire to. I
view HD movies on my A/V system in my living room, and I've never had a need to encode
my own video.
Please read my list.
-Dave
On Feb 9, 2010, at 6:10 PM, geoffrey oltmans wrote:
You don't have any problems viewing HD movies
on your 40MHz SPARC? How about encoding video, how long does that take?
________________________________
From: Dave McGuire <mcguire at neurotica.com>
To: General Discussion: On-Topic and Off-Topic Posts <cctalk at classiccmp.org>
Sent: Tue, February 9, 2010 5:06:30 PM
Subject: Re: Algol vs Fortran was RE: VHDL vs Verilog
Yes, the same things. Here, quoted from the message that you trimmed:
"Playing music, playing video files, telnetting, sshing, editing, compiling,
browsing the web, etc etc etc."
I'll add "viewing PDF files and generating documentation" since they came
to mind since I sent that. About the only thing I do on my system now that I didn't
back then was run CPU emulators and edit pictures.
Yes, the GUI is prettier, and it supports drag-and-drop (which I almost never use), but
other than that, there's not much difference. The OS *supports* the apps. I spend
most of my time in the apps.
-Dave
On Feb 9, 2010, at 6:00 PM, geoffrey oltmans wrote:
--
Dave McGuire
Port Charlotte, FL
The same things? Doubtful. How fancy a GUI does
your SPARCstation run compared to your more modern PPC?
________________________________
From: Dave McGuire <mcguire at neurotica.com>
To: General Discussion: On-Topic and Off-Topic Posts <cctalk at classiccmp.org>
Sent: Tue, February 9, 2010 4:46:33 PM
Subject: Re: Algol vs Fortran was RE: VHDL vs Verilog
Feelings? No, experience. Big difference. Experience with and knowledge of the past.
There is NO RATIONAL REASON why a GUI-based OS should need more than a billion bytes of
memory and a billion-plus clock cycles per second just to boot. You and I (and many
others on this list) have plenty of examples of machines that do the same thing with a
tiny fraction of those resources.
Windows, OS X, and Linux (but only with Gnome or KDE) are fat, bloated, slow, lumbering
pigs, and it's due to sloppy programming and misapplication of tools. That is my
assertion. My proof is that I use my dual 1.8GHz PPC with 4GB of RAM for the EXACT SAME
STUFF every day that I used my 40MHz SPARC with 32MB of RAM to do every day, and I bump up
against the performance limitations of both to essentially the same degree.
--Dave McGuire
Port Charlotte, FL
5:19 p.m.
New subject: Algol vs Fortran was RE: VHDL vs Verilog
Geoff Oltmans wrote:
You seemed to be arguing that there was absolutely no
benefit to the added complexity (bloat you said)
of modern systems. Just because there's some application that you
don't
want doesn't mean that it's
necessarily wasteful though.
Sorry, but because some kids like to watch movies, everybody else has to
have a slow system ?
Some of us, actually have to work on them.
My solution to this is simple. I use the console screen as long as
possible (linux/bsd/etc.) Then, when I really need to draw schematics or
something which really needs a gui, I start it.
5:39 p.m.
New subject: Algol vs Fortran was RE: VHDL vs Verilog
On Feb 9, 2010, at 7:56 PM, Geoff Oltmans wrote:
--
Dave McGuire
Port Charlotte, FL
You seemed to be arguing that there was absolutely no
benefit to
the added complexity (bloat you said) of modern systems. Just
because there's some application that you don't want doesn't mean
that it's necessarily wasteful though.
And you seem to be arguing that this system wouldn't be able to
encode video or watch HD movies without that complexity. ;) I disagree.
I don't mind *spending* cycles. That's what they're for. I just
don't like wasting them.
-Dave
3:12 p.m.
New subject: Algol vs Fortran was RE: VHDL vs Verilog
On Feb 9, 2010, at 2:46 PM, Dave McGuire <mcguire at neurotica.com> wrote:
You have? Seriously?
Yep. Again, it's a case of bad programmers doing stupid things.
Feelings? No, experience. Big difference. Experience with and
knowledge of the past. There is NO RATIONAL REASON why a GUI-based
OS should need more than a billion bytes of memory and a billion-
plus clock cycles per second just to boot. You and I (and many
others on this list) have plenty of examples of machines that do the
same thing with a tiny fraction of those resources.
Windows, OS X, and Linux (but only with Gnome or KDE) are fat,
bloated, slow, lumbering pigs, and it's due to sloppy programming
and misapplication of tools. That is my assertion. My proof is
that I use my dual 1.8GHz PPC with 4GB of RAM for the EXACT SAME
STUFF every day that I used my 40MHz SPARC with 32MB of RAM to do
every day, and I bump up against the performance limitations of both
to essentially the same degree.
Playing music, playing video files, telnetting, sshing, editing,
compiling, browsing the web, etc etc etc. The apps are a bit
prettier now, certainly moreso than with fvwm, but I'd happily live
without that.
See, here's where I see a disconnect; you are doing the same *class*
of thing, but you're not really doing the same thing. Programs have
gotten more complex because people want more from their software.
Regardless of whether Firefox 3.5 was written in assembly or C++ you'd
never hope to run it on your IPX. I just think you are blaming the
wrong thing (or just blaming one thing) for the performance
degradations you are perceiving. OO overhead adds some not
imperceivable overhead; so do each of extensibility, abstraction,
support for "modern standards" (CSS, JavaScript, XML) ui theming,
support for "advanced" desktop metaphors, etc... Code reuse and
abstractions also bring overhead; these exist even in C, but the
overhead is worth it in terms of maintenance and usability (from a
programming and a user perspective.)
And honestly, my current desktop machine runs circles around the
machine I was using in college, doing more or less the same things
you do; I rarely hit performance issues. The same was true of my
previous desktop, which I got six years of use from.
I suppose we'll have to agree to disagree here.
I'm fine with that.
Wow. So I'm not allowed to use analogies here?
Sorry, typing this from my phone and forgot to finish that sentence :).
And I said I wasn't going to continue dragging this offtopic...
Josh
On Feb 9, 2010, at 5:22 PM, Josh Dersch wrote:
Of course not. But don't assume I'm the only person using this
machine. It's sitting there receiving and doing spam filtering on
about 90K emails per day, serving web pages for a small stack of web
sites, being a database server with about 20GB of data behind
it...The machine isn't sitting there idle waiting for me to click on
something. That machine doesn't even have a graphical console.
There's more to what computers do than run whatever app one
particular user is clicking at at any given time.
C++ definitely has no concept of an integer object. (it offers no
built/in object types, not even a base Object class.)
Again, it was an example, taken from Java, because I know Java much
better than I know C++.
Everything I've read about generics describes them as a form of
templates. Everything. You're asserting that they're completely
different? If so, I will stand corrected, and chalk it up to a lot
of bad info on peoples' web sites. I myself don't have a Windows
computer so I don't use C#, so I can't speak from direct experience
there.
You can indeed use C#, via the Mono project. Generics are a very
basic form of C++ templates that are good for creating generic
containers, and that's about it. C++ templates are considerably more
involved, and metaprogramming tricks are used to do all manner of
insane things at compile time. At a very basic level, the two are the
same. It's like saying a Yugo and a Maserati are equivalent because
they are both cars. (yes, you can use analogies here :)
You're speaking from the standpoint of running one program, once,
alone on one computer. That's not how (most) computers are used.
How many processes are running, right now, on your Windows box?
146 right now on my Mac, *nearly seven hundred* on the central
computer here (a big Sun). Those "this code is only 20% slower"
inefficiencies that allowed us to get back on the golf course
fifteen minutes sooner do add up.
So you're clicking every button in every process running on your
machine constantly? My point is that for *many* operations (like
user-interactions
which typically are gated on the response time of humans) virtual
call overhead is acceptable.
If that's the only thing, or one of a very small number of things,
running on the (very very fast) machine, sure.
Depends greatly on the language. Don't confuse
one
implementation with ALL OO programming languages. In C++ an
integer maps to a register. Same in C#. Same in objc. Java
does this differently.
I'm going to go dig into a C++ implementation and look at the in-
memory composition of an integer object. I sure hope you're right. C# has a
form of templates, if memory serves. I believe they're
called "generics". Name one non-OO language that has such a
construct. I don't know of any.
C# generics and C++ template metaprogramming are nowhere near the
same thing. They both let you easily define reusable container
objects (and for that use, they are efficient.). C++ templates
actually provide a Turing-complete language (an ugly one) that runs
at compile time. You can do clever things with it, you can also do
horrible things with it.
C++ metaprogramming is very much a paradigm unto itself. It may
be, at least in part, speculation...but with lots of
experience to back it up. Quite simply, almost everything I've
seen written in C++ and Java (even with native compilation) is
slow, and most everything I've seen written in C, assembler, and
Forth is fast.
I could argue that I've also seen the exact opposite, but I'm not
sure what that would prove. One such
example in which the functionality is similar is groff
vs. nroff. Big speed difference between the two on similar
hardware performing similar functions.
Speculating that OS foo is far slower than it "should be" is
something that I think I can get a pretty good feel for, having
used dozens of operating systems on dozens of types of computers
over dozens of years. You're suggesting that my argument is
completely illegitimate because I'm not willing to spend the next
two weeks cooking up some sort of a benchmark suite to prove to
you, by the numbers, something that I've never heard anyone else
disagree with, ever?
I'm suggesting that you are exaggerating the performance impact and
that you keep basing these projections on feelings. > In an ideal world, one in newhich all programmers
were
> competent, OO languages wouldn't be such a problem. So I guess
> what I really mean is, "Bad programmers are even more
> detrimental to computing when armed with OO languages".
You really think these same programmers would somehow write
better code if only they would stop using OO?
Yes, absolutely. Most OO languages give bad programmers more code-
inflating features to misunderstand and abuse. If they don't know
how to write good code in C, which is a tiny, very fast, very low-
overhead, very simple language with very few features, how can
they be expected to write good code in C++, C# or Java, which are
anything but? Handing
an idiot a loaded rifle is dangerous. Handing an idiot a
loaded rifle with a loaded grenade launcher is MORE dangerous
Yes. Programming languages are just like firearms. -Dave
--
Dave McGuire
Port Charlotte, FL
10 Feb
10 Feb
3:26 p.m.
New subject: Algol vs Fortran was RE: VHDL vs Verilog
On Feb 9, 2010, at 6:12 PM, Josh Dersch wrote:
You have? Seriously?
Yep. Again, it's a case of bad programmers doing stupid things.
Well ok, but is that the rule or the exception? ;)
Sure, I see where you're coming from, and I agree. But I'm
actually doing the same thing. With the exception of Firefox and
Mail.app, the stuff I run is all pretty lightweight. I wish Mail.app
were a bit lighter, in particular, because I, even being a VERY heavy
email user, barely scratch the surface of [most of] its [pointless]
features.
You can indeed use C#, via the Mono project. Generics
are a very
basic form of C++ templates that are good for creating generic
containers, and that's about it. C++ templates are considerably
more involved, and metaprogramming tricks are used to do all manner
of insane things at compile time. At a very basic level, the two
are the same. It's like saying a Yugo and a Maserati are
equivalent because they are both cars. (yes, you can use analogies
here :)
Ok, I understand that a bit better now. I will go read up on
generics a bit. Thanks for the clarification.
It may be, at
least in part, speculation...but with lots of
experience to back it up. Quite simply, almost everything I've
seen written in C++ and Java (even with native compilation) is
slow, and most everything I've seen written in C, assembler, and
Forth is fast.
I could argue that I've also seen the exact opposite, but I'm
not sure what that would prove. Playing
music, playing video files, telnetting, sshing, editing,
compiling, browsing the web, etc etc etc. The apps are a bit
prettier now, certainly moreso than with fvwm, but I'd happily
live without that.
See, here's where I see a disconnect; you are doing the same
*class* of thing, but you're not really doing the same thing.
Programs have gotten more complex because people want more from
their software. Regardless of whether Firefox 3.5 was written in
assembly or C++
you'd never hope to run it on your IPX. I just think you are
blaming the wrong thing (or just blaming one thing) for the
performance degradations you are perceiving. OO overhead adds some
not imperceivable overhead; so do each of extensibility,
abstraction, support for "modern standards" (CSS, JavaScript, XML)
ui theming, support for "advanced" desktop metaphors, etc... Code
reuse and abstractions also bring overhead; these exist even in C,
but the overhead is worth it in terms of maintenance and usability
(from a programming and a user perspective.)
I do see where you're coming from. Perhaps I give OO too much
blame, but I stand by my accusations...it does deserve a lot of it,
in my opinion. It wasn't until very recent releases of common C
compilers, for example, that a simple "hello world" program in C++
generated a 600KB (yes, six hundred kilobyte) binary. I've
demonstrated that (along with its 4KB C equivalent) many times. I
was, admittedly, pleased to see that this particular brand of idiocy
has been addressed. I have no idea what was in that damn binary.
-Dave
--
Dave McGuire
Port Charlotte, FL
3:40 p.m.
New subject: Algol vs Fortran was RE: VHDL vs Verilog
On Wed, 10 Feb 2010, Dave McGuire wrote:
I do see where you're coming from. Perhaps I
give OO too much
blame, but I stand by my accusations...it does deserve a lot of it,
in my opinion. It wasn't until very recent releases of common C
compilers, for example, that a simple "hello world" program in C++
generated a 600KB (yes, six hundred kilobyte) binary. I've
demonstrated that (along with its 4KB C equivalent) many times. I
was, admittedly, pleased to see that this particular brand of idiocy
has been addressed. I have no idea what was in that damn binary.
But, don't you WANT to have a "division by zero" exception handler built
into your "Hello world" program?
When I taught C, I made the students use multiple compilers, including
command line (DeSmet/PCC, GCC) and IDE (TurboC, Microsoft C++), and
compare the results.
The other teacher, teaching another section, used Microsoft C++, and spent
the entire semester on how to use the compiler, and never really got
around to any C.
At the end of the semester, my students could write simple C programs, and
could figure out how to use other compilers. His students could use
the Microsoft compiler (without understanding what they were doing), but
couldn't create any programs on their own! (He gave all A's!)
--
Grumpy Ol' Fred cisin at xenosoft.com
9:21 p.m.
New subject: Algol vs Fortran was RE: VHDL vs Verilog
Dave McGuire wrote:
Well ok, but is that the rule or the exception? ;)
Hard to say. I'd estimate that most of the C++ code I've had to deal
with has had performance on par with what I'd expect from a C
implementation (it's just 20% uglier to look at) but I've also had to
deal with a good amount of ugly C and ugly C++ written by people who
were unclear on the concept of using the right algorithm for the problem.
And as an aside, the C/C++ code I've had to deal with has been, in my
experience, far more bug-prone and unstable than the C# code I've dealt
with :).
Sure, I see where you're coming from, and I agree. But I'm actually
doing the same thing. With the exception of Firefox and Mail.app, the
stuff I run is all pretty lightweight. I wish Mail.app were a bit
lighter, in particular, because I, even being a VERY heavy email user,
barely scratch the surface of [most of] its [pointless] features.
Well, there's a plethora of e-mail clients out there; I use Thunderbird
at home and while it's not the most elegant thing it does a decent job
for my needs. I've never used Mail.app (except perhaps in its earlier
incarnation as a NeXTstep app :)) so I can't speak to whether it does
magic things that are worth the memory overhead you're seeing.
I think that C++ did wonders to malign the image of OO. C++ is just
barely OO anyway -- it barely has compile-time encapsulation and has no
real run-time encapsulation, memory management is still almost entirely
manual (which people may argue is a good thing, but in the face of C++
exceptions and other C++ features, it's a HUGE issue since it makes
memory management all that more difficult to do correctly), and
compilers have taken a long time to catch up to the point where they
generate decent code.
I think most early (and some more recent) C++ compilers & linkers did a
really terrible job with unused code removal; i.e. if you did a
"#include<iostream>" to do 'cout << "Hello,
World!";' it'd drag in all
sorts of associated I/O and support code that, despite never actually
getting called by anything in your program, would end up in the
resultant binary. I can't speak for all compilers, but the recent VS
compilers/linkers do a pretty decent job of removing unused code, as
well as folding together identical code blocks (the latter is *vital* if
you get up to metaprogramming shenanigans). All of this comes with a
fairly high compilation-time cost. (And it makes debugging optimized
builds really fun -- those 50 templated functions you built get rolled
into one function associated with one symbol name...)
- Josh
On Feb 9, 2010, at 6:12 PM, Josh Dersch wrote:
If you have a strong stomach, you should read up on C++ Template
Metaprogramming as well. "Clever" people can do arguably useful things
with it; but I find it unreadable and very difficult to debug (I'm not
that clever, I guess). It's kind of like a limited version of Lisp
macros, only done in a bizarre moon language based on odd C++ template
expansion & overload resolution rules, and with no debugging support...
You can indeed use C#, via the Mono project.
Generics are a very
basic form of C++ templates that are good for creating generic
containers, and that's about it. C++ templates are considerably more
involved, and metaprogramming tricks are used to do all manner of
insane things at compile time. At a very basic level, the two are
the same. It's like saying a Yugo and a Maserati are equivalent
because they are both cars. (yes, you can use analogies here :)
Ok, I understand that a bit better now. I will go read up on
generics a bit. Thanks for the clarification. You
have? Seriously?
Yep. Again, it's a case of bad programmers doing stupid things. Playing
music, playing video files, telnetting, sshing, editing,
compiling, browsing the web, etc etc etc. The apps are a bit
prettier now, certainly moreso than with fvwm, but I'd happily live
without that.
See, here's where I see a disconnect; you are doing the same *class*
of thing, but you're not really doing the same thing. Programs have
gotten more complex because people want more from their software. Regardless of whether Firefox 3.5 was written in
assembly or C++
you'd never hope to run it on your IPX. I just think you are blaming
the wrong thing (or just blaming one thing) for the performance
degradations you are perceiving. OO overhead adds some not
imperceivable overhead; so do each of extensibility, abstraction,
support for "modern standards" (CSS, JavaScript, XML) ui theming,
support for "advanced" desktop metaphors, etc... Code reuse and
abstractions also bring overhead; these exist even in C, but the
overhead is worth it in terms of maintenance and usability (from a
programming and a user perspective.)
I do see where you're coming from. Perhaps I give OO too much
blame, but I stand by my accusations...it does deserve a lot of it, in
my opinion. It wasn't until very recent releases of common C
compilers, for example, that a simple "hello world" program in C++
generated a 600KB (yes, six hundred kilobyte) binary. I've
demonstrated that (along with its 4KB C equivalent) many times. I
was, admittedly, pleased to see that this particular brand of idiocy
has been addressed. I have no idea what was in that damn binary.
-Dave
9:56 p.m.
New subject: Algol vs Fortran was RE: VHDL vs Verilog
If you have a strong stomach, you should read up on
C++ Template
Metaprogramming as well. "Clever" people can do arguably useful things
with it; but I find it unreadable and very difficult to debug (I'm not
that clever, I guess). It's kind of like a limited version of Lisp
macros, only done in a bizarre moon language based on odd C++ template
expansion & overload resolution rules, and with no debugging support...
Mozilla uses templates for low-level stuff in NSPR, which means I have to
occasionally touch them during my Classilla work. They are ... oblique.
The less I have to deal with them, the better. I don't fully understand
them either.
And as an aside, the C/C++ code I've had to deal
with has been, in my
experience, far more bug-prone and unstable than the C# code I've dealt
with :).
But wouldn't that be a constant of any kind of managed code system?
--
------------------------------------ personal: http://www.cameronkaiser.com/ --
Cameron Kaiser * Floodgap Systems * www.floodgap.com * ckaiser at floodgap.com
-- God is Real, unless declared Integer. -- Stan Sieler -----------------------
11:16 p.m.
New subject: Algol vs Fortran was RE: VHDL vs Verilog
One thing I've said for years: C++ is a language that *enables* OOP, but does not
enforce it. (IMHO Philippe Kahn "did wonders to malign the image of OO" as he
promoted Borland's related products.) I remember doing some work in Smalltalk and
thinking, this is really OOP. That doesn't mean it was the way to do everything I
wanted to do.
OOP is a way of looking at problems. Functional programming is a way of looking at
problems. Declarative, imperative, etc., etc. E.g., FORTRAN is an implementation of a
specific instance of a way to look at a specific set of problems. All that we do in
programming languages is to find meaningful ways to map our 'questions, queries,
posers' onto the machines we've built, which underneath it all aren't (for the
largest part) really all that different than when we started building computers. No
programming language I've seen is attempting to or suitable for finding the nine
billion names of God*. Nor have I seen a job posting for a programmer for such a
position.
This is probably why I rarely get involved in debates about programming languages - unless
the subject is COBOL, which I think is an abomination, or Java, which is something you
drink, not code in. -- Ian
*Clarke, Arthur C: The Nine Billion Names of God (orig. 1953 in 'Star Science Fiction
Stories, repub. 1958 in 'The Other Side of the Sky')
________________________________________
From: cctalk-bounces at classiccmp.org [cctalk-bounces at classiccmp.org] On Behalf Of
Josh Dersch [derschjo at mail.msu.edu]
Sent: Wednesday, February 10, 2010 9:21 PM
To: On-Topic and Off-Topic Posts
Subject: Re: Algol vs Fortran was RE: VHDL vs Verilog
I think that C++ did wonders to malign the image of OO. C++ is just
barely OO anyway -- it barely has compile-time encapsulation and has no
real run-time encapsulation, memory management is still almost entirely
manual (which people may argue is a good thing, but in the face of C++
exceptions and other C++ features, it's a HUGE issue since it makes
memory management all that more difficult to do correctly), and
compilers have taken a long time to catch up to the point where they
generate decent code.
-- Josh
11:24 p.m.
New subject: Algol vs Fortran was RE: VHDL vs Verilog
Ian King wrote:
This is probably why I rarely get involved in debates about programming languages -
unless the subject is COBOL, which I think is an abomination, or Java, which is something
you drink, not code in. -- Ian
This is probably good advice. I should follow it more often. :)
- Josh
11:34 p.m.
New subject: Algol vs Fortran was RE: VHDL vs Verilog
What, and miss out on all the fun of a geek 'food fight'? :-)
________________________________________
From: cctalk-bounces at classiccmp.org [cctalk-bounces at classiccmp.org] On Behalf Of
Josh Dersch [derschjo at mail.msu.edu]
Sent: Wednesday, February 10, 2010 11:24 PM
To: On-Topic and Off-Topic Posts
Subject: Re: Algol vs Fortran was RE: VHDL vs Verilog
Ian King wrote:
This is probably why I rarely get involved in debates about programming languages -
unless the subject is COBOL, which I think is an abomination, or Java, which is something
you drink, not code in. -- Ian
This is probably good advice. I should follow it more often. :)
- Josh
11 Feb
11 Feb
11 a.m.
New subject: Algol vs Fortran was RE: VHDL vs Verilog
Ian King wrote:
This is probably why I rarely get involved in debates
about programming languages - unless the subject is COBOL, which I think is an
abomination,
One of my IM statuses is this "Learning COBOL is like seeing a
plush
Cthulhu and petting it before you sign up for the class, but when you
get there, you actually meet the real thing, in the flesh, awakened and
hungry."
Nope, I didn't listen, I thought "Nah, couldn't be THAT bad." Boy was
I
wrong. :-)
or Java, which is something you drink, not code in.
-- Ian
Or a place to visit.
I've recently taken a liking to Lua. Pretty decent for what it is.
Nice and small too. Though I've not done anything with Smalltalk, I do
like it, though coming from C, I do find the syntax a bit weird.
1:13 p.m.
New subject: Object-Oriented Programming models [was RE: Algol vs Fortran was RE: VHDL vs Verilog]
From: Ray Arachelian
Sent: Thursday, February 11, 2010 11:01 AM
Ian King wrote:
> This is probably why I rarely get involved in
debates about programming
> languages - unless the subject is COBOL, which I think is an abomination,
One of my IM statuses is this "Learning COBOL is
like seeing a plush
Cthulhu and petting it before you sign up for the class, but when you
get there, you actually meet the real thing, in the flesh, awakened and
hungry."
Nope, I didn't listen, I thought "Nah,
couldn't be THAT bad." Boy was I
wrong. :-)
Oh, come on. For the problem domain for which it was designed, COBOL is very
good. PL/I improves on it if you're a FORTRAsh programmer, but not much.
> or Java, which is something you drink, not code
in. -- Ian
Or a place to visit.
I've recently taken a liking to Lua. Pretty
decent for what it is.
Nice and small too. Though I've not done anything with Smalltalk, I do
like it, though coming from C, I do find the syntax a bit weird.
Personally, I wish that ANSI X3J13 had chosen Symbolics' New Flavors over
XEROX PARC's LOOPS as its OO model, but both work fine, and are real object
models. (My first exposure to OOP actually *was* Smalltalk, so all those C
based systems feel odd to me.) I already knew Lisp before I saw any OOP.
Rich Alderson
Vintage Computing Sr. Server Engineer
Vulcan, Inc.
505 5th Avenue S, Suite 900
Seattle, WA 98104
mailto:RichA at vulcan.com
mailto:RichA at LivingComputerMuseum.org
http://www.PDPplanet.org/
http://www.LivingComputerMuseum.org/
9:09 p.m.
New subject: Algol vs Fortran was RE: VHDL vs Verilog
I've recently taken a liking to Lua. Pretty
decent for what it is.
I maintained, until the project died, the Mac port of a cross-"compiler" for
Plua, which was my favourite way to program classic PalmOS apps.
But my preferred language for 90% of my tasks is Perl. After that, a
smattering of C/C++, BASIC, Pascal, Tcl/Tk, csh, whatever works well for
the project at hand.
I refuse to write Python, and I find Ruby and PHP too trendy.
--
------------------------------------ personal: http://www.cameronkaiser.com/ --
Cameron Kaiser * Floodgap Systems * www.floodgap.com * ckaiser at floodgap.com
-- Everything! Is my! Delusion! -- "Dead or Alive 2" --------------------------
8:56 a.m.
New subject: Algol vs Fortran was RE: VHDL vs Verilog
In article <4B7393E4.4000603 at mail.msu.edu>,
Josh Dersch <derschjo at mail.msu.edu> writes:
If you have a strong stomach, you should read up on
C++ Template
Metaprogramming as well. "Clever" people can do arguably useful things
with it; but I find it unreadable and very difficult to debug (I'm not
that clever, I guess). [...]
It should be mentioned that you neither need to understand the
template metaprogramming coding or debugging techniques as a user of
the libraries that employ these mechanisms.
For instance, the Spirit library in Boost lets you write recursive
descent parsers in C++ by writing the BNF grammar almost directly *as*
C++ source code. See
<http://www.boost.org/doc/libs/1_41_0/libs/spirit/doc/html/index.html>
<http://www.boost.org/doc/libs/1_41_0/libs/spirit/doc/html/spirit/qi/tutorials/quick_start.html>
Yeah, they employ all kinds of template magic to make this possible,
but as a user of Spirit I really don't need to understand it.
Stepping through the guts of Spirit while I debug my parser isn't any
more or less insane than stepping through the guts of a YACC generated
parser. The Spirit parsers are faster, provide more design options
and are implemented wholly in C++ (no lex or yacc needed). There's no
free lunch however -- the compile times can be hefty and are roughly
proportional to the complexity of the language being parsed.
And as an aside, the C/C++ code I've had to deal
with has been, in my
experience, far more bug-prone and unstable than the C# code I've dealt
with :).
C# is a .22 calibre pistol. C++ is a tactical nuclear weapon.
You don't give tactical nukes to a cadet. :-)
--
"The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download
<http://legalizeadulthood.wordpress.com/the-direct3d-graphics-pipeline/>
Legalize Adulthood! <http://legalizeadulthood.wordpress.com>
12 Feb
12 Feb
12:32 p.m.
New subject: Algol vs Fortran was RE: VHDL vs Verilog
On Thu, 11 Feb 2010 09:56:03 -0700
Richard <legalize at xmission.com> wrote:
C++ is a tactical nuclear weapon.
You don't give tactical nukes to a cadet. :-)
http://classiccmp.org/pipermail/cctalk/2008-July/259890.html
--
tsch??,
Jochen
Homepage: http://www.unixag-kl.fh-kl.de/~jkunz/
4:57 p.m.
New subject: Algol vs Fortran was RE: VHDL vs Verilog
C++ is a tactical nuclear weapon.
You don't give tactical nukes to a cadet. :-)
I have NEVER seen a C++ compiler for the 1620.
The PDQ FORTRAN and the 1401 emulator were far from nuclear.
--
Grumpy Ol' Fred cisin at xenosoft.com
5:35 p.m.
New subject: Algol vs Fortran was RE: VHDL vs Verilog
Chuck Guzis wrote:
On 12 Feb 2010 at 16:57, Fred Cisin wrote:
.. Took me a while. That I was able to get it was due only to the references to
the 1620 you and others have made on the list previously.
I have NEVER seen a C++ compiler for the 1620.
Very clever, Fred!
5:47 p.m.
New subject: Algol vs Fortran was RE:
[C++ is tactical nuclear; don't give tactical nuclear to a CADET)
> > I have NEVER seen a C++ compiler for the
1620.
On Fri, 12 Feb 2010, Brent Hilpert wrote:
.. Took me a while. That I was able to get it was due
only to the references to
the 1620 you and others have made on the list previously.
Sorry,
couldn't resist, even though not everybody knows that the 1620 was also
called "CADET" (Can't Add, Doesn't Even Try)
9 Feb
9 Feb
7:26 p.m.
New subject: Algol vs Fortran was RE: VHDL vs Verilog
On Tuesday 09 February 2010, Dave McGuire wrote:
Feelings? No, experience. Big difference.
Experience with and
knowledge of the past. There is NO RATIONAL REASON why a GUI-based
OS should need more than a billion bytes of memory and a billion-plus
clock cycles per second just to boot. You and I (and many others on
this list) have plenty of examples of machines that do the same thing
with a tiny fraction of those resources.
Minor nit to pick... most of the "billion-plus" cycles per second spent
on booting are spent waiting on I/O. If you look at the amount of time
it takes to boot the same OS in a virtualized environment (and thus has
some reasonable caching going on by the host OS, and emulated hardware
devices), it'll shrink a lot.
And I'm mostly speaking from the experience of running Linux under Xen,
but even Windows Server 2008 under VirtualBox seemed to yield similar
results, when I set that up for a friend.
Pat
--
Purdue University Research Computing --- http://www.rcac.purdue.edu/
The Computer Refuge --- http://computer-refuge.org
8:47 p.m.
New subject: Algol vs Fortran was RE: VHDL vs Verilog
On Feb 9, 2010, at 10:26 PM, Patrick Finnegan wrote:
Yes, I've seen this too. I'm just now wrapping up a fairly fun
consulting project in which I'm virtualizing a few Linux and SCO
OpenServer machines onto a smaller number of boxes using VMware.
Boot times are a bit quicker.
My "just to boot" comment above, though, wasn't meant to reference
boot times at all, though. I meant "just to come into being".
-Dave
--
Dave McGuire
Port Charlotte, FL
Feelings?
No, experience. Big difference. Experience with and
knowledge of the past. There is NO RATIONAL REASON why a GUI-based
OS should need more than a billion bytes of memory and a billion-plus
clock cycles per second just to boot. You and I (and many others on
this list) have plenty of examples of machines that do the same thing
with a tiny fraction of those resources.
Minor nit to pick... most of the "billion-plus" cycles per second
spent
on booting are spent waiting on I/O. If you look at the amount of
time
it takes to boot the same OS in a virtualized environment (and thus
has
some reasonable caching going on by the host OS, and emulated hardware
devices), it'll shrink a lot.
And I'm mostly speaking from the experience of running Linux under
Xen,
but even Windows Server 2008 under VirtualBox seemed to yield similar
results, when I set that up for a friend.
1:14 p.m.
New subject: Algol vs Fortran was RE: VHDL vs Verilog
I wonder how much programmers in the 50's and 60's argued about how many CPU
cycles this programming construct took vs. that. ;)
________________________________
From: Dave McGuire <mcguire at neurotica.com>
To: General Discussion: On-Topic and Off-Topic Posts <cctalk at classiccmp.org>
Sent: Tue, February 9, 2010 2:28:30 PM
Subject: Re: Algol vs Fortran was RE: VHDL vs Verilog
On Feb 9, 2010, at 2:19 PM, Josh Dersch wrote:
Yes, to a large degree! You're talking about it as if it happens ONCE, and you know
it doesn't. Would you care to estimate how many of those vtable lookup happen when
someone simply clicks a mouse in a modern OS? I don't know for certain, but I'm
willing to bet that it's thousands.
Yes, I have to acknowledge this; you'll get no argument from me there. But bad
programmers are the rule, not the exception. Code written by bad programmers constitutes
90% of the code written today. It's possible to write fast, compact C++ or Java code;
we've both seen it. But it's not the norm. KDE, OS X (and several of its apps,
Mail.app comes to mind) *are* the norm, and they're both horribly slow for the
hardware they're typically run on.
In an ideal world, one in which all programmers were competent, OO languages
wouldn't be such a problem. So I guess what I really mean is, "Bad programmers
are even more detrimental to computing when armed with OO languages".
-Dave
--Dave McGuire
Port Charlotte, FL
Ok. Show me
a processor that has an "object" data type, that has subtypes like
"member" and "method" and such. There aren't any. Translating
from such incredibly high-level constructs to registers, stacks, and memory locations is
not without a lot of overhead. Try to envision what happens in the instruction stream
during things like virtual function lookups in C++, for example.
Ok, I'm envisioning it. A few instructions to do a vtable lookup and a jump to the
correct virtual function. Wow. So those extra instructions are what's making every
machine in the world (apparently) very very slow? In C#, virtual lookups are cached at runtime so the
cost of the first virtual call to a function goes through the vtable routine; future calls
are very fast.
That's nice. Now if only C# weren't a proprietary product from one company
which happens to be obsessed with creating vendor lock-in situations. ;)
(though actually, hmm, that IS rather nice...)
Objects in their raw form are not "incredibly
high-level." In C++, an object is referenced via a pointer; data fields are accessed
via offsets just like in C. There is a small overhead for virtual function dispatch. I
fail to see how this overhead is somehow responsible for performance problems in computers
today.
There's a bit of congruity between C's structs and C++/C#/Java/etc objects,
but..
What other overheads/inefficiencies are you thinking
of?
...what happens when someone uses an Integer instead of an int? A whole object gets
created when all one likely needed was a memory location. What happens when one adds that
Integer to another Integer? Add in the address offset calculations to find out where the
actual int is stored within the Integer object, what would those be on most
architectures...two or three instructions? So our nice single-instruction add turns into
at least five instructions.
So you're arguing that increasing the number of instructions required to execute a
simple operation by a factor of five doesn't involve overhead? Ok, howabout when it
happens all the time, which additions tend to in most programs?
In C (for example), there's no motivation at all to wrap a struct around an int just
for the sake of doing so, so it doesn't happen.
And howabout template programming. I've never seen executables so big as the ones
in which templates were overused. (yes, here I have to give a nod to your point about bad
programmers below!) All in the name of "saving programmer time", as if
that's such a big deal, consequences be damned.
Note well, however, that I'm talking about more than just the number of instructions
required to accomplish a given task. Sure, that in itself has bad side effects when you
think about what it does to the instruction cache hit rates...the principal of locality of
reference is blown out the window. But what about memory utilization? How big, in bytes,
is an Integer compared to an int? Ok, the difference may be only a few bytes, but what
about the program (which would be "most of them") with tens of thousands of
them? (I'm typing this on a Mac, into Mail.app, which is currently eating 1.73GB of
memory)
You keep talking about how OO programming is the
reason that software today is so inefficient but you offer no data to back it up other
than "it doesn't map to the hardware."
I'm sorry, but knowing how processors work, it's pretty obvious to me. The data
that backs it up is lots of programs (some of which are operating systems) that I use
every day, written in OO languages, including (perhaps especially!) OS X, are far slower
than they should be given the hardware they're running on. YOU know how processors
work too, I know you do, so I know you see my point.
A modern
multi-GHz Linux box running GTK is far less "responsive"-feeling than my old
SPARCstation-IPX running fvwm when just tooling around the GUI. A little more time spent
by the programmers, ignoring the "easy way out" or heavy OO programming and
it'd be FAR faster.
So it finally comes out: it's the *bad progammers* at fault here. I knew it all
along! Don't confuse poor programmers with programming languages. There are always
efficiency tradeoffs in programming languages and a good programmer knows how to make the
right choices.
1:17 p.m.
New subject: Algol vs Fortran was RE: VHDL vs Verilog
On Tue, Feb 9, 2010 at 4:14 PM, geoffrey oltmans <oltmansg at bellsouth.net> wrote:
I wonder how much programmers in the 50's and
60's argued about how many CPU cycles this programming construct took vs. that. ;)
Probably a lot. In the earliest days, assemblers were considered a
poor use of time on the machine.
Of course, these are the people who argued as to how many digits you
really need to represent a year on the modern calendar. Hint: 2
digits only takes you so far... ;-)
-ethan
2:55 p.m.
New subject: Algol vs Fortran was RE: VHDL vs Verilog
I would imagine you are right. Back in an era where computing power was at a premium, any
wasted cycles were costly. Not so these days. I would argue that in several respects (i.e.
GUI design) OOP makes a lot of sense and writing a GUI environment in a non-OOP language,
while certainly possible, is probably a lot harder to design and make extensible. Again,
not impossible, but could be painful.
That said I see a lot of C++ code at my work that adds unnecessary complexity.
________________________________
From: Ethan Dicks <ethan.dicks at gmail.com>
To: General Discussion: On-Topic and Off-Topic Posts <cctalk at classiccmp.org>
Sent: Tue, February 9, 2010 3:17:08 PM
Subject: Re: Algol vs Fortran was RE: VHDL vs Verilog
On Tue, Feb 9, 2010 at 4:14 PM, geoffrey oltmans <oltmansg at bellsouth.net> wrote:
I wonder how much programmers in the 50's and
60's argued about how many CPU cycles this programming construct took vs. that. ;)
Probably a lot. In the earliest days, assemblers were considered a
poor use of time on the machine.
Of course, these are the people who argued as to how many digits you
really need to represent a year on the modern calendar. Hint: 2
digits only takes you so far... ;-)
-ethan
3:07 p.m.
New subject: Algol vs Fortran was RE: VHDL vs Verilog
On 9 Feb 2010 at 14:55, geoffrey oltmans wrote:
Of course, these are the people who argued as to how
many digits you
really need to represent a year on the modern calendar. Hint: 2
digits only takes you so far... ;-)
100 years, which is longer than we've had electronic digital
computers--or longer, depending on the mechanism used to store the
field (i.e.,. BCD vs. binary vs. ASCII). An awful lot of legacy code
was changed by Y2K programmers to express the year as a 4 digit
field, instead of simply employing "wraparound" logic. But heck, at
$45/hour for a COBOL programmer back then, why not make the job more
complicated?
--Chuck
3:12 p.m.
New subject: Algol vs Fortran was RE: VHDL vs Verilog
Chuck Guzis wrote:
On 9 Feb 2010 at 14:55, geoffrey oltmans wrote:
I think it was the $45 / word of memory that did it.
How many people coding in the late 1950's expected the same aps
would sill run 40+ years later?
Of course, these are the people who argued as to
how many digits you
really need to represent a year on the modern calendar. Hint: 2
digits only takes you so far... ;-)
100 years, which is longer than we've had electronic digital
computers--or longer, depending on the mechanism used to store the
field (i.e.,. BCD vs. binary vs. ASCII). An awful lot of legacy code
was changed by Y2K programmers to express the year as a 4 digit
field, instead of simply employing "wraparound" logic. But heck, at
$45/hour for a COBOL programmer back then, why not make the job more
complicated? --Chuck
3:14 p.m.
New subject: Algol vs Fortran was RE: VHDL vs Verilog
let alone having systems that are compatible? :)
________________________________
From: Ben <bfranchuk at jetnet.ab.ca>
To: On-Topic and Off-Topic Posts <cctalk at classiccmp.org>
Sent: Tue, February 9, 2010 5:12:37 PM
Subject: Re: Algol vs Fortran was RE: VHDL vs Verilog
Chuck Guzis wrote:
On 9 Feb 2010 at 14:55, geoffrey oltmans wrote:
I think it was the $45 / word of memory that did it.
How many people coding in the late 1950's expected the same aps
would sill run 40+ years later?
Of course, these are the people who argued as to
how many digits you
really need to represent a year on the modern calendar. Hint: 2
digits only takes you so far... ;-)
100 years, which is longer than we've had electronic digital
computers--or longer, depending on the mechanism used to store the
field (i.e.,. BCD vs. binary vs. ASCII). An awful lot of legacy code
was changed by Y2K programmers to express the year as a 4 digit
field, instead of simply employing "wraparound" logic. But heck, at
$45/hour for a COBOL programmer back then, why not make the job more
complicated? --Chuck
3:14 p.m.
New subject: Algol vs Fortran was RE: VHDL vs Verilog
On Feb 9, 2010, at 6:12 PM, Ben wrote:
I think it was the $45 / word of memory that did it.
How many people coding in the late 1950's expected the same aps
would sill run 40+ years later?
Shortsightedness is a hallmark of our industry. It always has
been, and probably always will be.
-Dave
--
Dave McGuire
Port Charlotte, FL
Of course, these are the people who argued as to how
many digits you
really need to represent a year on the modern calendar. Hint: 2
digits only takes you so far... ;-)
100 years, which is longer than we've had electronic digital
computers--or longer, depending on the mechanism used to store the
field (i.e.,. BCD vs. binary vs. ASCII). An awful lot of legacy code
was changed by Y2K programmers to express the year as a 4 digit
field, instead of simply employing "wraparound" logic. But heck, at
$45/hour for a COBOL programmer back then, why not make the job more
complicated?
3:50 p.m.
New subject: Algol vs Fortran was RE: VHDL vs Verilog
From: Chuck Guzis
Sent: Tuesday, February 09, 2010 3:07 PM
On 9 Feb 2010 at 14:55, geoffrey oltmans wrote:
> Of course, these are the people who argued as to
how many digits you
> really need to represent a year on the modern calendar. Hint: 2
> digits only takes you so far... ;-)
100 years, which is longer than we've had
electronic digital
computers--or longer, depending on the mechanism used to store the
field (i.e.,. BCD vs. binary vs. ASCII). An awful lot of legacy code
was changed by Y2K programmers to express the year as a 4 digit
field, instead of simply employing "wraparound" logic. But heck, at
$45/hour for a COBOL programmer back then, why not make the job more
complicated?
In those industries in which there is a lot of legacy COBOL code (which
is to say, those industries most affected by the so-called "Y2K bug"),
wraparound on dates is not a particularly good idea. I note the little
old lady in the UK who got a letter from her insurance company expressing
congratulations over the arrival of her new baby girl: A wrap-around
year calculation had turned the 101 year old woman into an infant.
Back in the late 1970s and early 1980s, when I earned my living doing
COBOL and PL/I programming for a major university's financial systems,
I frequently argued with my colleagues about the continued idiocy (no, I
was not politic about it) of using 2-digit years with the turn of the
century only 20 years away. When challenged on it, I could point to my
office mate, one of whose on-going tasks was documenting the major part
of the university's general accounting application which was written in
uncommented 1401 Autocoder, and which ran under emulation on the Amdahl
470 V8, that dated back to 1959. The assistant manager of the FS group
was one of the two people (the other one still in the Comptroller's office)
who wrote the code, 20 years earlier.
*He* backed me up.
Rich Alderson
Vintage Computing Sr. Server Engineer
Vulcan, Inc.
505 5th Avenue S, Suite 900
Seattle, WA 98104
mailto:RichA at vulcan.com
mailto:RichA at LivingComputerMuseum.org
http://www.PDPplanet.org/
http://www.LivingComputerMuseum.org/
5:10 p.m.
New subject: Algol vs Fortran was RE: VHDL vs Verilog
On 9 Feb 2010 at 15:50, Rich Alderson wrote:
In those industries in which there is a lot of legacy
COBOL code
(which is to say, those industries most affected by the so-called "Y2K
bug"), wraparound on dates is not a particularly good idea. I note
the little old lady in the UK who got a letter from her insurance
company expressing congratulations over the arrival of her new baby
girl: A wrap-around year calculation had turned the 101 year old
woman into an infant.
That wasn't my point. What I was getting at was that an awful lot of
code was rewritten unnecessarily simply to accommodate the "bump"
created by Y2K. Not making provision for someone being older than
99 is just plain stupid.
When I think of a military customer from the 1970's, with tons of
7080 COBOL with undocumented binary patches (probably to 'ENTER
AUTOCODER" routines) all running under emulation, the amount of work
needed to unravel that mess for Y2K would have been incredible.
--Chuck
3:44 p.m.
New subject: Algol vs Fortran was RE: VHDL vs Verilog
The comments are wide of the mark.? I started programming in the 1960's.? On an IBM
360/25 for example,? we had 48 KB memory in which to partition F1, F2, and BG.? Larger
systems we would run Power II or HASP, GRASP etc.? the spooler would use up memory.? Now
considering that back then one byte of memory cost a buck it doesn't take a rocket
scientist to? figure out that every little bit counted.? We had 11MB disks given that time
cost money (mount/unmount disks), multi volume files etc,? and that hardware was extremely
expensive it made a lot of sense to consider every aspect of the equation:
1) Run time - I rewrote a number of COBOL programs in 360 BAL (Assembler) that were
resource hogs and took a lot of processor time.? I could reduce the run time of some by a
factor of 5 or more.? COBOL compilers were inefficient and for example multiply, divide
and moves (different data formats) would generate a lot of? machine code instructions.? A
good programmer would know what was good and bad practice.? Example group moves to the
same format, multiple adds instead of multiply.? Assemblers were NOT considered poor use
of machine time? - totally the reverse.? Assembler programmers had to know what they were
doing though and for that I was paid more.? It took far less time to assemble a program in
BAL that compile a COBOL program.? The down side was it took a lot longer to write.
2)? Programs had to be written so that the most frequent parts were in memory due to the
need for the system to page.? BAL I wrote in Csec's (4kb) so that for example one
would perform a credit check, another perform page headings etc.? Maybe it sounds familiar
- reusable code/API's!? So maybe we weren't so stupid after all.
3) Anyone appreciating earlier data processing challenges would also be aware that storage
came at a price.? Also there was a limitation as to what would fit onto a 80 column card
(punched card).? Disc storage wasn't cheap and all this needed to be weighed against
the belief that a system written in 1965 would not be used by Y2K.? Maybe someone would
like to explain to my why my Quick Books purchase in 1996 (C#) wasn't Y2K compliant.?
I found a lot of the computer article written prior to the Y2K switch laughable being
written by people by people that really hadn't a clue as to why the systems had been
written that way in? the first place.
--- On Tue, 2/9/10, Ethan Dicks <ethan.dicks at gmail.com> wrote:
From: Ethan Dicks <ethan.dicks at gmail.com>
Subject: Re: Algol vs Fortran was RE: VHDL vs Verilog
To: "General Discussion: On-Topic and Off-Topic Posts" <cctalk at
classiccmp.org>
Date: Tuesday, February 9, 2010, 4:17 PM
On Tue, Feb 9, 2010 at 4:14 PM, geoffrey oltmans <oltmansg at bellsouth.net> wrote:
I wonder how much programmers in the 50's and
60's argued about how many CPU cycles this programming construct took vs. that. ;)
Probably a lot.? In the earliest days, assemblers were considered a
poor use of time on the machine.
Of course, these are the people who argued as to how many digits you
really need to represent a year on the modern calendar.? Hint: 2
digits only takes you so far... ;-)
-ethan
3:55 p.m.
New subject: Algol vs Fortran was RE: VHDL vs Verilog
On 9 Feb 2010 at 15:44, Russ Bartlett wrote:
It took far less time to assemble a program in BAL
that compile a
COBOL program.? The down side was it took a lot longer to write.
I imagine that you didn't use many I/O library macros then. On a Mod
40 running DOS using the F-level assembler, it took forever for the
assembler to crunch through those things. They were pretty hairy.
--Chuck
4:03 p.m.
New subject: The value of assembler language programmers [was RE: Algol vs Fortran was RE: VHDL vs Verilog]
From: Russ Bartlett
Sent: Tuesday, February 09, 2010 3:44 PM
--- On Tue, 2/9/10, Ethan Dicks <ethan.dicks at
gmail.com> wrote:
> On Tue, Feb 9, 2010 at 4:14 PM, geoffrey oltmans
<oltmansg at bellsouth.net>
> wrote:
>> I wonder how much programmers in the 50's
and 60's argued about how many
>> CPU cycles this programming construct took vs. that. ;)
> Probably a lot. In the earliest days, assemblers
were considered a poor use
> of time on the machine.
The comments are wide of the mark. I started
programming in the 1960's.
On an IBM 360/25 for example, we had 48 KB memory in which to partition F1,
F2, and BG. Larger systems we would run Power II or HASP, GRASP etc. the
spooler would use up memory. Now considering that back then one byte of
memory cost a buck it doesn't take a rocket scientist to figure out that
every little bit counted. We had 11MB disks given that time cost money
(mount/unmount disks), multi volume files etc, and that hardware was
extremely expensive it made a lot of sense to consider every aspect of the
equation:
[ snip ]
Assemblers were NOT considered poor use of machine
time - totally the
reverse. Assembler programmers had to know what they were doing though and
for that I was paid more. It took far less time to assemble a program in
BAL that compile a COBOL program. The down side was it took a lot longer
to write.
I'm pretty sure that Ethan was talking about the attitudes in the mid-1950s,
when assembler languages were born. He is correct that at the time, the use
of assembler languages was controversial, because so much precious computer
time was wasted doing something that any good programmer ought to be able to
do at his desk.
*Every* generation of programmers has *always* looked down on their successors
as using tools that waste too much computer time to do too little. Of course,
*my* generation (started programming in 1969 on a 1401) is right. ;-)
Rich Alderson
Vintage Computing Sr. Server Engineer
Vulcan, Inc.
505 5th Avenue S, Suite 900
Seattle, WA 98104
mailto:RichA at vulcan.com
mailto:RichA at LivingComputerMuseum.org
http://www.PDPplanet.org/
http://www.LivingComputerMuseum.org/
4:59 p.m.
New subject: The value of assembler language programmers [was RE: Algol vs Fortran was RE: VHDL vs Verilog]
On Tue, Feb 9, 2010 at 7:03 PM, Rich Alderson <RichA at vulcan.com> wrote:
Yep. Assemblers vs Machine Code, not Assemblers vs High Level
Language Compilers.
I did say "the earliest days". Sorry for not assigning a year to that.
--- On Tue,
2/9/10, Ethan Dicks <ethan.dicks at gmail.com> wrote:
> Probably a lot. ?In the earliest days, assemblers were considered a poor use
> of time on the machine.
Assemblers were NOT considered poor use of
machine time - totally the
reverse. ?Assembler programmers had to know what they were doing though and
for that I was paid more. ?It took far less time to assemble a program in
BAL that compile a COBOL program. ?The down side was it took a lot longer
to write.
I'm pretty sure that Ethan was talking about the attitudes in the mid-1950s,
when assembler languages were born. ?He is correct that at the time, the use
of assembler languages was controversial, because so much precious computer
time was wasted doing something that any good programmer ought to be able to
do at his desk.
That is the attitude I was recalling.
*Every* generation of programmers has *always* looked
down on their successors
as using tools that waste too much computer time to do too little. ?Of course,
*my* generation (started programming in 1969 on a 1401) is right. ;-)
I certainly agree with you in principle, but I still wonder why even
non-GUI application bloat has to be as bad as it is. We used to put
25-40 users on an 8MB VAX before it would start to swap. Now, still
using a character based interface (which happens to be ssh vs direct
serial connect, but that doesn't affect CLI application size), a
program to tell me what processes are active on the system is 8MB by
itself, vs a few dozen K bytes (I should go back and dig out one of
those programs from the old days and port it to a modern machine to
compare library bloat vs application bloat. Fortunately, I have my
backups from 25 years ago).
This is C code then and C code now, 80x25 then and 80x25 now. UNIX
then and UNIX or Linux now. 32-bit processors then, 32-bit processors
now. Not quite apples to oranges like most comparisons reaching back
that far across the generations of equipment and mentalities.
25+ years later, how far have uber-fast machines with uber-large and
uber-cheap storage really gotten us? Not as far as the raw numbers
might lead one to think. I can buy a machine that about fits in my
pocket that has 500 times the memory, 500 times the storage, and has a
clock that's nearly 500 times faster for 1/500th the cost* - a
250,000X price-performance advantage. I think quite a bit of that
500x multiplier is getting pissed away before I type a single
character. Yes it can do more; yes it feels faster. That much
faster? Not in my opinion.
-ethan
* Numbers based on 1984 stats for a VAX-11/750 w/RA81 - approx $150K,
integer speed approx the same as 8MHz 68000, 8MB RAM, 450 MB of disk,
compared with a modern portable 3.6GHz machine w/4GB of RAM and 250GB
of disk for under $400. Some settling may have occurred in shipping.
Post No Bills, etc.
-ethan
5:13 p.m.
New subject: The value of assembler language programmers [was RE: Algol vs Fortran was RE: VHDL vs Verilog]
Ethan Dicks wrote:
[ actually a lot of good stuff] ;-)
25+ years later, how far have uber-fast machines with uber-large and
uber-cheap storage really gotten us? Not as far as the raw numbers
might lead one to think. I can buy a machine that about fits in my
pocket that has 500 times the memory, 500 times the storage, and has a
clock that's nearly 500 times faster for 1/500th the cost* - a
250,000X price-performance advantage. I think quite a bit of that
500x multiplier is getting pissed away before I type a single
character. Yes it can do more; yes it feels faster. That much
faster? Not in my opinion.
That's why I love to embedded stuff. And even here, any "reasonable"
Real Time OS of today, can't really boot with 48 kbytes of memory.
Progress I guess ;-)
5:22 p.m.
New subject: The value of assembler language programmers [was RE: Algol vs Fortran was RE: VHDL vs Verilog]
On Tue, Feb 9, 2010 at 8:13 PM, e.stiebler <emu at e-bbes.com> wrote:
That brings to mind the assertions from Apple and Microsoft in the
mid-1980s - that you "needed" 2MB of memory to multitask. Over a
dozen simultaneously-updating "dotty windows" on a 256K A1000 was
simple proof that there was another way.
Ethan Dicks wrote:
>
> [ actually a lot of good stuff] ;-)
Thank you.
25+ years
later, how far have uber-fast machines with uber-large and
uber-cheap storage really gotten us?
That's why I love to embedded stuff. And even here, any "reasonable" Real
Time OS of today, can't really boot with 48 kbytes of memory. Progress I guess ;-)
Of a sort, I guess ;-)
-ethan
5:28 p.m.
New subject: The value of assembler language programmers [was RE: Algol vs Fortran was RE: VHDL vs Verilog]
Ethan Dicks wrote:
That brings to mind the assertions from Apple and
Microsoft in the
mid-1980s - that you "needed" 2MB of memory to multitask. Over a
dozen simultaneously-updating "dotty windows" on a 256K A1000 was
simple proof that there was another way.
But they were cheating on the A1000.
There was a processor in it ;-)
Cheers
5:43 p.m.
New subject: The value of assembler language programmers [was RE: Algol vs Fortran was RE: VHDL vs Verilog]
On Tue, Feb 9, 2010 at 8:28 PM, e.stiebler <emu at e-bbes.com> wrote:
Ethan Dicks wrote:
Sort of... the dedicated graphics hardware provided visually
impressive fill rates (try opening up the AmigaDOS "clock" tool and
resizing it to fill the screen - it paints thousands of pixels on two
bitplanes fast enough that you can barely see the polygons fill), but
the real-time executive kernel (EXEC) was what serviced all those
windows without a drop of application code to task-switch, unlike DOS
or the classic MacOS. The machine was built from the ground up to
support multitasking, unlike the other "popular" home platforms of the
day. The custom chips just offloaded mundane data moving tasks
(blitting, floppy data massaging, etc) leaving more time for the CPU
to service all the processes on the machine.
I did some work hacking "co-operative multitasking" application code
to work on the Amiga (swaths of code deleted!). Boy was that stuff a
mess. It really made me appreciate coming to the Amiga from UNIX,
instead of coming "up" from other environments.
Of course, earlier generations would decry task switching overhead as
"wasteful" - just put all the jobs in a queue, run each job to
completion really, really fast, then stack the output in the
pigeonholes ;-) (I came in at the tail-end of the Batch vs
Interactive Wars - I had *one* class in college that we submitted
batch jobs to, but thankfully for my sanity at the time, it was
terminal submissions, not punch-card submissions. I did all my work
on 3270 terminals, and except for the 15,000-job-long run queues, it
wasn't so bad).
-ethan
That brings to mind the assertions from Apple and Microsoft in the
mid-1980s - that you "needed" 2MB of memory to multitask. ?Over a
dozen simultaneously-updating "dotty windows" on a 256K A1000 was
simple proof that there was another way.
But they were cheating on the A1000.
There was a processor in it ;-)
5:24 p.m.
New subject: The value of assembler language programmers [was RE: Algol vs Fortran was RE: VHDL vs Verilog]
On 9 Feb 2010 at 18:13, e.stiebler wrote:
That's why I love to embedded stuff. And even
here, any "reasonable"
Real Time OS of today, can't really boot with 48 kbytes of memory.
Been on the AVR forums much lately? It's getting more difficult to
find someone who writes in assembler. I suspect it's almost
impossible on the ARM uC area.
HLLs march on...
--Chuck
5:34 p.m.
New subject: The value of assembler language programmers [was RE: Algol vs Fortran was RE: VHDL vs Verilog]
On Tue, Feb 9, 2010 at 8:24 PM, Chuck Guzis <cclist at sydex.com> wrote:
On 9 Feb 2010 at 18:13, e.stiebler wrote:
I myself have only ever programmed AVRs in C (including older parts
that had a mere 2K of code space), but I've done some PIC and MCS51
assembler in the past 5 years. Not much point to it usually, though.
That much optimization is rarely needed in a part that has limited I/O
and very limited memory. Occasionally, though, tasks like video
timing or less-sloppy clock precision can benefit from some
well-formed assembler.
It wouldn't surprise me to learn that ARM microcontrollers were
"impossible" to program in assembler. Workstations turned that corner
when they went from CISC to RISC - I know very, very few RISC
assembler programmers, but dozens who have done CISC assembly.
-ethan
That's why I love to embedded stuff. And even
here, any "reasonable"
Real Time OS of today, can't really boot with 48 kbytes of memory.
Been on the AVR forums much lately? ?It's getting more difficult to
find someone who writes in assembler. ?I suspect it's almost
impossible on the ARM uC area.
5:52 p.m.
New subject: The value of assembler language programmers [was RE: Algol vs Fortran was RE: VHDL vs Verilog]
On Feb 9, 2010, at 8:34 PM, Ethan Dicks wrote:
I myself have only ever programmed AVRs in C
(including older parts
that had a mere 2K of code space), but I've done some PIC and MCS51
assembler in the past 5 years. Not much point to it usually, though.
That much optimization is rarely needed in a part that has limited I/O
and very limited memory.
That's funny, I find that sort of optimization is required
*because* the parts have limited memory. ;) (not arguing about I/O
though)
On 8051 designs, I always code very low-level routines that will
be called a lot in assembler. Stuff like the low-level UART drivers
for maintaining serial output buffers and such. The rest I generally
do in C. I rarely write pure-C 8051 programs.
It wouldn't surprise me to learn that ARM
microcontrollers were
"impossible" to program in assembler. Workstations turned that corner
when they went from CISC to RISC - I know very, very few RISC
assembler programmers, but dozens who have done CISC assembly.
Absolutely. ARM is just plain difficult. Very interesting, but
difficult. I won't go there in any serious way...all C on ARM for me.
-Dave
--
Dave McGuire
Port Charlotte, FL
6:06 p.m.
New subject: The value of assembler language programmers [was RE: Algol vs Fortran was RE: VHDL vs Verilog]
On Tue, Feb 9, 2010 at 8:52 PM, Dave McGuire <mcguire at neurotica.com> wrote:
On Feb 9, 2010, at 8:34 PM, Ethan Dicks wrote:
I was unclear - I meant time/cycle optimization, not space optimization.
For bang-for-the-buck, AVRs are pretty good. The most expensive one I
ever bought was just over $3.
I myself have only ever programmed AVRs in C (including older parts
that had a mere 2K of code space), but I've done some PIC and MCS51
assembler in the past 5 years. ?Not much point to it usually, though.
That much optimization is rarely needed in a part that has limited I/O
and very limited memory.
?That's funny, I find that sort of optimization is required *because* the
parts have limited memory. ;) ?(not arguing about I/O though) ?On 8051 designs, I always code very low-level
routines that will be called
a lot in assembler. ?Stuff like the low-level UART drivers for maintaining
serial output buffers and such. ?The rest I generally do in C. ?I rarely
write pure-C 8051 programs.
Sure... serial comms are one of those time-sensitive things like
video. When I used to write protocol engine code, our Z8530 routines
were in assembler and 95% of the rest of the code was C (even the DMA
engine code).
-ethan
8:55 p.m.
New subject: The value of assembler language programmers [was RE: Algol vs Fortran was RE: VHDL vs Verilog]
On Feb 9, 2010, at 9:06 PM, Ethan Dicks wrote:
I was unclear - I meant time/cycle optimization, not space
optimization.
Ahh, gotcha.
We work along similar philosophies. :)
-Dave
--
Dave McGuire
Port Charlotte, FL
I myself have only ever programmed AVRs in C
(including older parts
that had a mere 2K of code space), but I've done some PIC and MCS51
assembler in the past 5 years. Not much point to it usually,
though.
That much optimization is rarely needed in a part that has
limited I/O
and very limited memory.
That's funny, I find that sort of optimization is required
*because* the
parts have limited memory. ;) (not arguing about I/O though) For bang-for-the-buck, AVRs are pretty good. The most
expensive one I
ever bought was just over $3.
That's excellent. There's no denying that they are Good Stuff
(tm). And their development suite support is good too, not just
loads of overpriced Windows-only binary-only commercial garbage.
On 8051
designs, I always code very low-level routines that will
be called
a lot in assembler. Stuff like the low-level UART drivers for
maintaining
serial output buffers and such. The rest I generally do in C. I
rarely
write pure-C 8051 programs.
Sure... serial comms are one of those time-sensitive things like
video. When I used to write protocol engine code, our Z8530 routines
were in assembler and 95% of the rest of the code was C (even the DMA
engine code). 
7:38 p.m.
New subject: The value of assembler language programmers [was RE: Algol vs Fortran was RE: VHDL vs Verilog]
Ethan Dicks wrote:
On Tue, Feb 9, 2010 at 8:24 PM, Chuck Guzis <cclist
at sydex.com> wrote:
You may well be nearly right about the "impossible" part, though I
notice you put it in quotes which I interpret to mean you think it may
only be extremely difficult. I never got really serious about it, but I
did look at just a few of the "start up" instructions in an ARM-7 TDMI
chip (Philips/NXP 2148 actually) once when I was trying to puzzle
something out about what happened just after a reset - like which I/O
pins were checked in what order to see what to do next. The
instructions did seem rather arcane, but I was able to puzzle out enough
for my purposes and felt that I could have understood it fully if I had
the time and a real need to do so. Might not be a lot of fun though. I
still have an eval board for that chip, so maybe some day I'll dig a
little deeper and see how bad it really is. In some of my reading I
have gotten the idea that over the years the difference in CISC and RISC
has been substantially reduced too. Just as one example, I understand
that early on the RISC guys insisted that every instruction be the same
length but evidently that went out the window over time when they
realized the non-economy of insisting on that philosophy. From what I
read, over time the line between CISC and RISC has became even more
blurred. If this is true then assembly language programming for the
latest ARM might be much easier than RISC assembly was early on, and
might not be so bad after all.
Later,
Charlie C.
On 9 Feb 2010 at 18:13, e.stiebler wrote:
I myself have only ever programmed AVRs in C (including older parts
that had a mere 2K of code space), but I've done some PIC and MCS51
assembler in the past 5 years. Not much point to it usually, though.
That much optimization is rarely needed in a part that has limited I/O
and very limited memory. Occasionally, though, tasks like video
timing or less-sloppy clock precision can benefit from some
well-formed assembler.
It wouldn't surprise me to learn that ARM microcontrollers were
"impossible" to program in assembler. Workstations turned that corner
when they went from CISC to RISC - I know very, very few RISC
assembler programmers, but dozens who have done CISC assembly.
-ethan
That's why I love to embedded stuff. And even
here, any "reasonable"
Real Time OS of today, can't really boot with 48 kbytes of memory.
Been on the
AVR forums much lately? It's getting more difficult to
find someone who writes in assembler. I suspect it's almost
impossible on the ARM uC area.
5:38 p.m.
New subject: The value of assembler language programmers [was RE: Algol vs Fortran was RE: VHDL vs Verilog]
Chuck Guzis wrote:
Been on the AVR forums much lately? It's getting
more difficult to
find someone who writes in assembler. I suspect it's almost
impossible on the ARM uC area.
Sorry, never liked them. They are cheap, and everybody (?) is crazy
about them. But to many different versions out
(thumb/native/cortex/whatever). Not really easy to deal with them on a
lower level.
5:48 p.m.
New subject: The value of assembler language programmers [was RE: Algol vs Fortran was RE: VHDL vs Verilog]
On Feb 9, 2010, at 8:24 PM, Chuck Guzis wrote:
In SOME places, yes. AVRs are an interesting anomaly: They're
extremely powerful processors with very low barriers to entry. Lots
of beginners start out with AVRs. (I'm NOT suggesting that AVRs are
only for beginners!) Lots of beginners also seem to think that
nobody programs in assembler anymore.
Granted, far fewer do now than, say, thirty years ago, but lots
do. One cannot replace all programming with HLLs, no more than one
can replace all programming with C# or Java.
ARMs are damn near impossible to program in assembler. That's why
everyone uses C in that world. Lots of [modern incarnation] Z80, Z8,
8051, and low-end PIC development is done, both professionally and
otherwise, in assembler today. Since those architectures aren't
changing, and it's mainly done that way because of the architectures,
I doubt it'll ever change. It certainly hasn't yet.
-Dave
--
Dave McGuire
Port Charlotte, FL
That's why
I love to embedded stuff. And even here, any "reasonable"
Real Time OS of today, can't really boot with 48 kbytes of memory.
Been on the AVR forums much lately? It's getting more difficult to
find someone who writes in assembler. I suspect it's almost
impossible on the ARM uC area.
HLLs march on...
5:54 p.m.
New subject: The value of assembler language programmers [was RE: Algol vs Fortran was RE: VHDL vs Verilog]
Dave McGuire wrote:
ARMs are damn near impossible to program in
assembler. That's why
everyone uses C in that world. Lots of [modern incarnation] Z80, Z8,
8051, and low-end PIC development is done, both professionally and
otherwise, in assembler today. Since those architectures aren't
changing, and it's mainly done that way because of the architectures, I
doubt it'll ever change. It certainly hasn't yet.
What we need is a J11/T11 chip again, so we can program MACRO11 again ;-)
(I know of the rumor, that the msp430 is loved by old pdp11 guys)
5:57 p.m.
New subject: The value of assembler language programmers [was RE: Algol vs Fortran was RE: VHDL vs Verilog]
On Feb 9, 2010, at 8:54 PM, e.stiebler wrote:
What we need is someone to code one up in VHDL or Verilog with a
reasonable (read: easy to use for non-FPGA-gods) interface to the
outside world.
ARMs are
damn near impossible to program in assembler. That's
why everyone uses C in that world. Lots of [modern incarnation]
Z80, Z8, 8051, and low-end PIC development is done, both
professionally and otherwise, in assembler today. Since those
architectures aren't changing, and it's mainly done that way
because of the architectures, I doubt it'll ever change. It
certainly hasn't yet.
What we need is a J11/T11 chip again, so we can program MACRO11
again ;-) (I know of the rumor, that the msp430 is loved by old
pdp11 guys)
With good reason...look at the architecture! I almost got misty-
eyed when I looked at the instruction set. I hope to do more with
msp430s soon.
-Dave
--
Dave McGuire
Port Charlotte, FL
8:10 p.m.
New subject: The value of assembler language programmers [was RE: Algol vs Fortran was RE: VHDL vs Verilog]
Think about it, if Ken Olsen hadn't been so dismissive of the idea of a Personal
Computer, we might have had J11-based desktops. After all, a J11 with MMU could address
4MB, instead of the anemic 1MB of the 8086/88. -- Ian
________________________________________
From: cctalk-bounces at classiccmp.org [cctalk-bounces at classiccmp.org] On Behalf Of
e.stiebler [emu at e-bbes.com]
Sent: Tuesday, February 09, 2010 5:54 PM
To: On-Topic and Off-Topic Posts
Subject: Re: The value of assembler language programmers [was RE: Algol vs Fortran
was RE: VHDL vs Verilog]
Dave McGuire wrote:
ARMs are damn near impossible to program in
assembler. That's why
everyone uses C in that world. Lots of [modern incarnation] Z80, Z8,
8051, and low-end PIC development is done, both professionally and
otherwise, in assembler today. Since those architectures aren't
changing, and it's mainly done that way because of the architectures, I
doubt it'll ever change. It certainly hasn't yet.
What we need is a J11/T11 chip again, so we can program MACRO11 again ;-)
(I know of the rumor, that the msp430 is loved by old pdp11 guys)
10 Feb
10 Feb
2:04 a.m.
New subject: The value of assembler language programmers [was RE: Algol vs Fortran was RE: VHDL vs Verilog]
Ian King wrote:
Think about it, if Ken Olsen hadn't been so
dismissive of the idea of a Personal Computer,
we might have had J11-based desktops. After all, a J11 with MMU could
address
4MB,
instead of the anemic 1MB of the 8086/88. -- Ian
We had. Pro380 ;-)
11:39 a.m.
New subject: The value of assembler language programmers [was RE: Algol vs Fortran was RE: VHDL vs Verilog]
-----Original Message-----
From: cctalk-bounces at classiccmp.org [mailto:cctalk-
bounces at classiccmp.org] On Behalf Of e.stiebler
Sent: Wednesday, February 10, 2010 2:04 AM
To: On-Topic and Off-Topic Posts
Subject: Re: The value of assembler language programmers [was RE: Algol
vs Fortran was RE: VHDL vs Verilog]
Ian King wrote:
No, I mean ones that people actually bought.
Think about it, if Ken Olsen hadn't been so
dismissive of the idea of
a Personal Computer,
we might have had J11-based desktops. After all,
a J11 with MMU
could
address 4MB,
instead of the anemic 1MB of the 8086/88. -- Ian
We had. Pro380 ;-)
noon
New subject: The value of assembler language programmers [was RE: Algol vs Fortran was RE: VHDL vs Verilog]
I wonder how successful the likes of the Dec PRO series would have been had they not been
astronomically expensive, even compared to the already expensive IBM PC/XT. I had a
Pro/350 that my uncle bought brand new, and at the time I think he spent close to $10k on
it around 1983ish and it still had a monochrome display.
________________________________
From: Ian King <IanK at vulcan.com>
To: General Discussion: On-Topic and Off-Topic Posts <cctalk at classiccmp.org>
Sent: Wed, February 10, 2010 1:39:35 PM
Subject: RE: The value of assembler language programmers [was RE: Algol vs Fortran was RE:
VHDL vs Verilog]
-----Original Message-----
From: cctalk-bounces at classiccmp.org [mailto:cctalk-
bounces at classiccmp.org] On Behalf Of e.stiebler
Sent: Wednesday, February 10, 2010 2:04 AM
To: On-Topic and Off-Topic Posts
Subject: Re: The value of assembler language programmers [was RE: Algol
vs Fortran was RE: VHDL vs Verilog]
Ian King wrote:
No, I mean ones that people actually bought.
Think about it, if Ken Olsen hadn't been so
dismissive of the idea of
a Personal Computer,
we might have had J11-based desktops. After all,
a J11 with MMU
could
address 4MB,
instead of the anemic 1MB of the 8086/88. -- Ian
We had. Pro380 ;-)
1:53 p.m.
New subject: The value of assembler language programmers [was RE: Algol vs Fortran was RE: VHDL vs Verilog]
On Wed, Feb 10, 2010 at 3:00 PM, geoffrey oltmans
<oltmansg at bellsouth.net> wrote:
I wonder how successful the likes of the Dec PRO
series would have been had they not been astronomically expensive, even compared to the
already expensive IBM PC/XT. I had a Pro/350 that my uncle bought brand new, and at the
time I think he spent close to $10k on it around 1983ish and it still had a monochrome
display.
For comparison, a "standard package" color IBM PC/AT (5170) w/dot
matrix printer and hard disk (larger than the Pro, admittedly) was $5K
at launch in 1985, IIRC.
-ethan
2:16 p.m.
New subject: The value of assembler language programmers [was RE: Algol vs Fortran was RE: VHDL vs Verilog]
Yep... I'd say doomed from that perspective. Still, I remember the Pro/350 fondly.
Nice machine. There's a pretty cool promotional/documentary type video of Digital and
the Pro series. Pretty funny in retrospect.
________________________________
From: Ethan Dicks <ethan.dicks at gmail.com>
To: General Discussion: On-Topic and Off-Topic Posts <cctalk at classiccmp.org>
Sent: Wed, February 10, 2010 3:53:06 PM
Subject: Re: The value of assembler language programmers [was RE: Algol vs Fortran was
RE: VHDL vs Verilog]
On Wed, Feb 10, 2010 at 3:00 PM, geoffrey oltmans
<oltmansg at bellsouth.net> wrote:
I wonder how successful the likes of the Dec PRO
series would have been had they not been astronomically expensive, even compared to the
already expensive IBM PC/XT. I had a Pro/350 that my uncle bought brand new, and at the
time I think he spent close to $10k on it around 1983ish and it still had a monochrome
display.
For comparison, a "standard package" color IBM PC/AT (5170) w/dot
matrix printer and hard disk (larger than the Pro, admittedly) was $5K
at launch in 1985, IIRC.
-ethan
3:39 p.m.
New subject: The value of assembler language programmers [was RE: Algol vs Fortran was RE: VHDL vs Verilog]
Ethan Dicks wrote:
For comparison, a "standard package" color
IBM PC/AT (5170) w/dot
matrix printer and hard disk (larger than the Pro, admittedly) was $5K
at launch in 1985, IIRC.
And a PC/AT compatible could be had for less than $3k at MicroCenter in
that time frame. I remember taking my parents to Columbus and convincing
them I needed it for school. I still have the chassis and the monitor,
but the motherboard gave up the ghost when I started doing ISA hardware
hacking.
-ethan
-chuck
11 Feb
11 Feb
8:40 a.m.
New subject: The value of assembler language programmers [was RE: Algol vs Fortran was RE: VHDL vs Verilog]
Ethan Dicks wrote:
> For comparison, a "standard package" color IBM PC/AT (5170) w/dot
> matrix printer and hard disk (larger than the Pro, admittedly) was $5K
> at launch in 1985, IIRC.
$5,000 in 1985 is the equivalent of $9876.79 in 2008.[*]
I know we all realize that inflation is eating away at the value of
currency, but it really has picked up quite a bit in the last decade
such that even 1985 currency is quite different from today.
That just floors me because in 1986 I took out a $4,000 loan to get an
Amiga 1000 with dual flopppy drives and a monitor. (I also got the extra
CHIP ram expansion thingy on the front.)
[*] http://www.westegg.com/inflation/infl.cgi
--
"The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download
<http://legalizeadulthood.wordpress.com/the-direct3d-graphics-pipeline/>
Legalize Adulthood! <http://legalizeadulthood.wordpress.com>
9:16 a.m.
New subject: The value of assembler language programmers [was RE: Algol vs Fortran was RE: VHDL vs Verilog]
This is a good point. I was comparing dollars in early 80's dollar amounts for the
difference between the IBM and DEC offerings. There's significant different in the
number, but as you indicate the difference is quite a bit more shocking when you put it
into today's denominated dollars. Computers today are waaay cheaper than they used to
be.
________________________________
From: Richard <legalize at xmission.com>
To: General Discussion: On-Topic and Off-Topic Posts <cctalk at classiccmp.org>
Sent: Thu, February 11, 2010 10:40:55 AM
Subject: Re: The value of assembler language programmers [was RE: Algol vs Fortran was RE:
VHDL vs Verilog]
Ethan Dicks wrote:
> For comparison, a "standard package" color IBM PC/AT (5170) w/dot
> matrix printer and hard disk (larger than the Pro, admittedly) was $5K
> at launch in 1985, IIRC.
$5,000 in 1985 is the equivalent of $9876.79 in 2008.[*]
I know we all realize that inflation is eating away at the value of
currency, but it really has picked up quite a bit in the last decade
such that even 1985 currency is quite different from today.
That just floors me because in 1986 I took out a $4,000 loan to get an
Amiga 1000 with dual flopppy drives and a monitor. (I also got the extra
CHIP ram expansion thingy on the front.)
[*] http://www.westegg.com/inflation/infl.cgi
--
"The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download
<http://legalizeadulthood.wordpress.com/the-direct3d-graphics-pipeline/>
Legalize Adulthood! <http://legalizeadulthood.wordpress.com>
10 Feb
10 Feb
1:36 p.m.
New subject: The value of assembler language programmers [was RE: Algol vs Fortran was RE: VHDL vs Verilog]
On Wed, Feb 10, 2010 at 2:39 PM, Ian King <IanK at vulcan.com> wrote:
Remember David Sarnoff's comment, "I think there is a world market for
maybe five computers"? Perhaps he was just prescient about the
Pro380. ;-)
-ethan
(Who has one. Are the other four owners already on this list?)
Ian King
wrote:
No, I mean ones that people actually bought. Think about it, if Ken Olsen hadn't been so
dismissive of the idea of
a Personal Computer, we might have had J11-based
desktops...
We had. Pro380 ;-)
1:39 p.m.
New subject: The value of assembler language programmers [was RE: Algol vs Fortran was RE: VHDL vs Verilog]
Ethan Dicks wrote:
On Wed, Feb 10, 2010 at 2:39 PM, Ian King <IanK at
vulcan.com> wrote:
Remember David Sarnoff's comment, "I think there is a world market for
maybe five computers"? Perhaps he was just prescient about the
Pro380. ;-)
-ethan
(Who has one. Are the other four owners already on this list?)
Thank you Ethan, very much !
I have more than half of the computer market in my garage ;-)
(two pro380, three pro350 ;-))
Ian King
wrote:
No, I mean ones that people actually bought. Think about it, if Ken Olsen hadn't been so
dismissive of the idea of
a Personal Computer, we might have had J11-based
desktops...
We had. Pro380 ;-)
1:40 p.m.
New subject: The value of assembler language programmers [was RE: Algol vs Fortran was RE: VHDL vs Verilog]
On Feb 10, 2010, at 4:36 PM, Ethan Dicks wrote:
No, I mean ones that people actually bought.
Remember David Sarnoff's comment, "I think there is a world market for
maybe five computers"? Perhaps he was just prescient about the
Pro380. ;-)
I thought that was Ken Olsen.
-Dave
--
Dave McGuire
Port Charlotte, FL
Think about
it, if Ken Olsen hadn't been so dismissive of the
idea of
a Personal Computer, we might have had J11-based desktops...
We had. Pro380 ;-)
1:59 p.m.
New subject: The value of assembler language programmers [was RE: Algol vs Fortran was RE: VHDL vs Verilog]
On Wed, Feb 10, 2010 at 4:40 PM, Dave McGuire <mcguire at neurotica.com> wrote:
On Feb 10, 2010, at 4:36 PM, Ethan Dicks wrote:
Ken Olsen famously asked who would want a computer at home. If I
recall the story correctly, it was in the context of Dave Ahl trying
to pitch a hobbyist-grade PDP-8/a as a product offering in the
Altair/MITS (pre-Apple/CBM/Tandy) days.
-ethan
Remember David Sarnoff's comment, "I
think there is a world market for
maybe five computers"? ?Perhaps he was just prescient about the
Pro380. ?;-)
?I thought that was Ken Olsen.
3:45 p.m.
New subject: The value of assembler language programmers [was RE: Algol vs Fortran was RE: VHDL vs Verilog]
On 10 Feb 2010 at 16:59, Ethan Dicks wrote:
Ken Olsen famously asked who would want a computer at
home. If I
recall the story correctly, it was in the context of Dave Ahl trying
to pitch a hobbyist-grade PDP-8/a as a product offering in the
Altair/MITS (pre-Apple/CBM/Tandy) days.
He wasn't alone. I remember asking an EE prof who was teaching logic
circuits what he thought about the possibilities of a computer on a
chip (ICs were fairly new stuff then).
He looked at me like I'd suggested that everyone should have their
own personal cyclotron. "What good would that be?" and he dismissed
it with a wave of his hand.
Personally, I still want a computer that will paint my house and
repair the fence in the backyard.
--Chuck
4:08 p.m.
New subject: The value of assembler language programmers [was RE: Algol vs Fortran was RE: VHDL vs Verilog]
At UC Berkeley, ~15 years ago, Clancy and Harvey took over the lower
division undergraduate CS instruction. They used Scheme (a Lisp
derivative), because "recursion is the only possible way to solve a
problem with more than one independent variable" (I didn't know that
nested loops were "impossible"), and they declared,
"Nobody uses assembly language any more, nor ever will again!"
UC Berkeley was ONCE a good place to learn CS.
--
Grumpy Ol' Fred (a nobody)
11 Feb
11 Feb
12:54 p.m.
New subject: The value of assembler language programmers [was RE: Algol vs
Personally, I still want a computer that will paint my
house and
repair the fence in the backyard.
IIRC, the original definiton of 'computer' was a person who operates a
computing machine. In which case finding one that can paint your house
shouldn't be too hard.
-tony
1:42 p.m.
New subject: The value of assembler language programmers [was RE: Algol vs
On 11 Feb 2010 at 20:54, Tony Duell wrote:
Heh. I haven't looked at the latest ANSI X3 Fortran (2003?) spec,
but I do recall that the '90 spec defined computer as "anyhing
capable of computation, including a human being.
On the other hand, I'm not certain about some human beings...
--Chuck
Personally, I
still want a computer that will paint my house and
repair the fence in the backyard.
IIRC, the original definiton of 'computer' was a person who operates a
computing machine. In which case finding one that can paint your house
shouldn't be too hard.
4 p.m.
New subject: The value of assembler language programmers [was RE: Algol vs
Tony Duell wrote:
To put a finer point on it, I expect the original definition would have been
someone who did the computation, then became someone who operated an adding
machine or calculator, then the modern/current definition.
Personally, I still want a computer that will
paint my house and
repair the fence in the backyard.
IIRC, the original definiton of 'computer' was a person who operates a
computing machine. In which case finding one that can paint your house
shouldn't be too hard.
8:37 p.m.
New subject: The value of assembler language programmers [was RE: Algol vs
Chuck Guzis wrote:
On 11 Feb 2010 at 16:17, Fred Cisin wrote:
Random walk to keep paint free, here!
Well, we all know about "fencepost
errors", but how computationally
intensive is your house painting?
It's basically a ladder funciton... --Chuck
10 Feb
10 Feb
1:40 p.m.
New subject: The value of assembler language programmers [was RE: Algol vs Fortran was RE: VHDL vs Verilog]
On Feb 10, 2010, at 4:36 PM, Ethan Dicks wrote:
Remember David Sarnoff's comment, "I think there is a world market for
maybe five computers"? Perhaps he was just prescient about the
Pro380. ;-)
...or was it TJ Watson of IBM? I'm pretty sure that was his quote.
-Dave
--
Dave McGuire
Port Charlotte, FL
Ian King wrote:
No, I mean ones that people actually bought. Think about it, if Ken Olsen hadn't been so
dismissive of the
idea of
a Personal Computer, we might have had J11-based desktops...
We had. Pro380 ;-)
1:45 p.m.
New subject: The value of assembler language programmers [was RE: Algol vs Fortran was RE: VHDL vs Verilog]
On 10 Feb 2010 at 16:40, Dave McGuire wrote:
...or was it TJ Watson of IBM? I'm pretty sure
that was his quote.
It's often attributed to Watson, but the attributions are all from
the 1980s. There's no solid evidence that he ever said it.
--Chuck
1:54 p.m.
New subject: "only 5 computers" [was RE: The value of assembler language programmers]
From: Chuck Guzis
Sent: Wednesday, February 10, 2010 1:45 PM
On 10 Feb 2010 at 16:40, Dave McGuire wrote:
> ...or was it TJ Watson of IBM? I'm pretty
sure that was his quote.
It's often attributed to Watson, but the
attributions are all from
the 1980s. There's no solid evidence that he ever said it.
http://freakonomics.blogs.nytimes.com/2008/04/17/our-daily-bleg-did-ibm-rea…
The truth, as is so often the case, is more complex than that. According to
the source cited above, what Watson reported to the 1953 stockholder's meeting
was that their expectation with regard to sales of the 701, when they visited 20
potential customers, was for 5 orders. Instead, they got 18.
Rich Alderson
Vintage Computing Sr. Server Engineer
Vulcan, Inc.
505 5th Avenue S, Suite 900
Seattle, WA 98104
mailto:RichA at vulcan.com
mailto:RichA at LivingComputerMuseum.org
http://www.PDPplanet.org/
http://www.LivingComputerMuseum.org/
2:11 p.m.
New subject: "only 5 computers" [was RE: The value of assembler language programmers]
On 10 Feb 2010 at 13:54, Rich Alderson wrote:
The truth, as is so often the case, is more complex
than that.
According to the source cited above, what Watson reported to the 1953
stockholder's meeting was that their expectation with regard to sales
of the 701, when they visited 20 potential customers, was for 5
orders. Instead, they got 18.
And taken in its context (even allowing for the differing quote in
his autobiography), is a very different kettle of fish. Expectations
for 5 orders for a new "paper tiger" machine on a single sales junket
was quite optimistic for the time.
"The IBM Archives Frequently Asked Questions asks if he said in the
1950s that he foresaw a market potential for only five electronic
computers. The document says no, but quotes his son and then IBM
President Thomas J. Watson, Jr., at the annual IBM stockholders
meeting, April 28, 1953, as speaking about the IBM 701 Electronic
Data Processing Machine, which it identifies as "the company's first
production computer designed for scientific calculations". He said
that "IBM had developed a paper plan for such a machine and took this
paper plan across the country to some 20 concerns that we thought
could use such a machine. I would like to tell you that the machine
rents for between $12,000 and $18,000 a month, so it was not the type
of thing that could be sold from place to place. But, as a result of
our trip, on which we expected to get orders for five machines, we
came home with orders for 18." Watson, Jr., later gave a slightly
different version of the story in his autobiography, where he said
the initial market sampling indicated 11 firm takers and 10 more
prospective orders."
--Chuck
1:56 p.m.
New subject: The value of assembler language programmers [was RE: Algol vs Fortran was RE: VHDL vs Verilog]
On Wed, Feb 10, 2010 at 4:45 PM, Chuck Guzis <cclist at sydex.com> wrote:
On 10 Feb 2010 at 16:40, Dave McGuire wrote:
I'm pretty sure it was David Sarnoff of RCA, but I don't have any
scholarly references to back that up.
-ethan
? ?...or was it TJ Watson of IBM? ?I'm pretty
sure that was his quote.
It's often attributed to Watson, but the attributions are all from
the 1980s. ?There's no solid evidence that he ever said it.
2:01 p.m.
New subject: Watson vs. Sarnoff [RE: The value of assembler language programmers]
From: Ethan Dicks
Sent: Wednesday, February 10, 2010 1:56 PM
On Wed, Feb 10, 2010 at 4:45 PM, Chuck Guzis
<cclist at sydex.com> wrote:
> On 10 Feb 2010 at 16:40, Dave McGuire wrote:
>> ...or was it TJ Watson of IBM? I'm
pretty sure that was his quote.
> It's often attributed to Watson, but the
attributions are all from
> the 1980s. There's no solid evidence that he ever said it.
I'm pretty sure it was David Sarnoff of RCA, but I
don't have any
scholarly references to back that up.
Actually, before I checked a few minutes ago, I thought you were *both*
wrong, and that it was a UNIVAC market survey that gave that result.
That's what I was told about 40 years ago, anyway...
Rich Alderson
Vintage Computing Sr. Server Engineer
Vulcan, Inc.
505 5th Avenue S, Suite 900
Seattle, WA 98104
mailto:RichA at vulcan.com
mailto:RichA at LivingComputerMuseum.org
http://www.PDPplanet.org/
http://www.LivingComputerMuseum.org/
2:02 p.m.
New subject: The value of assembler language programmers [was RE: Algol vs Fortran was RE: VHDL vs Verilog]
On Wed, 10 Feb 2010, Ethan Dicks wrote:
On Wed, Feb 10, 2010 at 4:45 PM, Chuck Guzis
<cclist at sydex.com> wrote:
Well, the quote was about FIVE computers.
Could we attribute it to Watson, Olsen, and Sarnoff?
Who were the other two?
On 10 Feb 2010 at 16:40, Dave McGuire wrote:
I'm pretty
sure it was David Sarnoff of RCA, but I don't have any
scholarly references to back that up. ? ?...or was it TJ Watson of IBM? ?I'm pretty
sure that was his quote.
It's often attributed to Watson, but the attributions
are all from
the 1980s. ?There's no solid evidence that he ever said it.
2:28 p.m.
New subject: 5 computers quote / was Re: The value of assembler..
Fred Cisin wrote:
On Wed, 10 Feb 2010, Ethan Dicks wrote:
I too have mostly heard it attributed to Watson, years ago I had the impression
it was Howard Aiken, though that may be just my mistake - don't have a reference.
On Wed, Feb 10, 2010 at 4:45 PM, Chuck Guzis
<cclist at sydex.com> wrote:
Well, the quote was about FIVE computers.
Could we attribute it to Watson, Olsen, and Sarnoff?
Who were the other two? On 10 Feb 2010 at 16:40, Dave McGuire wrote:
I'm pretty
sure it was David Sarnoff of RCA, but I don't have any
scholarly references to back that up. ? ?...or was it TJ Watson of IBM? ?I'm pretty
sure that was his quote.
It's often attributed to Watson, but the attributions
are all from
the 1980s. ?There's no solid evidence that he ever said it. 
3:31 p.m.
New subject: 5 computers quote / was Re: The value of assembler..
I too have mostly heard it attributed to Watson, years ago I had the
impression
it was Howard Aiken, though that may be just my mistake - don't have a
reference.
http://en.wikipedia.org/wiki/Thomas_J._Watson#Famous_misquote
Marcin
5:02 p.m.
New subject: 5 computers quote / was Re: The value of assembler..
Marcin Wichary wrote:
No, I meant I have no reference to attribute it to Aiken, just a limpid memory
that I read it somewhere.
I too have mostly heard it attributed to Watson,
years ago I had the
impression
it was Howard Aiken, though that may be just my mistake - don't have a
reference.
http://en.wikipedia.org/wiki/Thomas_J._Watson#Famous_misquote
Marcin 
5:29 p.m.
New subject: logic analyzers
Hi
I'm trying to find information on the logic pods used
with the logic analyzer I just got.
It is a Nicolet 700 series that uses the Paratronics Pods.
It uses Model 51A and Model 80 probes.
Does anyone have these that I can look at or have
manuals/schematics for these?
Thanks
Dwight
_________________________________________________________________
Your E-mail and More On-the-Go. Get Windows Live Hotmail Free.
http://clk.atdmt.com/GBL/go/201469229/direct/01/
5:44 p.m.
New subject: logic analyzers
On 2/10/10 5:29 PM, dwight elvey wrote:
Hi
I'm trying to find information on the logic pods used
with the logic analyzer I just got.
It is a Nicolet 700 series that uses the Paratronics Pods.
It uses Model 51A and Model 80 probes.
Does anyone have these that I can look at or have
manuals/schematics for these?
Dig around Weird Stuff. I thought I saw some there within the
last year.
Is this the one that ran CP/M ?
5:46 p.m.
New subject: logic analyzers
On 2/10/10 5:29 PM, dwight elvey wrote:
Hi
I'm trying to find information on the logic pods used
with the logic analyzer I just got.
It is a Nicolet 700 series that uses the Paratronics Pods.
Just checked my scanning backlog, and I have manuals for the NPC-700
and NPC-764
They were nice analyzers. Used one for the first project I worked on
at Apple.
5:51 p.m.
New subject: logic analyzers
Hi Al
Weirdstuff is where I got the main unit ( actually a 748, diskless version ).
I got it at auction but didn't get any probes. Did you see probes and if
so, where would I look for such things?
I'd be interested in a copy of the manuals, especially if they
have schematic but even operation would be nice to have.
Yes, this is the box that had a CP/M based OS ( when used with the
disk models, like the 764 ).
Dwight
Date: Wed, 10 Feb 2010 17:46:05 -0800
From: aek at bitsavers.org
To:
Subject: Re: logic analyzers
On 2/10/10 5:29 PM, dwight elvey wrote:
_________________________________________________________________
Hotmail: Trusted email with powerful SPAM protection.
http://clk.atdmt.com/GBL/go/201469227/direct/01/
Hi
I'm trying to find information on the logic pods used
with the logic analyzer I just got.
It is a Nicolet 700 series that uses the Paratronics Pods.
Just checked my scanning backlog, and I have manuals for the NPC-700
and NPC-764
They were nice analyzers. Used one for the first project I worked on
at Apple.
6:23 p.m.
New subject: logic analyzers
On 10 Feb 2010 at 17:51, dwight elvey wrote:
Weirdstuff is where I got the main unit ( actually a
748, diskless
version ). I got it at auction but didn't get any probes. Did you see
probes and if so, where would I look for such things? I'd be interested
in a copy of the manuals, especially if they have schematic but even
operation would be nice to have. Yes, this is the box that had a CP/M
based OS ( when used with the disk models, like the 764 ).
Not to rain on your parade, but I've long been fascinated by the
numerous offerings for logic analyzers on eBay--all without pods--and
all advertised as "working".
I've wondered if there's an underground smuggling ring for those
things were they all end up in Paraguay. Or maybe the bottom of the
Sargasso Sea is carpeted with discarded logic analyzer pods...
--Chuck
7:49 p.m.
New subject: logic analyzers
If you find a set of 4 P6490 from tektronix, please remember you nice friend
here :oP
----- Original Message -----
From: "Chuck Guzis" <cclist at sydex.com>
To: "General Discussion: On-Topic and Off-Topic Posts"
<cctalk at classiccmp.org>
Sent: Thursday, February 11, 2010 12:23 AM
Subject: RE: logic analyzers
On 10 Feb 2010 at 17:51, dwight elvey wrote:
Weirdstuff is where I got the main unit (
actually a 748, diskless
version ). I got it at auction but didn't get any probes. Did you see
probes and if so, where would I look for such things? I'd be interested
in a copy of the manuals, especially if they have schematic but even
operation would be nice to have. Yes, this is the box that had a CP/M
based OS ( when used with the disk models, like the 764 ).
Not to rain on your parade, but I've long been fascinated by the
numerous offerings for logic analyzers on eBay--all without pods--and
all advertised as "working".
I've wondered if there's an underground smuggling ring for those
things were they all end up in Paraguay. Or maybe the bottom of the
Sargasso Sea is carpeted with discarded logic analyzer pods...
--Chuck
8:02 p.m.
New subject: logic analyzers
Hi Chuck
I think they are just the right size to fall into
some black hole someplace and poof, they're gone.
I didn't pay anything like ebay prices at least.
Dwight
From: cclist at sydex.com
To: cctalk at classiccmp.org
Date: Wed, 10 Feb 2010 18:23:39 -0800
Subject: RE: logic analyzers
On 10 Feb 2010 at 17:51, dwight elvey wrote:
_________________________________________________________________
Hotmail: Free, trusted and rich email service.
http://clk.atdmt.com/GBL/go/201469228/direct/01/
Weirdstuff is where I got the main unit (
actually a 748, diskless
version ). I got it at auction but didn't get any probes. Did you see
probes and if so, where would I look for such things? I'd be interested
in a copy of the manuals, especially if they have schematic but even
operation would be nice to have. Yes, this is the box that had a CP/M
based OS ( when used with the disk models, like the 764 ).
Not to rain on your parade, but I've long been fascinated by the
numerous offerings for logic analyzers on eBay--all without pods--and
all advertised as "working".
I've wondered if there's an underground smuggling ring for those
things were they all end up in Paraguay. Or maybe the bottom of the
Sargasso Sea is carpeted with discarded logic analyzer pods...
--Chuck
8:54 p.m.
New subject: logic analyzers
On Feb 10, 2010, at 9:23 PM, Chuck Guzis wrote:
Many scrappers have separate contracts for disposal of "wire".
Anything that even remotely resembles "wire" gets unceremoniously
thrown into a big bin and sold to the wire recyclers. Most logic
analyzer pods go there from the scrapper world. I've plucked quite a
few pods from quite a few gaylords over the years.
-Dave
--
Dave McGuire
Port Charlotte, FL
Weirdstuff is
where I got the main unit ( actually a 748, diskless
version ). I got it at auction but didn't get any probes. Did you see
probes and if so, where would I look for such things? I'd be
interested
in a copy of the manuals, especially if they have schematic but even
operation would be nice to have. Yes, this is the box that had a CP/M
based OS ( when used with the disk models, like the 764 ).
Not to rain on your parade, but I've long been fascinated by the
numerous offerings for logic analyzers on eBay--all without pods--and
all advertised as "working".
I've wondered if there's an underground smuggling ring for those
things were they all end up in Paraguay. Or maybe the bottom of the
Sargasso Sea is carpeted with discarded logic analyzer pods...
10 p.m.
New subject: logic analyzers
On 10 Feb 2010 at 23:54, Dave McGuire wrote:
Many scrappers have separate contracts for disposal
of "wire".
Anything that even remotely resembles "wire" gets unceremoniously
thrown into a big bin and sold to the wire recyclers. Most logic
analyzer pods go there from the scrapper world. I've plucked quite a
few pods from quite a few gaylords over the years.
If that's the case, I shudder to think how many 'scope probes have
wound up in the "wire" box.
But I can remember running across a pod-less HP logic analyzer back
when Haltek was in business. It was going for next to nothing, to be
fair.
--Chuck
11:14 p.m.
New subject: logic analyzers
On Feb 11, 2010, at 1:00 AM, Chuck Guzis wrote:
Lots and lots. I made quite a bit of money digging them out,
cleaning them up, testing them, and selling them in the late 1990s.
I'd get them for a buck a piece.
-Dave
--
Dave McGuire
Port Charlotte, FL
Many
scrappers have separate contracts for disposal of "wire".
Anything that even remotely resembles "wire" gets unceremoniously
thrown into a big bin and sold to the wire recyclers. Most logic
analyzer pods go there from the scrapper world. I've plucked quite a
few pods from quite a few gaylords over the years.
If that's the case, I shudder to think how many 'scope probes have
wound up in the "wire" box.
11 Feb
11 Feb
8:03 a.m.
New subject: shipping help
Hi
I'm looking for some help to ship an item
from Pasadena, Ca. It is a little heavy, about 45 lb.
I hope to bid on it but it is a pick-up only.
I could use some help from someone in the
Pasadena area.
( Its not a logic analyzer ).
Dwight
_________________________________________________________________
Hotmail: Trusted email with powerful SPAM protection.
http://clk.atdmt.com/GBL/go/201469227/direct/01/
10 Feb
10 Feb
9:53 p.m.
New subject: logic analyzers
A friend of mine and I worked for Arium, which are well represented on
ePay. If anyone is interested we have a pile of probably 20 analyzers,
which are probably not going to get used. I am in posession of a 16500C
and quite pleased with it, though the ML4400 can run faster with more
channels.
We do have the pods, and manuals. Would consider requests for any or
all of the pile. I talked to my buddy, and pretty much are willing to
let it go.
The pods would mostly be for the ML4400, though I think I have a working
4100 with one pod set.
Arium had started making a trace product which went under a Pentium and
the ML4400 with a third party (paratronics or such) made capture board
to capture the 133mhz bus. At the time it was clunky, but INtel
couldn't keep up with the bus w/o a "deathstar" HP 16xx or 16xxx setup
to capture all the pins which cost way up near $100k.
So they kept making the 4400's plus the trace unit, called a TRC54 for
quite a time longer after they made any standalone analyzers. And
almost none with the pods for the TRC54 / ML4400 combo.
So what you see are the ML4400 units with two capture cards and 200
channels of trace.
Note also with the ML4400, for what it's worth the actual loop from the
pod to the clip is also active with a mini coax and balanced resistor
network on both ends, so you have to have the ML4400, pod, and the lead
set (or make up the leads, I can get you the formula).
The roll of mini coax was snarfed by another employee for scrap, so you
are on your own finding that. It was quite expensive and hard to get,
and actually looks like the small 30 guage stranded lead wire, but
actually is coax.
Other useless data is that the drives are 720k drives if anyone wants
one that won't read 1.44 (there are a very few that had the 1.44mb
units, but for the most part are 720k standard).
Jim
On 2/10/2010 6:23 PM, Chuck Guzis wrote:
On 10 Feb 2010 at 17:51, dwight elvey wrote:
Weirdstuff is where I got the main unit (
actually a 748, diskless
version ). I got it at auction but didn't get any probes. Did you see
probes and if so, where would I look for such things? I'd be interested
in a copy of the manuals, especially if they have schematic but even
operation would be nice to have. Yes, this is the box that had a CP/M
based OS ( when used with the disk models, like the 764 ).
Not to rain on your parade, but I've long been fascinated by the
numerous offerings for logic analyzers on eBay--all without pods--and
all advertised as "working".
I've wondered if there's an underground smuggling ring for those
things were they all end up in Paraguay. Or maybe the bottom of the
Sargasso Sea is carpeted with discarded logic analyzer pods...
--Chuck
2:06 p.m.
New subject: The value of assembler language programmers [was RE: Algol vs Fortran was RE: VHDL vs Verilog]
On 10 Feb 2010 at 16:56, Ethan Dicks wrote:
I'm pretty sure it was David Sarnoff of RCA, but I
don't have any
scholarly references to back that up.
See:
http://en.wikipedia.org/wiki/Thomas_J._Watson
under "Famous Misquote".
I don't think that General Sarnoff would have recognized a computer
if it fell on him. His specialty was stealing IP.
--Chuck
4:02 p.m.
New subject: The value of assembler language programmers [was RE: Algol vs Fortran was RE: VHDL vs Verilog]
Remember David Sarnoff's comment, "I think
there is a world market for
maybe five computers"? Perhaps he was just prescient about the
Pro380. ;-)
Those would be fun to get. And probably more manageable than a real PDP-11.
--
------------------------------------ personal: http://www.cameronkaiser.com/ --
Cameron Kaiser * Floodgap Systems * www.floodgap.com * ckaiser at floodgap.com
-- You only live twice. -------------------------------------------------------
11 Feb
11 Feb
12:08 p.m.
New subject: The value of assembler language programmers [was RE: Algol vs
maybe five computers"? Perhaps he was just
prescient about the
Pro380. ;-)
-ethan
(Who has one. Are the other four owners already on this list?)
Well, I have Pro380 (and a pair of Pro350s)
-tony
9 Feb
9 Feb
9:59 p.m.
New subject: The value of assembler language programmers [was RE: Algol vs Fortran was RE: VHDL vs Verilog]
On 9 Feb 2010 at 18:54, e.stiebler wrote:
What we need is a J11/T11 chip again, so we can
program MACRO11 again
;-) (I know of the rumor, that the msp430 is loved by old pdp11 guys)
While I've played around with the MSP430 a bit, I can appreciate the
value of a Harvard architecture on a microcontroller when all one has
is a 16-bit addressing space.
Some AVRs are very nice in this respect--you can connect an external
SRAM that expands system RAM to 65K and still have your instruction
space.
--Chuck
10:11 p.m.
New subject: The value of assembler language programmers [was RE: Algol vs Fortran was RE: VHDL vs Verilog]
On Feb 10, 2010, at 12:59 AM, Chuck Guzis wrote:
Very nice indeed. mcs51 also enjoys that attribute.
-Dave
--
Dave McGuire
Port Charlotte, FL
What we need
is a J11/T11 chip again, so we can program MACRO11 again
;-) (I know of the rumor, that the msp430 is loved by old pdp11 guys)
While I've played around with the MSP430 a bit, I can appreciate the
value of a Harvard architecture on a microcontroller when all one has
is a 16-bit addressing space.
Some AVRs are very nice in this respect--you can connect an external
SRAM that expands system RAM to 65K and still have your instruction
space.
6:55 p.m.
New subject: The value of assembler language programmers [was RE: Algol vs Fortran was RE: VHDL vs Verilog]
While I've never programmed ARM in assembly, I've done quite a lot of
assembly-level debug of ARM software. I think it is easier to understand than PPC
assembly.
On Feb 9, 2010, at 7:48 PM, Dave McGuire wrote:
On Feb 9, 2010, at 8:24 PM, Chuck Guzis wrote:
In SOME places, yes. AVRs are an interesting anomaly: They're extremely powerful
processors with very low barriers to entry. Lots of beginners start out with AVRs.
(I'm NOT suggesting that AVRs are only for beginners!) Lots of beginners also seem to
think that nobody programs in assembler anymore.
Granted, far fewer do now than, say, thirty years ago, but lots do. One cannot replace
all programming with HLLs, no more than one can replace all programming with C# or Java.
ARMs are damn near impossible to program in assembler. That's why everyone uses C
in that world. Lots of [modern incarnation] Z80, Z8, 8051, and low-end PIC development is
done, both professionally and otherwise, in assembler today. Since those architectures
aren't changing, and it's mainly done that way because of the architectures, I
doubt it'll ever change. It certainly hasn't yet.
-Dave
--
Dave McGuire
Port Charlotte, FL
That's why I love to embedded stuff. And even here, any "reasonable"
Real Time OS of today, can't really boot with 48 kbytes of memory.
Been on the AVR forums much lately? It's getting more difficult to
find someone who writes in assembler. I suspect it's almost
impossible on the ARM uC area.
HLLs march on...
7:14 p.m.
New subject: The value of assembler language programmers [was RE: Algol vs Fortran was RE: VHDL vs Verilog]
On Feb 9, 2010, at 9:55 PM, Geoff Oltmans wrote:
--
Dave McGuire
Port Charlotte, FL
While I've never programmed ARM in assembly,
I've done quite a lot
of assembly-level debug of ARM software. I think it is easier to
understand than PPC assembly.
PPC is another one I won't go near. ;) Give me 8051 and msp430
any day!
-Dave
7:52 p.m.
New subject: The value of assembler language programmers [was RE: Algol vs Fortran was RE: VHDL vs Verilog]
While I've
never programmed ARM in assembly, I've done quite a lot
of assembly-level debug of ARM software. I think it is easier to
understand than PPC assembly.
PPC is another one I won't go near. ;)
8:26 p.m.
New subject: The value of assembler language programmers [was RE: Algol vs Fortran was RE: VHDL vs Verilog]
My favorite has to be loading a 32-bit value...
lis and then ori? lame!
On Feb 9, 2010, at 9:52 PM, Cameron Kaiser wrote:
PPC assembly is pretty hairy. I understand it enough to crack open a
debugger, but I've never written in it as the primary language.
Come to think of it, the only assembly I've done from the ground up has
been 6502, even though I know a few other instruction sets (some better than
others).
--
------------------------------------ personal: http://www.cameronkaiser.com/ --
Cameron Kaiser * Floodgap Systems * www.floodgap.com * ckaiser at floodgap.com
-- #include <std_disclaimer.h> ------------------------------------------------
While I've never programmed ARM in assembly,
I've done quite a lot
of assembly-level debug of ARM software. I think it is easier to
understand than PPC assembly.
PPC is another one I won't go near. ;)
8:07 p.m.
New subject: The value of assembler language programmers [was RE: Algol vs Fortran was RE: VHDL vs Verilog]
A big advantage of RISC is that the compiler can optimize code in some very serious,
low-level ways that just aren't possible with a CISC ISA. The granularity is simply
smaller, allowing a good compiler to hoist loads, anticipate latencies and in many
respects take into account the strengths and weaknesses of the individual processor. --
Ian
________________________________________
From: cctalk-bounces at classiccmp.org [cctalk-bounces at classiccmp.org] On Behalf Of
Dave McGuire [mcguire at neurotica.com]
Sent: Tuesday, February 09, 2010 5:48 PM
To: General Discussion: On-Topic and Off-Topic Posts
Subject: Re: The value of assembler language programmers [was RE: Algol vs Fortran
was RE: VHDL vs Verilog]
On Feb 9, 2010, at 8:24 PM, Chuck Guzis wrote:
In SOME places, yes. AVRs are an interesting anomaly: They're
extremely powerful processors with very low barriers to entry. Lots
of beginners start out with AVRs. (I'm NOT suggesting that AVRs are
only for beginners!) Lots of beginners also seem to think that
nobody programs in assembler anymore.
Granted, far fewer do now than, say, thirty years ago, but lots
do. One cannot replace all programming with HLLs, no more than one
can replace all programming with C# or Java.
ARMs are damn near impossible to program in assembler. That's why
everyone uses C in that world. Lots of [modern incarnation] Z80, Z8,
8051, and low-end PIC development is done, both professionally and
otherwise, in assembler today. Since those architectures aren't
changing, and it's mainly done that way because of the architectures,
I doubt it'll ever change. It certainly hasn't yet.
-Dave
--
Dave McGuire
Port Charlotte, FL
That's why
I love to embedded stuff. And even here, any "reasonable"
Real Time OS of today, can't really boot with 48 kbytes of memory.
Been on the AVR forums much lately? It's getting more difficult to
find someone who writes in assembler. I suspect it's almost
impossible on the ARM uC area.
HLLs march on...
5:41 p.m.
New subject: The value of assembler language programmers [was RE: Algol vs Fortran was RE: VHDL vs Verilog]
On Feb 9, 2010, at 8:13 PM, e.stiebler wrote:
That's one of the big reasons why I moved into the embedded world
too. Efficient programming is still valued in that world.
-Dave
--
Dave McGuire
Port Charlotte, FL
[ actually a
lot of good stuff] ;-)
25+ years later, how far have uber-fast machines with uber-large and
uber-cheap storage really gotten us? Not as far as the raw numbers
might lead one to think. I can buy a machine that about fits in my
pocket that has 500 times the memory, 500 times the storage, and
has a
clock that's nearly 500 times faster for 1/500th the cost* - a
250,000X price-performance advantage. I think quite a bit of that
500x multiplier is getting pissed away before I type a single
character. Yes it can do more; yes it feels faster. That much
faster? Not in my opinion.
That's why I love to embedded stuff. And even here, any
"reasonable" Real Time OS of today, can't really boot with 48
kbytes of memory.
Progress I guess ;-)
10 Feb
10 Feb
7:42 a.m.
New subject: The value of assembler language programmers [was RE: Algol vs Fortran was RE: VHDL vs Verilog]
e.stiebler wrote:
Ethan Dicks wrote:
OS/9 for the 6809 does alot, but not real time.I suspect a real time OS
would be in the same ball park. Graphics is the killer for any small
system and that is where I would check first.
[ actually a lot of good stuff] ;-)
25+ years later, how far have uber-fast machines with uber-large and
uber-cheap storage really gotten us? Not as far as the raw numbers
might lead one to think. I can buy a machine that about fits in my
pocket that has 500 times the memory, 500 times the storage, and has a
clock that's nearly 500 times faster for 1/500th the cost* - a
250,000X price-performance advantage. I think quite a bit of that
500x multiplier is getting pissed away before I type a single
character. Yes it can do more; yes it feels faster. That much
faster? Not in my opinion.
That's why I love to embedded stuff. And even here, any "reasonable"
Real Time OS of today, can't really boot with 48 kbytes of memory. Progress I guess ;-)
Yes. today in one chip you
can do what 5 chips of yesterday can
do with all pins left for I/O stuff.
9 Feb
9 Feb
8:08 p.m.
New subject: The value of assembler language programmers [was RE: Algol vs Fortran was RE: VHDL vs Verilog]
Ethan Dicks wrote:
On Tue, Feb 9, 2010 at 7:03 PM, Rich Alderson
<RichA at vulcan.com> wrote:
Yep. Assemblers vs Machine Code, not Assemblers vs High Level
Language Compilers.
I did say "the earliest days". Sorry for not assigning a year to that.
ICBW, but I think a lot of the bloat is caused by the
layer upon layer
upon layer upon layer of application interface code. My theory is that
all those layers arose because of inadequate or incompetent design in
the first place. Then too, I think we have a lot of "features" that are
rarely used and that we would be better off without, to say nothing of
all the changes for no apparent reason other than to just be different.
I also suspect that some of those spurious features are the root cause
of a lot of the security holes. Too, your "non-GUI" application is
probably actually running inside a system GUI which only emulates the
non-GUI user interface you think you're using. :-)
--- On
Tue, 2/9/10, Ethan Dicks <ethan.dicks at gmail.com> wrote:
I'm pretty sure that Ethan was talking about the attitudes in the
mid-1950s,
when assembler languages were born. Probably a lot. In the earliest days, assemblers
were considered a poor use
of time on the machine.
Assemblers were NOT considered poor use of machine time -
totally the
reverse. Assembler programmers had to know what they were doing though and
for that I was paid more. It took far less time to assemble a program in
BAL that compile a COBOL program. The down side was it took a lot longer
to write. He is correct that at the time, the use
of assembler languages was controversial, because so much precious computer
time was wasted doing something that any good programmer ought to be able to
do at his desk.
That is the attitude I was recalling.
*Every* generation of programmers has *always*
looked down on their successors
as using tools that waste too much computer time to do too little. Of course,
*my* generation (started programming in 1969 on a 1401) is right. ;-)
I certainly agree with you in principle, but I still wonder why even
non-GUI application bloat has to be as bad as it is. We used to put
25-40 users on an 8MB VAX before it would start to swap. Now, still
using a character based interface (which happens to be ssh vs direct
serial connect, but that doesn't affect CLI application size), a
program to tell me what processes are active on the system is 8MB by
itself, vs a few dozen K bytes (I should go back and dig out one of
those programs from the old days and port it to a modern machine to
compare library bloat vs application bloat. Fortunately, I have my
backups from 25 years ago).
This is C code then and C code now, 80x25 then and 80x25 now. UNIX
then and UNIX or Linux now. 32-bit processors then, 32-bit processors
now. Not quite apples to oranges like most comparisons reaching back
that far across the generations of equipment and mentalities.
25+ years later, how far have uber-fast machines with uber-large and
uber-cheap storage really gotten us? Not as far as the raw numbers
might lead one to think. I can buy a machine that about fits in my
pocket that has 500 times the memory, 500 times the storage, and has a
clock that's nearly 500 times faster for 1/500th the cost* - a
250,000X price-performance advantage. I think quite a bit of that
500x multiplier is getting pissed away before I type a single
character. Yes it can do more; yes it feels faster. That much
faster? Not in my opinion.
-ethan
* Numbers based on 1984 stats for a VAX-11/750 w/RA81 - approx $150K,
integer speed approx the same as 8MHz 68000, 8MB RAM, 450 MB of disk,
compared with a modern portable 3.6GHz machine w/4GB of RAM and 250GB
of disk for under $400. Some settling may have occurred in shipping.
Post No Bills, etc.
-ethan
------------------------------------------------------------------------
No virus found in this incoming message.
Checked by AVG - www.avg.com
Version: 9.0.733 / Virus Database: 271.1.1/2678 - Release Date: 02/09/10 13:35:00
10 Feb
10 Feb
3:15 p.m.
New subject: The value of assembler language programmers [was RE: Algol vs Fortran was RE: VHDL vs Verilog]
Ethan Dicks wrote:
This is C code then and C code now, 80x25 then and
80x25 now. UNIX
then and UNIX or Linux now. 32-bit processors then, 32-bit processors
now. Not quite apples to oranges like most comparisons reaching back
that far across the generations of equipment and mentalities.
Parkinson's Law at work.
It is interesting to compare UNIX device drivers for V6 or V7 or even
4.2BSD with NetBSD for VAX for the same devices. The difference is
striking. The V6 code does only what is absolutely necessary and nothing
more.
-ethan
-chuck
9 Feb
9 Feb
5:18 p.m.
New subject: Algol vs Fortran was RE: VHDL vs Verilog
On Tue, Feb 9, 2010 at 6:44 PM, Russ Bartlett <arcbe2001 at yahoo.com> wrote:
The comments are wide of the mark.? I started
programming in the 1960's.
As has already been mentioned, I was referring to a generation or two
_before_ you. *They* would have complained of your use of compilers
and assembers. By your era, that argument was long stale.
3) Anyone appreciating earlier data processing
challenges would also be aware that storage came at a price.? Also there was a limitation
as to what would fit onto a 80 column card (punched card).? Disc storage wasn't
cheap...
11 years ago, I pointed this very fact out to "journalists" who were
convinced that Y2K was all a scam to pad IT budgets because "nobody
would have gone to that much trouble to save 4 bits (00-99 fits in 7
bits, 2000 fits in 11 bits) even in the 1950s.
I pointed out that a) it was two characters, not 4 bits (BCD or EBCDIC
or later ASCII), and b) a metropolitan utility company that just kept
*only* two dates per customer would have millions of extra copies of
"19" to keep track of, load, process, store, print, save, etc., and c)
that one of the most easily exhausted resources was 80 columns on a
punch card. If you encode the due-date of a utility bill onto the
card for later processing, that's two columns less you have for
account number or other pertinent information (I don't recall what
punch-card bills specifically had on them - I only saw my parents pay
them). Even the extra reels of tape from millions of copies of "19"
will add up after a while.
and all this needed to be weighed against the belief
that a system written in 1965 would not be used by Y2K.
That's certainly true enough - who would have forecast that so much
code was still running in one form or another after so many decades?
Maybe someone would like to explain to my why my Quick
Books purchase in 1996 (C#) wasn't Y2K compliant.? I found a lot of the computer
article written prior to the Y2K switch laughable being written by people by people that
really hadn't a clue as to why the systems had been written that way in? the first
place.
It seems to me that any code written after 1980 _should_ have been
written with 4-digit dates, but not enough of it was. We Americans
were all too much in the habit of writing our dates as MM/DD/YY to get
"far off" things to change. I personally made the switch in my own
writing by the late 1980s, but I blame VMS and traveling in Europe for
that (when is 01/02/03, as if 02/04/88 isn't bad enough? It all
depends on where you are and where your audience is from.)
-ethan
6:14 p.m.
New subject: Algol vs Fortran was RE: VHDL vs Verilog
11 years ago, I pointed this very fact out to
"journalists" who were
convinced that Y2K was all a scam to pad IT budgets because "nobody
would have gone to that much trouble to save 4 bits (00-99 fits in 7
bits, 2000 fits in 11 bits) even in the 1950s.
While it was not a scam, it certainly was used to pad IT budgets.
We lost a great many old machines because of it.
I pointed out that ...
that one of the most easily exhausted resources was 80 columns on a
punch card. ?If you encode the due-date of a utility bill onto the
card for later processing, that's two columns less you have for
account number or other pertinent information (I don't recall what
punch-card bills specifically had on them
Just to nitpick - this would have been tiny. The unit record equipment
could have been wired up to prepunch the 19 if need be (it wasn't), so
the operators would still only have to key in the last two digits. And
tape was really, really cheap.
The problem was that disks turned from being used as temporary storage
to full, online storage - then those two character started costing big
bucks.
--
Will
10:25 p.m.
New subject: Y2K retrospective / was Re: Algol vs ...
William Donzelli wrote:
I would argue the public aspect of the issue was a scam.
The people who needed to know, knew already.
The public hype around the issue was overblown and unnecessary.
Remember the various experts and consultants railing about how microwave ovens
and cars and anything with a microprocessor in it (things that didn't even know
about the date) were going to fail?
I still have the bulletin from the government mailed out to every household in
Canada to prepare everyone for Y2K: a fine example of public folly.
11 years ago, I pointed this very fact out to
"journalists" who were
convinced that Y2K was all a scam to pad IT budgets because "nobody
would have gone to that much trouble to save 4 bits (00-99 fits in 7
bits, 2000 fits in 11 bits) even in the 1950s.
While it was not a scam, it certainly was used to pad IT budgets.
1:17 p.m.
New subject: Algol vs Fortran was RE: VHDL vs Verilog
On Feb 9, 2010, at 4:14 PM, geoffrey oltmans wrote:
I wonder how much programmers in the 50's and
60's argued about how
many CPU cycles this programming construct took vs. that. ;)
Well, there were what, six programming constructs at the time? ;)
-Dave
--
Dave McGuire
Port Charlotte, FL
2 p.m.
New subject: Algol vs Fortran was RE: VHDL vs Verilog
On 9 Feb 2010 at 13:14, geoffrey oltmans wrote:
I wonder how much programmers in the 50's and
60's argued about how
many CPU cycles this programming construct took vs. that. ;)
A lot--you also learned to spend your time where it mattered.
As a simple exercise, try writing a CDC 6600 loop to move a non-zero
number of word pairs (non-overlapped), such that you get one
instruction issue per cycle--and two words per loop traversal--and
keep the whole thing in the instruction "stack".
Similarly, a lot of time was spent figuring out bit-twiddling
shortcuts. Some were remarkably clever.
Heck, the code to save and restore all registers was pure cleverness.
It was a different world.
--Chuck
1:57 p.m.
New subject: Algol vs Fortran was RE: VHDL vs Verilog
It was thus said that the Great Josh Dersch once stated:
Dave McGuire wrote:
It's worse than that. Shared libraries also take their toll, at least,
for those systems that use the ELF format. The following article is rather
instructive for those not familiar with the dynamics of dynamic linking:
http://www.iecc.com/linker/linker10.html
So it's a tradeoff---dynamic libraries allow a smaller executable (the
executable for Firefox 3.5.7 on my system is only 57k, which surprised the
hell out of me, but then again, it loads about 42M of libraries) and less
memory usage overall (about 4M of shared libraries are used by other
processes) *and* allow a library to be fixed without relinking the entire
program, but at a cost of slower runtime (because shared libraries and
vtables use pretty much the same logic).
About the worst case I can see is a virtual call method into a shared
library, in the middle of a crital loop.
To mangle a quote: a few cycles here, a few cycles there, and pretty soon
you're talking real time.
And while I could load up RedHat 5.2 (last decent version of RedHat in my
opinion) on a modern machine (and yes, it would fly on today's hardware), I
would end up having to recompile X to use my video card, and I would have to
suffer Netscape 4, unless, of course, I wanted to try to compile Firefox. I
would also lose out on the C99 features of GCC (which I do use---C99 is a
nice progression), which means I would have to recompile GCC, etc. etc.
The other side of the coin is that the 2.6Gh machine sitting below my desk
can do things that my old system (a 150MHz 486 with 32M RAM) would die
trying to do. I can actually manipulate digital photos for one thing.
Another thing, I can solve jumbles *really fast*, burning through half a
million words in 0.18 seconds (heck, I have a version that does that in
0.006 seconds, but in order to to that, I use 15M of memory when running). I
could probably edit video on this box if I had the software to do so.
Couldn't even *conceive* of that on my Coco (which I love dearly).
Now, do I wish Firefox was faster? Heck, I'd take stability (it crashes
on a whim, but I have to use Firefox 3.5 for some of the stuff I do for
work) over speed, but ... yeah, speed would be nice.
Ah, anyway, enough rambling ...
-spc (http://prog21.dadgum.com/ makes for some interesting reading [1])
[1] http://prog21.dadgum.com/50.html
http://prog21.dadgum.com/45.html
http://prog21.dadgum.com/47.html
http://prog21.dadgum.com/29.html
But really, all the entries are good ...
On Feb 9, 2010, at 1:44 PM, Josh Dersch wrote:
Ok. Show me a processor that has an "object" data type, that has
subtypes like "member" and "method" and such. There aren't any.
Translating from such incredibly high-level constructs to registers,
stacks, and memory locations is not without a lot of overhead. Try to
envision what happens in the instruction stream during things like
virtual function lookups in C++, for example.
Ok, I'm envisioning it. A few instructions to do a vtable lookup and a
jump to the correct virtual function. Wow. So those extra instructions
are what's making every machine in the world (apparently) very very slow? 
3:03 p.m.
New subject: 80486 (was Algol vs Fortran was RE: VHDL vs Verilog)
-----Original Message-----
From: cctalk-bounces at classiccmp.org [mailto:cctalk-bounces at classiccmp.org]
On Behalf Of Sean Conner
Sent: Wednesday, 10 February 2010 8:58 AM
To: General Discussion: On-Topic and Off-Topic Posts
Subject: Re: Algol vs Fortran was RE: VHDL vs Verilog
The other side of the coin is that the 2.6Gh machine
sitting below my
desk
can do things that my old system (a 150MHz 486 with
32M RAM) would die
trying to do
Don't think 486's ever reached this speed. I know AMD released a 133MHz
version (the AM 5x86) and that 150MHz & 160MHz were planned but not (I
believe) ever released.
Cheers,
Lance Lyon
http://www.commodore128.org
3:26 p.m.
New subject: 80486 (was Algol vs Fortran was RE: VHDL vs Verilog)
It was thus said that the Great Lance Lyon once stated:
-----Original Message-----
From: cctalk-bounces at classiccmp.org [mailto:cctalk-bounces at classiccmp.org]
On Behalf Of Sean Conner
Sent: Wednesday, 10 February 2010 8:58 AM
To: General Discussion: On-Topic and Off-Topic Posts
Subject: Re: Algol vs Fortran was RE: VHDL vs Verilog
You're right---I had an AMD 5x86 chip in that box.
-spc (and I knew it was around 150MHz ... )
The other side of the coin is that the 2.6Gh
machine sitting below my
desk
can do things that my old system (a 150MHz 486
with 32M RAM) would die
trying to do
Don't think 486's ever reached this speed. I know AMD released a 133MHz
version (the AM 5x86) and that 150MHz & 160MHz were planned but not (I
believe) ever released.
11:19 a.m.
New subject: Algol vs Fortran was RE: VHDL vs Verilog
On 9 Feb 2010 at 13:00, Dave McGuire wrote:
Our processors have registers, ALUs, and memory
locations...not
objects. (iAPX432 notwithstanding) Constructs that don't map to
that paradigm are going to be inefficient, to a degree that
corresponds to how badly they match the paradigm. And objects don't
map to it at all.
How about GOTO-less CPUs? Do any exist that completely lack a jump
instruction of any sort (I'm not counting those where PC is mapped as
a general register)?
--Chuck
11:28 a.m.
New subject: Algol vs Fortran was RE: VHDL vs Verilog
Chuck Guzis wrote:
How about GOTO-less CPUs? Do any exist that
completely lack a jump
instruction of any sort (I'm not counting those where PC is mapped as
a general register)?
You must have a jump instruction for a loop.
Weird programing and computing... different topic.
--Chuck
12:55 p.m.
New subject: Algol vs Fortran was RE: VHDL vs Verilog
How about GOTO-less CPUs? Do any exist that
completely lack a jump
instruction of any sort (I'm not counting those where PC is mapped as
a general register)?
I assume you also don't count any processor where every instruction
includes the address of the next instruction. There is no explicit jump
instruction on such a mahcine, becuase every instruction includes a jump.
What about a Turing machine. I would claim that has no jump instruciton.
And of coruse (apart from the infinite memory), it's fairly easy to build
one in hardware.
-tony
1:06 p.m.
New subject: Algol vs Fortran was RE: VHDL vs Verilog
Tony Duell wrote:
That is the same as a STATE machine, we just call the states; ADDRESS n.
How about
GOTO-less CPUs? Do any exist that completely lack a jump
instruction of any sort (I'm not counting those where PC is mapped as
a general register)?
I assume you also don't count any processor where every instruction
includes the address of the next instruction. There is no explicit jump
instruction on such a mahcine, becuase every instruction includes a jump. What about a Turing machine. I would claim that has no
jump instruciton.
And of coruse (apart from the infinite memory), it's fairly easy to build
one in hardware.
I heard you can get a C? compiler for one too!
-tony
Ben. Who wants a better 12 bit machine
than the humble 8.
10 Feb
10 Feb
11:50 a.m.
New subject: Algol vs Fortran was RE: VHDL vs Verilog
I assume you
also don't count any processor where every instruction
includes the address of the next instruction. There is no explicit jump
instruction on such a mahcine, becuase every instruction includes a jump.
That is the same as a STATE machine, we just call the states; ADDRESS n.
9 Feb
9 Feb
1:21 p.m.
New subject: GOTO-less machines, was: Algol vs Fortran was RE: VHDL vs Verilog
On 9 Feb 2010 at 20:55, Tony Duell wrote:
What about a Turing machine. I would claim that has no
jump
instruciton. And of coruse (apart from the infinite memory), it's
fairly easy to build one in hardware.
Or Dataflow machines, for that matter. Would you count SKIP
instructions as GOTO? There has been more than one machine with
instruction execution depending on the setting of a condition code,
so that whole sequences could be skipped without a GOTO per se.
There's no real reason that a machine even needs to have every
location uniquely tagged by an address for that matter. Turing
machines are again a good example.
I could conceive of a machine with a WHILE-DO instruction pair, the
pairs obeying nesting rules.
Early paper-tape driven machines simply looped the tape to perform an
iterative instruction sequence.
--Chuck
1:24 p.m.
New subject: GOTO-less machines, was: Algol vs Fortran was RE: VHDL vs Verilog
On Feb 9, 2010, at 4:21 PM, Chuck Guzis wrote:
Would you count SKIP instructions as GOTO?
I would. It just has a fixed (relative) target address.
There has been more than one machine with
instruction execution depending on the setting of a condition code,
so that whole sequences could be skipped without a GOTO per se.
Indeed, look at ARM.
-Dave
--
Dave McGuire
Port Charlotte, FL
10 Feb
10 Feb
11:52 a.m.
New subject: GOTO-less machines, was: Algol vs Fortran was RE: VHDL vs Verilog
On Feb 9, 2010, at 4:21 PM, Chuck Guzis wrote:
In which case a machine which just steps through memory one location at a
time also has an implied goto in each instruction. With a relative
address of the next instruction, of course.
-tony
Would you count SKIP instructions as GOTO?
I would. It just has a fixed (relative) target address.
9 Feb
9 Feb
6:14 a.m.
New subject: Algol vs Fortran was RE: VHDL vs Verilog
On Tuesday 09 February 2010, Dave McGuire wrote:
On Feb 8, 2010, at 7:32 PM, N0body H0me wrote:
That's certainly an issue. I wonder how many applications are
slower and more overweight due to their being crafted with OOP than
they would be if they were coded using more traditional methods.
"More traditional methods"? Just "the way processors execute
code" would be a good start. Processors aren't object-oriented in
nature. This is one of the reasons why we have computers with multi-
GHz processors that barely get out of their own way. The constructs
commonly used in OO programming don't come anywhere close to mapping
to hardware efficiently.
But, isn't the point of programming languages to make it easier for the
programmer to create programs? Computers are fast; people are slow.
Have you ever tried writing code against GTK (not-quite-OOP jammed into
C) vs Qt (real OOP using C++)? GTK is such a pile of sh*t to try to
write code for, in my opinion.
Now, I'm not saying that I appreciate OOP in every case, but it seems to
be darn useful when writing GUI-based applications. Oh, and don't
forget that most of the code on running your favorite Mac was written in
Objective C...
Pat
--
Purdue University Research Computing --- http://www.rcac.purdue.edu/
The Computer Refuge --- http://computer-refuge.org
Here, here. The thing that impressed me about FORTRAN
(well, as
as science major, anyway) was that it could do complex numbers as
a *NATIVE* datatype!! Now, I know for you OOP and C++ guys,
custom, exotic datatypes are a dime a dozen. But in 1980, I was
sure glad I could do complex math without all of the extra
baggage that would have been necessary if I had to use, say,
BASIC-Plus.
Yeah, but how often do those C++ custom exotic datatypes map to
real datatypes supported by the hardware? (in other words, which
ones will actually be FAST?)
9:54 a.m.
New subject: Algol vs Fortran was RE: VHDL vs Verilog
On Feb 9, 2010, at 9:14 AM, Patrick Finnegan wrote:
"More traditional methods"? Just "the way processors execute
code" would be a good start. Processors aren't object-oriented in
nature. This is one of the reasons why we have computers with multi-
GHz processors that barely get out of their own way. The constructs
commonly used in OO programming don't come anywhere close to mapping
to hardware efficiently.
But, isn't the point of programming languages to make it easier for
the
programmer to create programs? Computers are fast; people are slow.
Yes of course, but it has gone WAY TOO FAR in the other direction.
There's been this crazy idea that saving EVEN FIVE MINUTES of
programmer time is worth ANY amount of processor time or ANY amount
of memory that you'd have to spend.
The mentality is similar to that surrounding today's school buses
(in the US anyway, don't know how they look elsewhere)...Increase
visibility at ANY cost, blindly pushing forward, completely ignoring
any other ramifications. Now we have school buses with WAY too many
blinking and flashing lights all over them that end up causing
distraction on the road, sometimes to the point of causing the
accidents that they're trying to prevent. And it just gets worse
every year.
I'm all for saving programmer time...I'm a programmer, and I'm
lazy too. But when a computer takes forever to grind through the
simplest of operations to enable me to "write the program" by
clicking and drooling for five minutes instead of actually doing a
little work, it has gone too far.
--
Dave McGuire
Port Charlotte, FL
> Here,
here. The thing that impressed me about FORTRAN (well, as
> as science major, anyway) was that it could do complex numbers as
> a *NATIVE* datatype!! Now, I know for you OOP and C++ guys,
> custom, exotic datatypes are a dime a dozen. But in 1980, I was
> sure glad I could do complex math without all of the extra
> baggage that would have been necessary if I had to use, say,
> BASIC-Plus.
Yeah, but how often do those C++ custom exotic datatypes map to
real datatypes supported by the hardware? (in other words, which
ones will actually be FAST?)
That's certainly an issue. I wonder how many applications are
slower and more overweight due to their being crafted with OOP than
they would be if they were coded using more traditional methods. Have you ever tried writing code against GTK
(not-quite-OOP jammed
into
C) vs Qt (real OOP using C++)? GTK is such a pile of sh*t to try to
write code for, in my opinion.
Yes I have, both. And yes, it's terrible. GTK is a steaming pile
of llama poop for a number of reasons. And they're both slower than
pissing tar.
Now, I'm not saying that I appreciate OOP in every
case, but it
seems to
be darn useful when writing GUI-based applications.
Useful in saving programmer time, yes. But look at the result! A
modern multi-GHz Linux box running GTK is far less "responsive"-
feeling than my old SPARCstation-IPX running fvwm when just tooling
around the GUI. A little more time spent by the programmers,
ignoring the "easy way out" or heavy OO programming and it'd be FAR
faster.
So, spend a little time now, ONCE, and make a million Linux boxes
twice as fast? That sounds like a good deal to me.
Yes I know GTK isn't written in an OO language, but I'm talking
about OO *techniques*...just like some programmers (I may be guilty
of this) can "write C in any language", some programmers seem to be
able to write C++ any any language.
Oh, and don't
forget that most of the code on running your favorite Mac was
written in
Objective C...
...which is something that I'm terribly annoyed with. It's fast,
but it should be a LOT faster, for the powerful processors it has.
-Dave
11:29 a.m.
New subject: Algol vs Fortran was RE: VHDL vs Verilog
On Tuesday 09 February 2010, Dave McGuire wrote:
On Feb 9, 2010, at 9:14 AM, Patrick Finnegan wrote:
Having written stuff for Qt, I have to disagree. KDE is different, and
is very heavy-weight, but I found Qt to be fairly light-weight and quick
when I used it by itself. Unless it has changed radically in the last
few years, I doubt it's bad compared to when I last used it a few years
ago.
Pat
--
Purdue University Research Computing --- http://www.rcac.purdue.edu/
The Computer Refuge --- http://computer-refuge.org
Have you ever tried writing code against GTK
(not-quite-OOP jammed
into
C) vs Qt (real OOP using C++)? GTK is such a pile of sh*t to try
to write code for, in my opinion.
Yes I have, both. And yes, it's terrible. GTK is a steaming pile
of llama poop for a number of reasons. And they're both slower than
pissing tar.
12:05 p.m.
New subject: Algol vs Fortran was RE: VHDL vs Verilog
On Feb 9, 2010, at 2:29 PM, Patrick Finnegan wrote:
Having written stuff for Qt, I have to disagree. KDE is different,
and
is very heavy-weight, but I found Qt to be fairly light-weight and
quick
when I used it by itself. Unless it has changed radically in the last
few years, I doubt it's bad compared to when I last used it a few
years
ago.
I've written stuff for Qt too. I liked it, but I found it to be
slow. Admittedly this was in the Qt2 days, 2002 or so?
But yes, I agree, KDE is a bloated pig.
-Dave
--
Dave McGuire
Port Charlotte, FL
Have you ever tried writing code against GTK
(not-quite-OOP jammed
into
C) vs Qt (real OOP using C++)? GTK is such a pile of sh*t to try
to write code for, in my opinion.
Yes I have, both. And yes, it's terrible. GTK is a steaming pile
of llama poop for a number of reasons. And they're both slower than
pissing tar.
10 Feb
10 Feb
8:54 a.m.
New subject: Algol vs Fortran was RE: VHDL vs Verilog
Dave McGuire wrote:
Useful in saving programmer time, yes. But look at the result! A
modern multi-GHz Linux box running GTK is far less
"responsive"-feeling than my old SPARCstation-IPX running fvwm when
just tooling around the GUI. A little more time spent by the
programmers, ignoring the "easy way out" or heavy OO programming and
it'd be FAR faster.
There's always lighter things like LXDE or XFCE.
So, spend a little time now, ONCE, and make a million Linux boxes
twice as fast? That sounds like a good deal to me.
Indeed 5 minutes saved of
programmer time = thousands of hours (or for
popular apps millions) wasted by end users.
Yes I know GTK isn't written in an OO language, but I'm talking
about OO *techniques*...just like some programmers (I may be guilty of
this) can "write C in any language", some programmers seem to be able
to write C++ any any language.
It's not the OOP stuff, it's the
architecture astronaut ideal of
layering meaningless abstractions on top of meaningless abstractions.
It's turtles all the way down. :-)
It was always PREMATURE optimization that was evil, not optimization.
Yet, they plow on like all optimization is evil.
Some of the stuff amazes me. We now have an app at $WORK that's an in
memory XML db - the data in memory is just a plain XML file as far as we
can tell - not tokenized and structured. Our db is ~100GB in size and
growing. Worse yet, this db "engine" is not multithreaded. Also, it
takes about an hour to save or load the db from/to disk. Of course this
is on a clustered system for high availability. But it takes more than
an hour to do a failover.
The previous version required you to load X copies of the db in memory
if you wanted to do X things with it at once! So a 384GB - yes GB
machine with 32 AMD 2GHz cores just isn't enough for this thing.
They've fixed this a bit, but nowhere near what it should be.
Like all poorly written apps, this one crashes occasionally. Care to
guess what happens to the poor file system when it tries to write a
300GB core file to disk that's far smaller? :-(
This is just pure insanity. Just 25 years ago, I remember fighting to
save every byte of a 5K program, and now we have this insanity.
GTK has NOTHING on this evil thing. Be happy if GTK's your only gripe. :-)
3:30 p.m.
New subject: Poor programming (was Re: Algol vs Fortran)
----- Original Message -----
From: "Ray Arachelian" <ray at arachelian.com>
To: "General Discussion: On-Topic and Off-Topic Posts"
<cctalk at classiccmp.org>
Sent: Wednesday, February 10, 2010 4:54 PM
Subject: Re: Algol vs Fortran was RE: VHDL vs Verilog
Some of the stuff amazes me. We now have an app at $WORK that's an in
memory XML db - the data in memory is just a plain XML file as far as we
can tell - not tokenized and structured. Our db is ~100GB in size and
growing. Worse yet, this db "engine" is not multithreaded. Also, it
takes about an hour to save or load the db from/to disk. Of course this
is on a clustered system for high availability. But it takes more than
an hour to do a failover.
The previous version required you to load X copies of the db in memory
if you wanted to do X things with it at once! So a 384GB - yes GB
machine with 32 AMD 2GHz cores just isn't enough for this thing.
They've fixed this a bit, but nowhere near what it should be.
Like all poorly written apps, this one crashes occasionally. Care to
guess what happens to the poor file system when it tries to write a
300GB core file to disk that's far smaller? :-(
That is shocking. I may not be writing professional programs (thank god, no
time limits or other pressures), but when I do write software (usually for
the Amiga) I always include error checks. When attempting to save a file to
disk, I always check to make sure that there is enough space on the target
device for the file.
I had Windows Media Player crash on me the other week and jammed CPU usage
at 100% :( Not great on my laptop, as the only way to shut it down is to
pull the plug out of the mains and then pull out the battery (timed
carefully - thank god for the HD access light!). It was just as it was about
to reload in the music file (something else I hate - why re-load in the
music file you were just playing, especially when it's not a large file
(<5MB)?!!) after reaching the end when the problem occured.
I had selected the file to play in a slightly different way to normal, so
thankfully I can avoid that problem again quite easily :)
I'm certainly no expert at programming (good at BASIC and beginner at 68K
ASM), but if you don't sort out the easy bugs (or put in safety nets) how on
earth can you expect to catch the hard-to-find ones?!
Regards,
Andrew B
aliensrcooluk at yahoo.co.uk
11 Feb
11 Feb
8:46 a.m.
New subject: Poor programming (was Re: Algol vs Fortran)
Its simple economics, really.
There is a huge demand for the creation and modification of software.
There is a short supply of top-calibre coders that create and modify software.
Ergo, most of the creation and modification of software is by a lesser
calibre of programmer.
Instead of just bemoaning the situation, I personally spend quite a
bit of time trying to educate my fellow programmers on better and best
practices. Almost all of it is done for free.
--
"The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download
<http://legalizeadulthood.wordpress.com/the-direct3d-graphics-pipeline/>
Legalize Adulthood! <http://legalizeadulthood.wordpress.com>
10:41 a.m.
New subject: Poor programming (was Re: Algol vs Fortran)
Andrew Burton wrote:
That is shocking. I may not be writing professional
programs (thank god, no
time limits or other pressures), but when I do write software (usually for
the Amiga) I always include error checks. When attempting to save a file to
disk, I always check to make sure that there is enough space on the target
device for the file.
Oh I'm sure they've got error checks, but those don't help when
their
design was written by monkeys.
Ok, I can understand you'd want an in memory db, but why not tokenize
the XML, why not store the XML as a tree.
Why not make it so it has proper multithreading, and why not set it up
so you don't actually read and write the data from disk into memory and
instead use mmap to let the OS do that work for you?
I had Windows Media Player crash on me the other week
and jammed CPU usage
at 100% :( Not great on my laptop, as the only way to shut it down is to
pull the plug out of the mains and then pull out the battery (timed
carefully - thank god for the HD access light!).
Ouch. Well, that's not
exactly well written software either. I get by
with Miro or VLC for video and Songbird, which I also use as a browser
since it's built ontop of the same engine as Firefox and can use most of
Firefox's plugins. Much nicer than itunes or anything else I've used
recently, though it takes some work to get it to be as nice as firefox.
Running this on OS X or Linux is a godsend over that other thing from
Redmond that they claim is an operating system. I've not been able to
make any app crash the OS so far in that manner, but that's just me. :-)
It was just as it was about
to reload in the music file (something else I hate - why re-load in the
music file you were just playing, especially when it's not a large file
(<5MB)?!!) after reaching the end when the problem occured.
Well, I do like the ability for the apps I use to restore themselves to
the same state they were in before I quit them - saving context is a
good thing. Obviously if you had just crashed you should detect that
the app wasn't closed cleanly and give the user some options. If you've
seen the Session Manager plugin to Firefox, IMHO, the way to do right by
the user.
I'm certainly no expert at programming (good at
BASIC and beginner at 68K
ASM), but if you don't sort out the easy bugs (or put in safety nets) how on
earth can you expect to catch the hard-to-find ones?!
Most of this stuff is driven by marketing, and having it just barely
good enough to get it out the door, damn the users, meet the deadline no
matter what. And it shows.
The new hw is wonderful, very fast, loads of storage, loads of memory.
Sadly code monkeys barely out of high school abuse it by writing buggy
bloatware.
10:54 a.m.
New subject: Poor programming (was Re: Algol vs Fortran)
Ray Arachelian wrote:
The new hw is wonderful, very fast, loads of storage,
loads of memory.
Sadly code monkeys barely out of high school abuse it by writing buggy
bloatware.
Well I am doing the same thing with hardware, for the CPLD computer
design I playing with. Keep on adding features until the compiler
crashes and the keep all the features before that one. :)
How ever since is for my personal use, I don't need all the features,
but it sure is hard to tell if a complex design will route.
Ben.
11:09 a.m.
New subject: Poor programming (was Re: Algol vs Fortran)
Ben wrote:
Ray Arachelian wrote:
Presumably you've not written an in memory db that's single threaded
that requires 100GB of RAM, and claims to be a commercially available
application, sold for who knows how many hundreds of thousands of dollars.
Nothing wrong with adding features as long as you use the right data
structures and algorithms to implement them.
Yeah, ok, for sorting an array of 10-20 values, bubble sort is ok, but
when that grows to several hundred items, that no longer works. As an
example. :-)
The new hw is wonderful, very fast, loads of
storage, loads of memory.
Sadly code monkeys barely out of high school abuse it by writing buggy
bloatware.
Well I am doing the same thing with hardware, for the CPLD computer
design I playing with. Keep on adding features until the compiler
crashes and the keep all the features before that one. :)
How ever since is for my personal use, I don't need all the features,
but it sure is hard to tell if a complex design will route.
11:25 a.m.
New subject: Poor programming (was Re: Algol vs Fortran)
Ben wrote:
Ray Arachelian wrote:
Programmer : We didn't test it yet !
Managment : We just send patches next Tuesday !
Yeah, ok, for sorting an array of 10-20 values,
bubble sort is ok, but
when that grows to several hundred items, that no longer works. As an
example. :-)
Management: "We need it yesterday!"
12:14 p.m.
New subject: Poor programming (was Re: Algol vs Fortran)
-----Original Message-----
From: cctalk-bounces at classiccmp.org [mailto:cctalk-
bounces at classiccmp.org] On Behalf Of Ben
Sent: Thursday, February 11, 2010 11:20 AM
To: On-Topic and Off-Topic Posts
Subject: Re: Poor programming (was Re: Algol vs Fortran)
Ray Arachelian wrote:
Marketing: "And it needs to come in blue."
Yeah, ok, for sorting an array of 10-20 values,
bubble sort is ok,
but
when that grows to several hundred items, that no
longer works. As
an
example. :-)
Management: "We need it yesterday!"
12 Feb
12 Feb
6:28 a.m.
New subject: Poor programming (was Re: Algol vs Fortran)
----- Original Message -----
From: "Ray Arachelian" <ray at arachelian.com>
To: "General Discussion: On-Topic and Off-Topic Posts"
<cctalk at classiccmp.org>
Sent: Thursday, February 11, 2010 6:41 PM
Subject: Re: Poor programming (was Re: Algol vs Fortran)
Yes, I quite agree with you on that. When Firefox crashes (usually because
of a flash plug-in) I love the fact that it gives you the option to restore
it's status.
However, the point I was making with WMP was that it reloads the music file
each time it reaches playing the end of it. I can understand re-loading it
in if WMP was shut down, crashed or not used for a long time, but to re-load
in the music file before each time it is played is ludicrous. For example,
if I were to play a 1 minute long song for 1 hour, it would load it in an
additional 59 times after opening WMP and loading in the song.
Regards,
Andrew B
aliensrcooluk at yahoo.co.uk
> I had Windows Media Player crash on me the other week and jammed CPU
usage
> at 100% :( Not great on my laptop, as the only
way to shut it down is
to
pull the plug
out of the mains and then pull out the battery (timed
carefully - thank god for the HD access light!).
Ouch. Well, that's not
exactly well written software either. I get by
with Miro or VLC for video and Songbird, which I also use as a browser
since it's built ontop of the same engine as Firefox and can use most of
Firefox's plugins. Much nicer than itunes or anything else I've used
recently, though it takes some work to get it to be as nice as firefox.
Running this on OS X or Linux is a godsend over that other thing from
Redmond that they claim is an operating system. I've not been able to
make any app crash the OS so far in that manner, but that's just me. :-)
It was just as it was about
to reload in the music file (something else I hate - why re-load in the
music file you were just playing, especially when it's not a large file
(<5MB)?!!) after reaching the end when the problem occured.
Well, I do like the ability for the apps I use to restore themselves to
the same state they were in before I quit them - saving context is a
good thing. Obviously if you had just crashed you should detect that
the app wasn't closed cleanly and give the user some options. If you've
seen the Session Manager plugin to Firefox, IMHO, the way to do right by
the user.
2:27 p.m.
New subject: Poor programming (was Re: Algol vs Fortran)
In article <00c801caac1c$26a88300$5216610a at user8459cef6fa>,
"Andrew Burton" <aliensrcooluk at yahoo.co.uk> writes:
Yes, I quite agree with you on that. When Firefox
crashes (usually because
of a flash plug-in) I love the fact that it gives you the option to restore
it's status.
IE8 does the same.
--
"The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download
<http://legalizeadulthood.wordpress.com/the-direct3d-graphics-pipeline/>
Legalize Adulthood! <http://legalizeadulthood.wordpress.com>
10 Feb
10 Feb
5:49 a.m.
New subject: Algol vs Fortran was RE: VHDL vs Verilog
Patrick Finnegan wrote:
But, isn't the point of programming languages to
make it easier for the
programmer to create programs? Computers are fast; people are slow.
I'd agree with that.
Have you ever tried writing code against GTK
(not-quite-OOP jammed into
C) vs Qt (real OOP using C++)? GTK is such a pile of sh*t to try to
write code for, in my opinion.
Try the Windows API some time. That's even more fun.
I've been using wxWidgets for a while -- mainly because it abstracts all
this bullcrap into a common interface. You can change platforms and the
code remains the same -- normal apps will work fine on
GTK+{$UNIX_FLAVOUR}, Windows 32/64-bit using the native API, and Mac OS X.
Even applications that make use of hardware can be made portable across
all three platforms -- LibUSB runs native on OSX and Linux, and there's
a port for Windows too.
Creating, say, a window is a piece of cake -- extend the wxFrame class,
add your components to the constructor (stuff like "myTextBox = new
wxTextBox(this)"), and add event handler functions to deal with what the
user does.
The one thing I haven't found yet is an equivalent for Delphi's
"Application.ProcessMessages()" function -- which basically forces the
VCL to run the event handler / window refresh loop again. Very handy in
long do-while or for-next loops. It's probably there, though -- just
that I haven't RTFM'd enough to find it in the wxWidgets manual.
--
Phil.
classiccmp at philpem.me.uk
http://www.philpem.me.uk/
11 Feb
11 Feb
10:24 a.m.
New subject: Algol vs Fortran was RE: VHDL vs Verilog
Philip Pemberton wrote:
Creating, say, a window is a piece of cake -- extend
the wxFrame
class, add your components to the constructor (stuff like "myTextBox =
new wxTextBox(this)"), and add event handler functions to deal with
what the user does.
<Way OT rant>
The thing that's currently pissing me off about wx is that the newer
ones lack the rawbits interface - at least on OS X 10.6 - and some on
Linux as well.
Well, that and the fact that you can't blit an image to a DC, you have
to first convert it to a bitmap.
wxBitmap can be manipulated with rawbitmap.h - only it's not available
where I need it.
wxImage can be manipulated with the SETRGB macro , but you need to
convert it to a bitmap before you can Blit it, and doing so is insanely,
unbearably slow on OS X.
Oh sure, there are other methods of playing with wxImages, but they're
even slower (using pens, drawing lines, etc.)
Worse yet, on OS X 10.6 with wxCocoa, if I use wxImage with SETRGB and
then convert the image to a bitmap and blit the bitmap, I'm get weird
banding artifacts when using the gray 50% desktop pattern (you know,
alternating lines of 0x55 and 0xaa patterns black & white), but not on
the older OS X 10.5's. It's making it very hard to get a 64 bit version
of LisaEm.
That and playing sounds is fugly - you have to pass it a .wav file, so I
had to resort to creating a temporary .wav file on the fly and telling
it to play that. Oh sure, on SOME platforms passing raw data works, but
not everywhere.
Rest of the stuff is wonderful.
:-)
</WAY OT>
8 Feb
8 Feb
3:15 p.m.
New subject: Algol vs Fortran was RE: VHDL vs Verilog
Chuck Guzis wrote:
On 8 Feb 2010 at 18:42, Andy Holt wrote:
Humm, tell that to the Delphi programmers.....as Delphi is basically
Pascal with some extra beslls.
Ok I agree probably not as widely used as C, but still pretty popular as
far as I can tell.
And yeah I'm biased as I do do a lot of my code in Delphi/Pascal though
I also do a fair amount of C too, each has it's strengths and weeknesses
but something I learnt a long time ago is there's no one tool for every
situation.
Besides if we are talking about lines of code written I'd have to say
that probably COBOL would beat even C......
Cheers,
Phill.
--
Phill Harvey-Smith, Programmer, Hardware hacker, and general eccentric !
"You can twist perceptions, but reality won't budge" -- Rush.
I remember the Algol-FORTRAN cross-pond war of
the 60s and 70s. :)
Now I wonder, "who won?" :)
The easy answer is "C" :-)
The curious thing is that the "structured" languages of the 70s
(Pascal and Modula-2) seem to have regressed to minority languages. 
9 Feb
9 Feb
1:52 a.m.
New subject: Algol vs Fortran was RE: VHDL vs Verilog
But has to really work at it to do so in a functional
language :-)
[perhaps why I stick to imperative languages]
PostScript I like do Postscript let's so
[sorry, grammar was lost somewhere on the way to stack programming]
--
http://www.hachti.de
11:59 a.m.
New subject: Algol vs Fortran was RE: VHDL vs Verilog
"A REAL programmer can write a FORTRAN program in
any language."
A Real Programmer can write assembler in any language :-). I am not a
Real Programmer, but I once translated a short 6502 assembly language
routine into Pascal, with procedures called 'ADC' and the like. The
reason was I was trying to figurte out the checksum routine in a
Commodore printer ROM -- I wanted to modify the ROM so the printer would
take ASCII rather htan PETSCII. Yes, I did do it.
-tony
8 Feb
8 Feb
2:25 p.m.
New subject: Algol vs Fortran was RE: VHDL vs Verilog
Part of Primos O/S was written in FORTRAN as well their Prime Information ? (Pick like
DBMS on Prime) Databasic.? Also? earlier DEC Dibol language.? On the other hand Algol was
extensively used on the Burroughs as was central to its architecture (no assembler).?
Burroughs had a highly advanced stack type architecture.
Having used both - Algol!?? Algol people viewed Fortran people pretty much the same way
COBOL guys viewed RPG people.?
--- On Mon, 2/8/10, Andy Holt <andyh at andyh-rayleigh.freeserve.co.uk> wrote:
From: Andy Holt <andyh at andyh-rayleigh.freeserve.co.uk>
Subject: Algol vs FORTRAN was RE: VHDL vs Verilog
To: "'General Discussion: On-Topic and Off-Topic Posts'" <cctalk at
classiccmp.org>
Date: Monday, February 8, 2010, 1:42 PM
>>>
I remember the Algol-FORTRAN
cross-pond war of the 60s and 70s.? :)
?
Now I wonder, "who won?"? :)
<<<<
The easy answer is "C" :-)
You can look at it at least two ways:
* C has the structure of Algol with most of the dirty tricks and efficiency
of FORTRAN.
* C derives from multiple paths -
???One of these ia PL/I (which derives from Fortran, Algol, and COBOL)
???Another is from B which comes from BCPL which comes from CPL which was
essentially an extended Algol
However it seems that the saying: "I don't know what language engineers will
use in the future, but I know they'll call it Fortran." has mostly
turned-out mistaken.
Andy
3:15 p.m.
New subject: Algol vs Fortran was RE: VHDL vs Verilog
On 8 Feb 2010 at 14:25, Russ Bartlett wrote:
Having used both - Algol!?? Algol people viewed
Fortran people pretty
much the same way COBOL guys viewed RPG people.?
The curious thing is that the "portmanteu" languages, such as PL/I
(FORTRAN, COBOL, Algol) or Ada inevitably seem to be less popular
than the languages they were intended to supercede.
--Chuck
5:39 p.m.
New subject: Algol vs Fortran was RE: VHDL vs Verilog
A lot of the earlier application software was written in FORTRAN.? I first used it on an
IBM 1620, and 1130.?? FORTRAN had the weight of IBM behind it.? I'd say Algol was far
more influential on the design of other languages and for that reason I think it was a
better language.? Algol's I/O sucked though. ?? As I recall the Elliot 803 had an
Algol compiler.??? IBM had a lot sway on the market; FORTRAN, PL/I and RPG.??
--- On Mon, 2/8/10, Chuck Guzis <cclist at sydex.com> wrote:
From: Chuck Guzis <cclist at sydex.com>
Subject: Re: Algol vs Fortran was RE: VHDL vs Verilog
To: "General Discussion: On-Topic and Off-Topic Posts" <cctalk at
classiccmp.org>
Date: Monday, February 8, 2010, 6:15 PM
On 8 Feb 2010 at 14:25, Russ Bartlett wrote:
Having used both - Algol!?? Algol people viewed
Fortran people pretty
much the same way COBOL guys viewed RPG people.?
The curious thing is that the "portmanteu" languages, such as PL/I
(FORTRAN, COBOL, Algol) or Ada inevitably seem to be less popular
than the languages they were intended to supercede.
--Chuck
1:23 p.m.
New subject: VHDL vs Verilog
Chuck Guzis wrote:
On 8 Feb 2010 at 7:28, Jos Dreesen wrote:
I say fortran ... They have compilers for it! :)
I think they have the same problem with the very high level
languages: NO IN/OUT.
Ben.
VHDL vs Verilog is another holy war, and about as
useful as a 6502 vs
Z80 discussion. Thus I continue : Personally I pity those who never
get into VHDL and stay with Verilog, and I will choose VHDL over
Verilog any day. Oh the agony when forced to use a Verilog testbench
from our US collegues.....
I remember the Algol-FORTRAN cross-pond war of the 60s and 70s. :)
Now I wonder, "who won?" :)
--Chuck
11:50 a.m.
New subject: VHDL vs Verilog
Personally I pity those who never get into VHDL and
stay with Verilog,
and I will choose VHDL over Verilog any day.
Agree :-)
Oh the agony when forced to use a Verilog testbench
from our US
collegues.....
Oh, let's do it in SystemC - that cures every pain!
Philipp :-)
11:44 a.m.
New subject: cpld design
Oh!
VHDL is the ADA of EDA languages--almost no one ever
uses it because
they *want* to.
I adore it!
I find Verilog quite crappy. And it doesn't tell me when I misspell a signal. Ok,
perhaps a little
compiler warning - but that's all.
With VHDL I have a quite better chance to get a running design if it passes the
compiler...!
I like Verilog very much; it's straightforward
and
not too "dirty".
IMHO it *IS* dirty. VERY dirty.
Philipp .-)
--
http://www.hachti.de
1:08 p.m.
New subject: cpld design
On Feb 8, 2010, at 4:03 PM, Chuck Guzis wrote:
I've written ALGOL code. It is FAR more elegant than VHDL. ;)
-Dave
--
Dave McGuire
Port Charlotte, FL
I adore it!
Your first programmig language was probably Algol. :) (or Pascal or
Modula-2, depending upon your vintage).
1:38 p.m.
New subject: cpld design
I adore it!
Your first programmig language was probably Algol. :) (or Pascal or
Modula-2, depending upon your vintage).
9 Feb
9 Feb
1:43 a.m.
New subject: cpld design
Hm....!
My vintage is 1978.... So... Ok, you're
probably right with Pascal for me. But to be 100% correct:
Omicron Basic on Atari ST, then GfA-Basic. Then Microsoft QBasic on my 286 notebook. Turbo
Pascal
(and traces of Delphi) followed.
Learned OOP and Java at University (using commandline javac and editing with Emacs).
First C in autumn of 2000 as I remember.
:-)
VHDL in conjunction with the XEmacs VHDL mode is unbeatable!
Regards,
Philipp
--
http://www.hachti.de
I adore it!
Your first programmig language was probably Algol. :) (or Pascal or
Modula-2, depending upon your vintage).
7 Feb
7 Feb
5:45 p.m.
New subject: cpld design
On 08/02/2010 00:31, Philip Pemberton wrote:
Ben wrote:
> I am using 128 cell CPLD's, from Atmel with CPUL (wincpul) for
> logic design. This language is at the gate level, but easy to use
> compared to the other two design languages.
While we're on the subject of Atmel's WinCUPL, is it just me or is it
pretty buggy and crash prone...especially if you try and simulate your
design. I do occasionally use it for programming the Atmel PALs.
Cheers.
Phill.
6:44 p.m.
New subject: cpld design
Phill Harvey-Smith wrote:
On 08/02/2010 00:31, Philip Pemberton wrote:
Simulate... What is that!
I tend to find the IDE and compiler buggy. That is why I edit
the source with EDIT and just compile it. I plan not to have
complex logic, so I don't simulate stuff. Most of the time the
logic fits ( or works ) or back to the drawing board.
Ben wrote:
> I am using 128 cell CPLD's, from Atmel with CPUL (wincpul) for
> logic design. This language is at the gate level, but easy to use
> compared to the other two design languages.
While we're on the subject of Atmel's WinCUPL, is it just me or is it
pretty buggy and crash prone...especially if you try and simulate your
design. I do occasionally use it for programming the Atmel PALs. Cheers.
Phill.
Ben.
7:04 p.m.
New subject: cpld design
On Feb 7, 2010, at 7:31 PM, Philip Pemberton wrote:
I still use PALASM for PAL/GAL work. I find it to be very simple
and straightforward.
-Dave
--
Dave McGuire
Port Charlotte, FL
Interesting. I find Verilog easier to use than CUPL.
Certainly for
register-based logic it makes the function of the code a bit more
obvious; for combinational logic it really doesn't matter (although
Verilog uses C-style expressions and thus might be a little easier
for your average software geek to understand... ahem :P )
VHDL on the other hand is evil, distilled into its purest form. In
my experience, what can be said in half a dozen lines of Verilog
takes 30 or so in VHDL. CUPL seems to sit somewhere in the middle.
I was forced to learn to read VHDL at a previous job (some idiot
lost the register documentation for a glue-logic PLD, I got to
rewrite it from source). That experience and one or two like it
have put me off VHDL for life!
I agree on both VHDL and Verilog. My HDL experience is very
limited, but I've looked at both, and immediately wondered why VHDL
still exists.
I do, however, still use CUPL on occasion for creating
fusemaps for
GALs... I think I've still got half a tube of DIL-packaged Lattice
GAL16V8s in my spares bin...
7:57 p.m.
On Feb 7, 2010, at 5:57 PM, KeithM wrote:
I'm in the process of using the FPGA, but
haven't touched the
CPLD. I barely know how to spell it. :)
FPGAs are more flexible, but I found CPLDs easier to get started
with. That's likely because I had done PAL design before, and CPLDs
(at least the Xilinx ones, dunno about others) implement a very
similar architecture.
-Dave
--
Dave McGuire
Port Charlotte, FL
7:56 p.m.
On Feb 7, 2010, at 5:36 PM, Ben wrote:
See: CPLD design. This current design is CPLD/2901 bitslice design.
The ALU is 12 bits, double clocked to give a 24 bit CPU on a 6800/6502
style memory cycle.One CPLD is for high speed decoding and the other
for the MAR and MBR data paths. A 8 bit refresh counter is for
DRAM's. A 2.5 MHZ (top speed)clock gives a 800 ns memory cycle. 3
2901's make
up the data path.
That sounds like fun.
Had you ever thought about making boards for these to sell to
people? I'd want a couple, I'll bet some other people would buy them
too...they sound like fun to hack on.
-Dave
--
Dave McGuire
Port Charlotte, FL
PS. I have a design concept with about the same number
of gates as
6809 or a Z80.
Cool! Describe?
8:11 p.m.
Dave McGuire wrote:
I plan to make up some PCB's for my local use, when I get off my butt.
Right now I am taking a short break, since I am not sure just what the
rest of the design will be like. Most likely similar to the Mark 8
micro-computer with a 50 pin ribbon cable buss and PC floppy drive
connectors for power. It looks like about 6 boards.
A) clock/front panel
B) Cpu
C) 128 kb static ram
D) 128 kb static ram/EEPROM
E) Uart/IDE interface
F) spare
Ben.
See: CPLD
design. This current design is CPLD/2901 bitslice design.
The ALU is 12 bits, double clocked to give a 24 bit CPU on a 6800/6502
style memory cycle.One CPLD is for high speed decoding and the other
for the MAR and MBR data paths. A 8 bit refresh counter is for DRAM's.
A 2.5 MHZ (top speed)clock gives a 800 ns memory cycle. 3 2901's make
up the data path.
That sounds like fun.
Had you ever thought about making boards for these to sell to people?
I'd want a couple, I'll bet some other people would buy them too...they
sound like fun to hack on. -Dave
8 Feb
8 Feb
10:38 a.m.
>>> OK, I actuially have a US dime
somwhere. Please tell me where I can
>>> exchange it for 12 PCs capable of running FPGA or CPLD development
>>> software.
>>
I would. :) But I see PeeCees on the curb quite often.
7 Feb
7 Feb
3:20 p.m.
New subject: Dime-a-dozen PCs
On Sun, 7 Feb 2010, Tony Duell wrote:
OK, I actuially have a US dime somwhere. Please tell
me where I can
exchange it for 12 PCs capable of running FPGA or CPLD development software.
Well, admittedly there is an issue of shipping. The dime is just the
purchase price.
If you can come up with a way to ship them, we (those in the USA) would
be glad to provide a metric buttload of PCs.
If you come visit, we can load you down with more stuff than you can
carry. I'll even throw in some photographic equipment that you would
like.
--
Grumpy Ol' Fred cisin at xenosoft.com
3:33 p.m.
New subject: Dime-a-dozen PCs
There is a US non-profit which runs a boarding school and skills
training center in Kenya.
They are looking for surplus PCs with 220 VAC OK supplies for use in
basic rework and software skills programs.
There may also a possibility for people to teach the basic skills required.
Have known one of the principals for >20 years. This is legit; no resale
or scrapping at destination.
If people have surplus machines to contribute, please inform off-list.
Thanks,
Steve
Boston
Fred Cisin wrote:
On Sun, 7 Feb 2010, Tony Duell wrote:
OK, I actuially have a US dime somwhere. Please
tell me where I can
exchange it for 12 PCs capable of running FPGA or CPLD development software.
Well, admittedly there is an issue of shipping. The dime is just the
purchase price.
If you can come up with a way to ship them, we (those in the USA) would
be glad to provide a metric buttload of PCs.
If you come visit, we can load you down with more stuff than you can
carry. I'll even throw in some photographic equipment that you would
like.
--
Grumpy Ol' Fred cisin at xenosoft.com
4 p.m.
On 2/7/10 10:23 AM, "Tony Duell" <ard at p850ug1.demon.co.uk> wrote:
Also, unless I missed something, Windows isn't
free. I I doubt that if I
found a junked PC that happeend to have a runnable copy of Windows on the
hard drivce the ntat would count as a valid Windows license. I don't
particulalry care for Windows, or any Microsoft product for that matter,
but that doesn't give me the right to pirate them.
-tony
It depends on the system actually, and the user :) for example, OEM's (dell,
HP, etc) the OS is licensed to a particular machine, that is why when you
purchase a Dell or HP pc, the windows activation key/cd key is affixed to
the system. According to what MS states also, once you install Win XP,
Vista, Win7, 98, 95, etc you are supposed to affix the cd-key/activation key
label to that machine and use it on no other machine, even if you replace
the machine they want you to buy a new windows license for that new machine.
5 Feb
5 Feb
3:04 p.m.
That being said, apparently few think that it's an
issue, as a web
search doesn't turn up much in the way of grumbling. But how many
8255s are installed in an application where mode switching is used?
Darned few, I would guess.
The problem is still there even if you don't want to change modes after
inintialisation. After a hardware reset all pins you want to use as
outputs (that is pins you have connected to inputs of your peripheral
logic) are going to appear floating, so if your peripheral logic is TTL
(a good bet at the time the 8255 was designed), they will appear high. As
soon as you program the mode register, all those lines go low. You can
then set them back to your desired states. But your logic has to be
designed to cope with that.
I am trying to think of where the 8255 was used. OK, on the 5150 and 5160
motherboard to handle the keyboard interface and DIP switches, where
glitches don't matter. What other major uses did it have? Very frw of my
classic computers use one.
The 8255 was obsolete years ago. It's slow and most of the desired
functionality can be gotten more easily with other means, either with
programmable logic or even SSI.
So? This is classiccmp
So we're really beating a dead horse.
I was simply pointing out that Intel even managed to mis-design a
parallel port chip. Most of their other chips were equaliy inellegant.
-tony
3:51 p.m.
On 5 Feb 2010 at 23:04, Tony Duell wrote:
I am trying to think of where the 8255 was used. OK,
on the 5150 and
5160 motherboard to handle the keyboard interface and DIP switches,
where glitches don't matter. What other major uses did it have? Very
frw of my classic computers use one.
Quite a few 8-bit x80 micros used them them for various purposes
(yes, even Z80 systems); The 5150 BIOS refers to an 8255 in the
printer code, even though they didn't use one. A FAX machine I
looked at not long ago used one. I've got a 90's PCI-bus data
aquisition card that uses 3 of them.
But there really is no good reason to use an 8255, a Z80 PIO, a 6820
or even a 6522 in a new design today, other than for nostalgia's
sake.
--Chuck
3:59 p.m.
On Feb 5, 2010, at 6:51 PM, Chuck Guzis wrote:
I wonder if the 5150 was originally designed with an 8255?
--
Dave McGuire
Port Charlotte, FL
I am trying to
think of where the 8255 was used. OK, on the 5150 and
5160 motherboard to handle the keyboard interface and DIP switches,
where glitches don't matter. What other major uses did it have? Very
frw of my classic computers use one.
Quite a few 8-bit x80 micros used them them for various purposes
(yes, even Z80 systems); The 5150 BIOS refers to an 8255 in the
printer code, even though they didn't use one. A FAX machine I
looked at not long ago used one. I've got a 90's PCI-bus data
aquisition card that uses 3 of them. But there really is no good reason to use an 8255, a
Z80 PIO, a 6820
or even a 6522 in a new design today, other than for nostalgia's
sake.
Well if you really want to think that way, there's really no good
reason to use ANY digital component (save for perhaps the very
highest-clocked microprocessors) other than an FPGA in a new design
today.
-Dave
4:16 p.m.
On 5 Feb 2010 at 18:59, Dave McGuire wrote:
Well if you really want to think that way,
there's really no good
reason to use ANY digital component (save for perhaps the very
highest-clocked microprocessors) other than an FPGA in a new design
today.
I can think of one--money. The cheapest microcontroller is cheaper
than the cheapest FPGA.
--Chuck
4:22 p.m.
On Feb 5, 2010, at 7:16 PM, Chuck Guzis wrote:
Smartass. ;)
-Dave
--
Dave McGuire
Port Charlotte, FL
Well if you
really want to think that way, there's really no good
reason to use ANY digital component (save for perhaps the very
highest-clocked microprocessors) other than an FPGA in a new design
today.
I can think of one--money. The cheapest microcontroller is cheaper
than the cheapest FPGA.
11:14 p.m.
On 5 Feb 2010 at 23:14, Ben wrote:
Chuck Guzis wrote:
But there really is no good reason to use an 8255, a Z80 PIO, a 6820
What do you need to do? Programmable logic can be configured to do
whatever you need.
--Chuck
or even a 6522 in a new design today, other than
for nostalgia's >
sake.
So what do you recomend?
6 Feb
6 Feb
3:41 a.m.
Quite a few 8-bit x80 micros used them them for
various purposes
(yes, even Z80 systems); The 5150 BIOS refers to an 8255 in the
I must have a strange colletion then. I can only think of 2 or 3 machines
I own that contain 8255s.
But there really is no good reason to use an 8255, a
Z80 PIO, a 6820
or even a 6522 in a new design today, other than for nostalgia's
sake.
I can think of many reasons : You have the chip in stock ('new design'
doe not preculuse it being a one-off); Compatibility with existing
hardware or software (then if the design doesn't work you know to look
elserwhree for the fualt); It takes less time to use the chip than to
design a replacement; And many more.
There;s no reason why ytou have to use anything other than 7400s, of
course...
-tony
5378
days inactive
5389
days old
294 comments
49 participants
participants (49)
-
aek＠bitsavers.org -
afra＠aurigae.demon.co.uk -
ajp166＠verizon.net -
aliensrcooluk＠yahoo.co.uk -
andyh＠andyh-rayleigh.freeserve.co.uk -
arcarlini＠iee.org -
arcbe2001＠yahoo.com -
ard＠p850ug1.demon.co.uk -
bfranchuk＠jetnet.ab.ca -
cclist＠sydex.com -
chd＠chdickman.com -
cisin＠xenosoft.com -
classiccmp＠philpem.me.uk -
csquared3＠tx.rr.com -
derschjo＠mail.msu.edu -
dgriffi＠cs.csubak.edu -
dkelvey＠hotmail.com -
emu＠e-bbes.com -
ethan.dicks＠gmail.com -
g＠kurico.com -
geoffr＠zipcon.net -
hachti＠hachti.de -
hilpert＠cs.ubc.ca -
IanK＠vulcan.com -
jdr_use＠bluewin.ch -
jkunz＠unixag-kl.fh-kl.de -
jonas＠otter.se -
jws＠jwsss.com -
keithvz＠verizon.net -
lance.w.lyon＠gmail.com -
legalize＠xmission.com -
mcguire＠neurotica.com -
mwichary＠gmail.com -
n0body.h0me＠inbox.com -
oltmansg＠bellsouth.net -
pat＠computer-refuge.org -
pcw＠mesanet.com -
pete＠dunnington.plus.com -
pu1bzz.listas＠gmail.com -
ray＠arachelian.com -
RichA＠vulcan.com -
robert＠irrelevant.com -
rogpugh＠mac.com -
spc＠conman.org -
spectre＠floodgap.com -
steve＠radiorobots.com -
tpeters＠mixcom.com -
trixter＠oldskool.org -
wdonzelli＠gmail.com