Advantages of Parallel Hz

On Mon, 07 May 2007 14:56:42 -0500, Del Cecchi wrote:
....
Just think, a digital theramin.

OK:
http://www.physics.gla.ac.uk/~kskeld...ts/E9/cir2.gif

;-)
Rich

"Del Cecchi" wrote in message
...
Wilco Dijkstra wrote:
"Radium" wrote in message
oups.com...

On May 7, 11:27 am, Rich Grise wrote:


On Sun, 06 May 2007 01:08:43 -0700, Radium wrote:

On May 5, 9:57 pm, "Bob Myers" wrote:

You have yet to ask a serious question.

How does SB16 ISA's FM synth freshly generate its instructions?

SB16 ISA's FM synth doesn't freshly generate its instructions.

It freshly synthesizes (electrical representations of) sounds based on
instructions it receives from the device that owns, and is controlling,
the ISA bus.

Okay. That is what I meant. Sorry for the misunderstanding.

I want my CPU to freshly generate electronic signals [instead of
playing them back from ROM] "based on instructions it receives from
the device that owns, and is controlling" it.


So you want micro code :-) But where do you get the instructions that
control the micro code from? Or are you generating those instructions
too? If so, where do those instructions come from? And so on...

You always need to store and play back instructions one way or another,
they can't generate themselves automatically you know. Lots of people
would be out of a job if computers could write their own software...


Thanks for clearing this up.

Sometimes, I need to be told what I want.


Thanks for making my day!

Wilco
Of course one can generate the instructions to the sound card algorithmically rather
that using stored sequences. Likewise with Just in Time compilation or interpretation,
one can generate sequences of instructions algorithmically rather than use a classic
stored object program. Just think, a digital theramin.

But in these cases there is another program that does the generation/translation/
interpretation/decompression. That program itself must be stored and played back
from memory somehow.

In any case the data used to generate the instructions from is a stored program
as well that is simply played back from memory. Does it matter whether the same
binary can be intepreted, JIT'd, executed as micro code sequences or directly
executed by different implementations? In many cases you can't tell, eg. Transmeta.
I call that binary a stored program played back from memory irrespectively of how
it is executed.

Wilco

"Rich Grise" wrote in message
news
On Fri, 04 May 2007 17:45:56 -0700, Radium wrote:

On May 4, 5:32 pm, "Bob Myers" wrote:

Yes, you've SAID that before, but you have yet to give
any indication at all that it means anything.

How does it not mean anything?

By not meaning anything.

Exactly....welcome to Radium's Department
of Redundancy Department.

"When I use a word, it means just what I choose it
to mean - neither more nor less."

- Humpty Dumpty, to Alice,
"Alice's Adventures in Wonderland"

Bob M.

On May 7, 12:12 pm, "Wilco Dijkstra"
wrote:

"Radium" wrote in message

oups.com...

On May 7, 11:27 am, Rich Grise wrote:

On Sun, 06 May 2007 01:08:43 -0700, Radium wrote:

On May 5, 9:57 pm, "Bob Myers" wrote:

You have yet to ask a serious question.

How does SB16 ISA's FM synth freshly generate its instructions?

SB16 ISA's FM synth doesn't freshly generate its instructions.

It freshly synthesizes (electrical representations of) sounds based on
instructions it receives from the device that owns, and is controlling,
the ISA bus.

Okay. That is what I meant. Sorry for the misunderstanding.

I want my CPU to freshly generate electronic signals [instead of
playing them back from ROM] "based on instructions it receives from
the device that owns, and is controlling" it.

So you want micro code :-) But where do you get the instructions that
control the micro code from?

No microcode.

Or are you generating those instructions
too?

Yes.

If so, where do those instructions come from?

Hardware logic.

If you read the wikipedia links I posted and quoted, you'll find that
there is a real-time, hardware-based alternative to ROM and microcode.

On May 7, 12:56 pm, Del Cecchi wrote:

one can generate sequences of
instructions algorithmically rather than use a classic stored object
program.

Obviously, I prefer the former over the latter. I like real-time
hardware. I dislike latency and buffering and want the least of them
as possible. In order to have the least amount of latency and
buffering, all parts of the PC must be fully-hardware with as little
software as necessary.

On Mon, 07 May 2007 14:35:51 -0700, Radium wrote:
On May 7, 12:56 pm, Del Cecchi wrote:

