Re: 6502 illegal opcodes questions

["mdj" <mdj.mdj@gmail.com>]

Michael J. Mahon wrote:

> I had FOR <index> OVER <subrange or subrange type>...
> and FOR <index> IN <set value>...  [Pascal-like sets].

Both are quite good approaches. Ada had both.

> >>Overwriting data is a classic problem, and is usually pretty easily
> >>found if it's literally a bad conditional or an off-by-1 error, since
> >>the error is always misbehaving.
> >>
> >>(Overwriting code is another matter, but code pages should be protected
> >>from self-modification except in unusual cases.)
> >
> >
> > A big problem is how to avoid execution of code within data pages, when
> > its been put there by a malicious perpeprator exploiting a flaw. Code
> > overwrite is easy, lock the codepages against writes. Can't easily lock
> > the data pages though :-)
>
> Nonsense.  Virtually all architectures today have page attributes that
> specify whether anything on a page can be *executed*, as well as whether
> it can be written.  Some architectures provide for these attributes
> to be dependent on the current privilege level of the processor.
>
> Most data pages are marked "writeable, not executable" and most code
> pages are marked "non writeable, executable" (at least if the processor
> is running at user process privilege level).
>
> Any violation results in an immediate hardware trap.

Yet we still suffer security issues like buffer overrun exploits- I
don't think this approach is all that effective on present systems, as
you can't get every codepage secured.

> >>You should take some solace from the fact that probably the most
> >>frequently used "higher level language" is Excel, and it is completely
> >>pointer safe.  ;-)  The only mistakes you can make in Excel are the
> >>ones that will bankrupt your company!  (Get my point?)
> >
> >
> > No it isn't! Excel spreadsheets routinely refer to a cell that hasn't
> > been defined. This brings a whole new meaning to segmentation
> > violation. Don't get me started about the number of "databases" that
> > exist in spreadsheets :-)
> >
> > There's no restriction whatsoever in Excel code over what part of the
> > "address space" you reference in an expression. You can even reference
> > a sheet that doesn't exist (a genuine "bus error" :) )

> My point was, that there are more direct ways that human error can
> lead to the failure of a business (or what-have-you) than can be
> protected against in a programming language!

Indeed. I just want to improve the quaility of expression of ideas such
that the code is more reusable over time.

> Then what do all those legions of programmers read?  Or do they all
> have so little influence over the spending of money that no one cares
> to advertise to them?

Web sites, blogs, etc. A big issue is that a majority of the larger
sites are vendor sponsored, so there's a lot of don't bite the hand
that feeds going on.

> > Most development environments today provide profiling tools that make
> > it simple to spot such hotspots. The tricky areas now are usually where
> > programs are I/O bound.
>
> Clock time includes I/O waits.  In fact, the 20% routine was a codefile
> output routine that originally had only one buffer.  I added three page
> buffers for it to manage LRU and it sped up by a factor of ten.

This is probably one of the biggest areas of performance enhancement we
could explore with well designed tools, that showed up the bottlenecks
on performance due to over utilisation of I/O resources.

I had a case sometime back where a database system was performing
extremely slowly, while running on some pretty impressive hardware.
Turns out the system was issuing asynchronous I/O calls in 8kb chunks
at such a rate that it exceeded the transactional throughput of the
fibre card it was using for I/O without getting anywhere near its
bandwidth.

Problem was solvable by tuning a parameter or two, but such a thing
should be easier to find than it was (used an interposing technique to
sniff the read/write calls to the OS)

> > This is why I advocate tools and languages that allow you observe
> > complexity. Nobody can understand complex systems in their entirety.
>
> I'd like to see some of those tools...  Tools that span abstraction
> levels are quite interesting, and mind-blowing for many.

Yes, but nobody's putting in the effort required to make them happen.

> > The interesting elements of behavior only manifest when it's possible
> > to observe them, and observations of complex system behaviors are
> > difficult with current toolsets.
>
> Observations of system behaviors, where interesting behaviors span time
> scales of picoseconds to hours, are extremely difficult.  I have not
> seen any "great" tools, nor even any effort to create them.
>
> What I do see are little tiny steps, disconnected from one another,
> and generally used under protest by people who don't see the value.
>
> It is evident that the folks building new levels of abstraction have
> never felt any need to construct stairways to connect up with the
> lower level(s).
>
> If it were easy to visualize the behavior of a program, then programmers
> would not be so universally in the dark about how their programs
> actually behave!
>
> Have things improved greatly in the last few years?  When I made
> profiling tools available, I found them virtually unused!  Apparently
> programmers felt they already understood what their code was doing,
> so measuring it would be a waste of time (or a nasty surprise ;-),
> so there was no motivation to do it.

