Re: 6502 illegal opcodes questions

[pausch@saaf.se (Paul Schlyter)]

In article <1149557912.816160.29150@i40g2000cwc.googlegroups.com>,
mdj <mdj.mdj@gmail.com> wrote:

> Paul Schlyter wrote:
>> In article <1149381913.929713.169160@i40g2000cwc.googlegroups.com>,
>> mdj <mdj.mdj@gmail.com> wrote:
>>
>>> Paul Schlyter wrote:
>>>
>>> How so?
>>
>> By making it possible to give a subroutine an argument of one type
>> while it expected that argument to be of another type.
> 
> Unlike C/C++, variable arguments in Java are typed. You can declare the
> variable list of be of type Object (in reality, Object[]), but you
> still need to cast them back to something useful. Essentially, you
> handle Objects of the types that are applicable and anything else you
> can either ignore, or throw a runtime error.
> 
> It's actually very typesafe.

However, an Object parameter requires to be given an actual object as
its argument, right?  So you cannot pass it a primitive data type, such
as an int or a double.
 
>>> Exactly. The point is to avoid these situations by design. There's no
>>> good reason to have machine dependencies within the same class in a OO
>>> language. That's poor design.
>>
>> If you were to write your application from scratch today, that's the
>> way to go of course.  But have you ever heard about legacy code?  Code
>> reuse?  If not, welcome to the real world!  If an old working piece of
>> code can be made to run on a new platform with only some small changes
>> here and there, that might be preferable to rewriting it all from
>> scratch.  If so, conditional compilation is a better way to maintain
>> that code than to create two versions of what's essentially the same
>> code.
> 
> :-) This is the essence of the point. It is VASTLY superior to create a
> small binding to legacy code via a portable mechanism (as Java and
> other languages do) than to inherit the no longer scalable features of
> legacy languages. Otherwise, you end up with new code with legacy
> problems!

That's the way to go if you want to integrate a piece of old code in a new,
larger, application of course.  But I was more thinking of code which shouldn't
be expanded but merely moved to a new platform and there behave as it did
on the old platform.  It doesn't seem particularly productive to wrap your
old C code into a Java wrapper which does nothing but executes that old C code...
 
> In the real world, real code has real legacy issues. These issues cause
> problems like portability, security, and developer productivity. You
> have a choice: either continue with the legacy approaches, or learn
> from the mistakes, wrap the code in a portable interface and move on.
> 
> In the real world, keeping your development pace agile as to not be
> eaten by newer products that don't have your legacy issues is a real
> problem. There are real solutions.

I suppose you mean "the commercial world" when you say "the real
world".  Yes, the commerical world is a continuous hectic race where
there's not really any time to do solid work.  It's more important
that the product is flashy and that it appears early.  Buggy?  Of
course, but so what?  Let customer support take care of the
complaining customers while we're developing the next product to
appear early and being flashier still .... the lifetime of a software
product is nowadays so short anyway.....

In such an environment it's probably best to throw away old code and
let everyone reinvent their wheels once more .... with humps and bumps
that there's no time to polish away.

> This is the real world effect of Microsofts design decision (pollute
> the new language with old problems) versus the Java model. Still
> hobbling with legacy for no reason whatsoever than a couple of very
> poorly concieved design ideas. And ones that history has already shown
> has a simple, clean solution.
> 
> "Those who cannot learn from history are doomed to repeat it...."

Actually, there are lots of people who do this, for their enjoyment.
I'm referring to vintage computing of course, and this very newsgroup is
part of that movement.

Yep, it belongs to "the real world" too....
 