one can generate sequences of
instructions algorithmically rather than use a classic stored object
program.

Obviously, I prefer the former over the latter. I like real-time
hardware. I dislike latency and buffering and want the least of them
as possible. In order to have the least amount of latency and
buffering, all parts of the PC must be fully-hardware with as little
software as necessary.

OK, then just go ahead and design the hardware algorithms that generate
the programs that do what you want them to do, and show us.

Even a block diagram would be fine. :-)

BTW, Radium, are you, by any chance, autistic?

Thanks!
Rich

On May 7, 2:56 pm, Rich Grise wrote:

On Mon, 07 May 2007 14:35:51 -0700, Radium wrote:

On May 7, 12:56 pm, Del Cecchi wrote:

one can generate sequences of
instructions algorithmically rather than use a classic stored object
program.

Obviously, I prefer the former over the latter. I like real-time
hardware. I dislike latency and buffering and want the least of them
as possible. In order to have the least amount of latency and
buffering, all parts of the PC must be fully-hardware with as little
software as necessary.

OK, then just go ahead and design the hardware algorithms that generate
the programs that do what you want them to do, and show us.

I wish commercial PCs were made that way. Sadly, my wish is way too
good to ever be true.

Even a block diagram would be fine. :-)

LOL.

BTW, Radium, are you, by any chance, autistic?

I am Aspergered.

Robert Redelmeier wrote:

In comp.sys.ibm.pc.hardware.chips Roger_Nickel wrote in
part:
http://www.ltsp.org/
Linux terminal server project. Seems like a step backwards but
certainly solves many of the usual support problems. Etherboot
or Intel PXE for the terminals is a possibility if the hardware
supports it or could boot off a usb disk or flash card.

Thanks. Very nice. There are some decent thinclients available.
Mostly looks like for internet cafes, classrooms, workrooms.

A bigger market might be "standalone" thin clients. Home internet
appliances with built-in browsers, but otherwise no programmability
(state retained). Certainly more than the 32 MB LTSP minimum, but
probably not more than 128 MB RAM. US$50 plus monitor (or S-video
out for exhibitionists/remotecontrol-hogs who want to surf on the TV!)

Such a device would be attractive to non-computer experts
(nothing to go wrong) or as second PCs in a household.

-- Robert
Add an HDMI output to that for all the large wide-screen types. The added
resolution is quite worth it.
--
JosephKK
Gegen dummheit kampfen die Gotter Selbst, vergebens.Â*Â*
--Schiller

On Mon, 07 May 2007 15:57:58 -0700, Radium wrote:
On May 7, 2:56 pm, Rich Grise wrote:
....
BTW, Radium, are you, by any chance, autistic?

I am Aspergered.

Thanks for this.

Would you like special kid-glove treatment, or is your condition under
control enough that our feedback is bearable?

Thanks,
Rich

On May 7, 3:57 pm, Radium wrote:
On May 7, 2:56 pm, Rich Grise wrote:

On Mon, 07 May 2007 14:35:51 -0700, Radium wrote:
On May 7, 12:56 pm, Del Cecchi wrote:
one can generate sequences of
instructions algorithmically rather than use a classic stored object
program.
Obviously, I prefer the former over the latter. I like real-time
hardware. I dislike latency and buffering and want the least of them
as possible. In order to have the least amount of latency and
buffering, all parts of the PC must be fully-hardware with as little
software as necessary.
OK, then just go ahead and design the hardware algorithms that generate
the programs that do what you want them to do, and show us.

I wish commercial PCs were made that way. Sadly, my wish is way too
good to ever be true.

Not getting what you want can be frustrating but the real disasters
happen when you do get what you want but didn't fully think through
what you wanted. This may be that sort fo case. The current line of
processor evolution is from a simple concept that the CPU does what it
is told. They are very slavish in this in that if you tell them to
add zero to a number, they will perform the add without noticing that
it is a silly thing to do.

Some processor are "microcoded". I suggest you look this up and study
it a bit. It is a concept that is heading in the direction you seem
to be thinking. The microprocessor translates a single instruction
into a short list of more basic operations that do the operation step
by step.

"microcode" tends to make for a slower processor. In order for it to
show any speed advantage, more microcode operations must be done per
second than the native instruction speed. If the internals of the
micor runs at many GHz but the I/O is only 100MHz, there can be
advantages.