Herein lies the problem. There are some very nice profiling tools these
days, and profiling is just the beginning.

It takes a pretty big shift in thinking, apparently, to get people
using the tools. Once they start though they start wishing for better
ones....

> > This is precisely why I argue so strongly against using C/C++, you lose
> > any ability to do this kind of optimisation when you have no runtime,
> > and no runtime typing.
>
> No, you can "observe" machine code, too!  It is pretty easy, and
> languages like C and C++ can gain tremendously from it.
>
> All you need to do adaptive optimization is a program and its
> behavior, and they *all* have lots of that.  ;-)
>
> You don't need any *algebra* of types, since the only types that
> matter are the machine data types.  It is only at the level of
> actual machine code and actual machine addresses that it is
> possible to observe "practical" reference disambiguation and
> optimize for it, while putting in a guard against its failure.

It is significantly trickier given the architecture of current OS's to
glean this level of measurement though, where a VM approach greatly
simplifies it.

> > I think things will be much easier once there's universal adoption.
>
> We are well past the point where a language must run on all extant
> machines to be a winner.
>
> It is appropriate to leave behind the machine baggage that obstructs
> doing what needs to be done.  The programmers for that machine will
> struggle along for a while, but so what?  At least the 95% majority
> will move ahead on more modern platforms.
>
> (As an aside, Intel was the *first* company to adopt IEEE FP, back
> when it was on a coprocessor--and they did it in full generality,
> but pretty slowly.)

Yep, and x86 is still one of the only architectures with a complete
implementation.

> >
> > There's actually a great absence of such libraries though.
>
> Which, I suppose, speaks to the need for humans who understand caches
> and superscalar, out-of-order scheduling to code them--or another of
> those infernal genetic algorithms.  ;-)

You certainly need a lot less of those humans, and often they can be
the same people who helped design the hardware in the first place -
this isn't really a problem.

> >
> > I mean you must do it manually :-)
>
> Well, that's true (and I almost said so), but that is not the
> usual understanding of "garbage collection".
>
> >>Garbage collection arises as a necessity only when programmers are
> >>released from the obligation to return resources they are no longer
> >>using.
>
> There, you see, I said it!
>
> >>Garbage collection generally means traceable data structures, and
> >>therefore disciplined data structures.  However, don't overlook the
> >>"catch all" discipline for garbage--simply allocating a chunk of
> >>resource and then reclaiming everything that wasn't "registered
> >>as persistent" at end-of-job.
>
> And this "chunky" garbage collection is relatively inexpensive
> and quite effective for most programming chores.
>
> (After all, the prime directive is to not generate (much) garbage if
> it can be avoided.  ;-)

I'm actually convinced that on current and future architectures
releasing programmers from the need to clean up after themselves (so to
speak) is a major benefit. It's one less thing to be concerned about,
and the net result is (usually) better execution time for a given
program.

Only in cases where resource consumption is extremely high is there a
need to invoke manual collection strategies.

> > Other than not having plenty of free concurrent processing power
> > available, what are they?
>
> I was about to say their lack of provable correctness combined with
> their ability to wreak havoc across all levels of abstraction.  But
> then I realized that they almost have a "provable lack of incorrectness"
> in a highly concurrent, hierarchically connected multiprocessor.
>
> Garbage collection, because it typically cuts across several layers
> of abstraction, exhibits a criminal lack of locality.  So one must
> use a hierarchy of concurrent local garbage collectors...is this
> considered a solved problem?

Not yet - but it's getting there slowly :-)

> > Any non-trivial program creates data then needs to dispose of it. What
> > purpose does it serve for that program to waste sequential running time
> > doing so?
>
> One could as easily, and more coherently, say that part of doing any
> job is cleaning up after it.  And such local "cleaning up" is a much
> more efficient process than anything more global--think cache misses,
> page faults, network traffic...
>
> Why on earth would you expect that the "cleanup" phase of a program
> was a good part to run in parallel with the rest of it, rather than
> looking for a more structural division into concurrent parts.
>
> Garbage collection originally came into being because of a programming
> paradigm which made multiple, uncountable references to various data
> objects, then re-assigned references, leaving data sometimes abandoned
> without any explicit knowledge of that fact--"garbage" data.
>
> While this paradigm is occasionally useful, for most programming it
> is simply a mark of laziness and failure to keep track of the scope
> or lifetime of data structures.  Some languages define semantics (of
> strings, for example) which naturally result in garbage creation.
> But even then, the garbage can be restricted to the string pool(s).
>
> Most "garbage" is either avoidable, and can be prevented, or is
> negligible, and can wait to be blindly recovered at the end of a
> task.  Building in a pervasive notion of a background garbage
> collection activity is, in many cases, surrendering to a lack of
> discipline in managing data structures.  (And a lack of tools to
> verify that they are properly managed.)

