[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: 6502 illegal opcodes questions

mdj wrote:

Michael J. Mahon wrote:



I'm awaiting a TimeMaster HO which has a rather nice programmable
interrupt controller. Much more flexible than relying on the 60Hz VBL I
use at the moment for experimentation.


Actually, 60Hz is plenty fast enough to find almost anything of
real interest on a slow machine.  And it is infrequent enough that
you can actually execute some code without it being intrusive.



True. Actually I've found 60Hz to be a good slicing interval on the
Apple II, perhaps moreso when the machine accelerated than not. I'm
looking forward though to having a programmable timer source in the
machine - something I've been missing for a long time.


I've found any card with a 6522 a great source of programmable timers
and interrupts.  It's pretty easy to hook up the IRQ line if the card
hasn't done so.

Just running two counters as a 1MHz counter provides a great running
cycle counter for sampling at interesting places.


It's good fun exploring these ideas on smaller environments that have
nice predictable behaviors, but you already know this :-)


...and I *love* it!  Of course, I love it even more when I fail to
predict a behavior.  ;-)



And it's very enlightening just how frequently this occurs, even on
machines that are very humble. There is so much to be learned.


Hear, hear.


Yes, I always provided a way for processes to handle interrupts
directed to them.  (Most language designers hated the idea.)



It's hard enough getting OS designers to acknowledge the issue :-(


Most OS designers think of application programmers as wimps,
and the *first* set of wimps are the language folks. ;-(


Most language designers are fundamentally opposed to concurrency
concerns entering the language. This is a folly, and a real impediment
to having modern system provide realtime scheduling :-(


Yep--that's been my experience, too.

In most languages, concurrency further weakens the already weak
axiom system defined by type and scope rules.  The fact that it
adds tremendous power as it does so is apparently lost on them.


That is the very simple approach which I believe the encoders themselves
should do after taking a "census" of the system they are running on.



Yeah - it's simple enough to get a poor mans version through a simple
wrapper script, but you're right encoders need to do this. Bring on
parallelism support in languages says I !



Quantum computing evaluates all possible computations simultaneously,
so the "selection" of the answer tends to be done at the end.  ;-)

NP-complete problems become solvable because a huge combinatoric
space of possible solutions is explored "in superposition" in the
time required to explore a single solution.  Then you have to "read
out" the final state(s) to discover the solution(s).



Parallelism provides a reduction in time required to compute many
combinatorial problems too.


But only (at best) in proportion to the degree of parallelism.

Quantum mechanics is using the whole universe to get the answer.  ;-)


I'm reminded of "the answer to the ultimate question".  At some point,
you realize that you really want the ultimate question, too.  ;-)



Indeed! The answer is arbitrary without the question :-)



What needs to be done is for trained people with an *engineering*
mindset to sit down and squarely face the problem of multi-level
concurrency.

I expect the solutions will roll out in layers of successive refinement,
but we haven't yet even chosen to directly address the problem.



It won't be long now. We can't wait much longer for companies to
engineer processors with massively faster sequential processing speeds
before realising that they can't :-)


Yes, I think that has dawned on them as they whip their design teams
harder while watching their stock stagnate and then fall...



I think it has dawned on them the stock price is falling, but beyond
that, the actual measures of such failure tend to evade being
addressed. :-(


I think it's more a problem of not knowing what to do.  The "machine"
of the semiconductor industry has been tuned up to the rhythm of Moore's
"Law"--actually a simple economic prediction that if you can increase
the number of transistors on a chip fast enough, you can create enough
business to finance the work required to maintain the density increases.

Now that physics is interfering with the rate of improvement, and making
the transistors less ideal, business is down, and what was a virtuous
cycle is turning vicious.

Like the proverbial frog, the industry is taking a long time to figure
out that their business model needs to change fundamentally if they are
to survive.  And that includes the PC market, where the average life
of a system has increased from about 2.5 years to about 4 years, causing
a massive decrease in the effective size of the (saturated) market.

We're now in a *serious* buyers' market--with the real price of
computers dropping like a rock as their effective performance has
effectively stagnated.

Now that the stage is set, it will be interesting to see what happens!


You're absolutely right, but there's a degree of dependency between the
two that needs to be addressed, and part of that is engineering out old
notational forms which inhibit the progress of parellel system design.


Again, I would say that very little of the current linguistic goals have
more than incidental relevance to parallelism.  It's a plain case of
"looking where there's light instead of where they lost it".



Indeed the things I'd like to change are fairly little things too, yet
the degree of defiance that ones faces when suggesting it is staggering
:-)


So if you're going to make a change, make it a *big* one--it won't get
any worse reaction than a small one, and maybe *less*!  It's certainly
a better average return on your investment.  ;-)


If an alien intelligence is watching, a little box on page 11,325 of
their weekly report must be devoted to a betting pool on how long it
will take us to figure out that we were working on the wrong problem.
(Just in *this* area--there are lots of boxes on other pages!  ;-)



And the one who wins the pool probably made his guess based on looking
at their own history ;-)


Nah--the only thing we learn from history is that no one ever learns
anything from history.  ;-)  (And the Barber of Seville has a beard. ;-)

-michael

Parallel computing for 8-bit Apple II's!
Home page:  http://members.aol.com/MJMahon/

"The wastebasket is our most important design
tool--and it is seriously underused."