>>>> I dondt think one can talk about namespaces at all regarding macros in
>>>> preprocessors.  The preprocessor does not know what a namespace is. It
>>>> hardly knows anything about the underlying source language.  Heck, you
>>>> can even replace reserved words with macros -- try to do THAT using
>>>> the global namespace in a normal way.....
>>>
>>> Why?
>>
>> Because namespeces belong to the programming language, and macros know
>> nothing about the underlying language.  Macros is nothing by text
>> substitution.
> 
> This is the case in C/C++. Simply because C/C++ doesn't have macro
> namespaces is not a particularly solid argument that namespaces in
> macros is a bad idea. I mean, really, every C/C++ programmer with more
> than a little experience emulates the namespace concept with prefixes?
> Why? Because you need it!

If C/C++ macros should be made aware of namespaces, should they also be
made aware of other parts of the underlying langauge?  If so, which
parts?  I think you'll have a can of worms there if you open that one....
 
>>> Namespaces are a natural extension present in most modern languages
>>> to avoid collisions that occur frequently in larger programs.
>>> Macro's being redefined by included headers from an unrelated piece of
>>> code is a real problem in C/C++ programs.
>>
>> Macros by themselves don't generate external symbols though.  The linker
>> never sees the macro names.
> <snip>
>> Note that the macros are "global" only over the source file, not over
>> the entire application.
> 
> Of course, but includes include includes (lol), which include others,
> which then perhaps collide with one you've already defined. The scope
> over which a macro symbol exists is potentially the entire application.
> It's entirely non-determinable.

Only if you're sloppy about your macro definitions.  If the macro is to
have effect in only one source file, then you'll of course define it
*after* all your #include's.  But what if that macro had been defined
somewhere else already?  The compiler will immediately complain so you'll
notice it soon enough - it can be handled in this way:

#ifdef MYMACRO
#undef MYMACRO
#endif

#define MYMACRO   My own macro definition

 
> Heck, you even have to use a convention to ensure a preprocessor file
> is applied only once, or worse recursively.

That problem is routinely handled in this way:

---------- myinclude.h header file -----------
#ifndef MYINCLUDE_H
#define MYINCLUDE_H

<contents of include file here>

#endif
----------------------------------------------

Now you can include myinclude.h as many times as you like, and it'll have
effect only once.  It is recommented that you wrap all your header files
like that, to avoid the problem of multiple inclusion.


>>> Semantically speaking Java is a lot more like Smalltalk than C++. It's
>>> a nice bridge between the dynamic world and the static world.
>>
>> The other extreme could be represented by Javascript, where all typing
>> and binding is done at runtime, and where all objects are polymorphic.
> 
> Or better by a language like Ruby which doesn't suffer from the
> semi-functional quirkiness of javascript.

Unfortunately, Ruby interpreters aren't particularly common in web browsers.. :-)

Sometimes you don't have much choice of language.  Being multi-lingual is
then the best solution.
 
>> The most important difference here is not what Java allows you to to,
>> but what Java prevents you to do.  In Java OO is mandatory while in
>> C++ it's an option.  You can even do OO programming in plain C,
>> although it means more work for the programmers -- e.g. the "this"
>> pointer must always be passed explicitly to methods, constructors and
>> destructors must be called explicitly, etc.
> 
> Indeed in plain C, you can do 'better' OO that in C++ by implementing a
> real dynamic binding system ;-)

Are you trying to say one can do something in C that cannot be done in C++ ?  :-)
 
> The things you're prevented from doing in Java are prevented because
> they've proven to be more trouble than they're worth, and there are
> other techniques which allow the same things to be implemented without
> rehashing error-prone on non-portable paradigms.

Such as unsigned integers or complex arithmetic?   <g>
 
> They were chosen not because of the whim of some engineer who preferred
> things this way, but because research had shown where the common errors
> and pitfalls were.

Such as unsigned integers or complex arithmetic?   <g>
 
> Matt
-- 
----------------------------------------------------------------
Paul Schlyter,  Grev Turegatan 40,  SE-114 38 Stockholm,  SWEDEN
e-mail:  pausch at stockholm dot bostream dot se
WWW:     http://stjarnhimlen.se/