Quite strongly disagree with this point. Any reasonably large program
will generate 'garbage', and indeed it can be prevented, by cleaning it
up. I just don't think it's an efficient use of either human time
(which is limited) or machine time (which is always expanding) to put
responsibility for a relatively simple computation task on the human.

You gain nothing by doing it yourself, and potentially lose out, by
losing the ability to handle it concurrently.

> > Once we rely on techniques that bind us to architectures we lose. It's
> > easy to avoid them, and we should do so.
>
> So you think that address spaces are in danger of becoming obsolete?
> Or that addresses will not be operated on by arithmetic operations?
> Trust me, we'll all be long gone before that changes!

Indeed, but applications that are bound to single address spaces by
virtue of exploiting their nature in code unnecessarily will also by
long gone. And we're recreating them still, far beyond the point where
it's sensible to continue.

> > Yet still the speed deficit between I/O and computation grows...
>
> But somehow that processing advantage has not translated into the
> need to do less I/O!

Indeed it's caused the need for more I/O. There's potential light at
the end of the tunnel though - the possibility of treating secondary
storage as it it's a persistant addressable medium is not far away,
which can result in many positive shifts in the computing paradigm.

> But one man's callous is another man's foot.  ;-)
>
> Frameworks only get pruned by discipline--and someone's ox always
> gets gored in the process.  That's why, in a market-driven world, the
> universe is always expanding, not contracting.  Until the "stressor"
> lands like a ton of bricks...

We agree on that. It's unfortunate that the stressors always end up
being so extreme, and are dealt with reactively.

> >>Organisms usually get simpler only when some extreme stressor hits their
> >>environment.  Hand-cranked machines?  Boot times exceeding attention
> >>spans?  ;-)
> >
> >
> > Well, such things are on their way :-)
>
> Yes, if Negroponte gets his way.  ;-)
>
> Already, many people keep their machines powered off, and don't use
> them for many tasks in passing because they take too long to boot
> (and shut down).  There is a huge productivity loss in the extended
> time required to start up a modern machine.
>
> (I keep mine on all the time--so I trade off electricity use against
> twiddling my thumbs--that and the fact that my machine is the house's
> print server.  ;-)

I do the same, it consumes little power in standby mode anyway, and the
time gained back by not waiting for it is a big plus.

I frequently have to defend myself against those who claim it is a
waste of power, when that remark is usually a thinly disguised (that
noise is keeping me awake :) )

> >>>Indeed. I believe though that minimising these decisions through
> >>>keeping interfaces highly abstract is the best way to provide space
> >>>down the track for optimisation. Generally speaking, it isn't that hard
> >>>to get it right, but getting everyone to agree is oft problematic :-)
> >>
> >>Hence the need for objective models, and the expertise to appreciate
> >>their results.
> >
> >
> > If only there was time to analyse them. Can I say more, better tools
> > one more time ? ;)
>
> But most of the tools we need are programs that we need to write, and
> many of them are analogous to, and therefore specialized to, the problem
> that we are currently solving.  It is the unwillingness to write this
> "scaffold" code (I call it that because it is essential to the efficient
> construction of the product, but is not a shipping part of the product).
>
> Dijkstra used to make the analogy between a program and an iceberg:
> like an iceberg, the visible code of a program is only a small part
> of the documentation and code that supports the activity of creating
> the program.  Yet, we often find that these supporting tasks are left
> to the end of a project, or are left undone entirely.
>
> Most engineering disciplines have a solid understanding of the value
> and necessity of thorough planning and "tooling" to do a project.
> Making proper drawings, forms, and scaffolds is as critical to the
> project's success as a good design or good materials.
>
> Only in software construction are we so informal (perhaps even sloppy)
> that we jump right in and start deciding things before the problem is
> even well-defined, we code modules before considering how we will test
> them, and we attempt to integrate systems from modules of radically
> differing robustness and pedigree.  It's no wonder that we are so
> often surrounded by piles of collapsed rubble!
>
> You keep saying "tools" and I keep saying "discipline".
>
> I have observed that a disciplined programmer will find or construct
> good tools as a natural part of his discipline.

Indeed this is true.

> I see little corresponding indication that a programmer provided with
> good tools will develop good discipline.  I hope I'm wrong...

You don't learn from the tools, but you can learn from information, or
demonstrations of things that aren't quite right. It's not the most
efficient approach to constantly learn only from ones own mistakes.

I mean, by the logic of applied discipline, we could all program in
assembly and construct massive macro libraries, but we don't because
it's a waste of time - we can use high level languages with some built
in discipline to save ourselves effort.

I think there's an awfully long way to go before we're doing that even
remotely to the potential of the technique.

Matt