f



6502 illegal opcodes questions

All hail to the right honourable lords and ladies of 6502 hackery! ;-)

Adam Vardy's article "Extra Instructions Of The 65XX Series CPU" covers 
this topic very well down to the ugliest details, but is unclear in two 
points:

> SKB    ***
> SKB stands for skip next byte.
> Opcodes: 80, 82, C2, E2, 04, 14, 34, 44, 54, 64, 74, D4, F4.
> Takes 2, 3, or 4 cycles to execute.

Is it documented anywhere which of these opcodes have which cycle counts?

> AXA    ***
> This opcode stores the result of A AND X AND the high byte of the target
> address of the operand +1 in memory.
> 
> Supported modes:
> 
> AXA abcd,Y      ;9F cd ab    ;No. Cycles= 5
> AXA (ab),Y      ;93 ab       ;            6
> 
> Example:
> 
> AXA $7133,Y     ;9F 33 71
> 
> Equivalent instructions:
> 
> STX $02
> PHA
> AND $02
> AND #$72
> STA $7133,Y
> PLA
> LDX $02

This is clear enough for the abs-y (9F) case, but what is "the high byte 
of the target address of the operand" in the indirect-y case (93)?

Any elucidations are highly appreciated! Including telling me where to 
look and/or whom to ask.

(Please note that this article has been cross-posted to three groups).

-- 
Linards Ticmanis
-1
ticmanis (776)
4/23/2006 8:46:21 PM
comp.sys.cbm 14331 articles. 0 followers. dunric (341) is leader. Post Follow

289 Replies
2786 Views

Similar Articles

[PageSpeed] 38

Linards Ticmanis <ticmanis@gmx.de> wrote:

> Is it documented anywhere which of these opcodes have which cycle
> counts?

Get AAY64
http://www.the-dreams.de
also look in here
http://oxyron.de/html/opcodes.html

-- 
-=[]=--- iAN CooG/HokutoForce ---=[]=-


0
iAN
4/23/2006 10:02:12 PM
There are some discrepancies between the different info files floating
around the net. Some opcodes go by different names or have a different
meaning. I've found at least three different descriptions of the $93
opcode.

Here are without any claim of validity excerpts from "6502 Undocumented
Opcodes v3.0" by Freddy Offenga:

===

"The timing values (clock cycles) from all the opcodes were compared
with
the values on the list by Adam Vardy. There were no differences.

The addressing modes for the "DOP" (double nop) and "TOP" instructions
were copied from Craig Taylor's list. The reason for this is that the
different addressing modes explain the differences in the timing
values. "

===

DOP (NOP) [SKB]
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
No operation (double NOP). The argument has no significance.
Status flags: -

Addressing  |Mnemonics  |Opc|Sz | n (cycles)
------------|-----------|---|---|---
Zero Page   |DOP arg    |$04| 2 | 3
Zero Page,X |DOP arg,X  |$14| 2 | 4
Zero Page,X |DOP arg,X  |$34| 2 | 4
Zero Page   |DOP arg    |$44| 2 | 3
Zero Page,X |DOP arg,X  |$54| 2 | 4
Zero Page   |DOP arg    |$64| 2 | 3
Zero Page,X |DOP arg,X  |$74| 2 | 4
Immediate   |DOP #arg   |$80| 2 | 2
Immediate   |DOP #arg   |$82| 2 | 2
Immediate   |DOP #arg   |$89| 2 | 2
Immediate   |DOP #arg   |$C2| 2 | 2
Zero Page,X |DOP arg,X  |$D4| 2 | 4
Immediate   |DOP #arg   |$E2| 2 | 2
Zero Page,X |DOP arg,X  |$F4| 2 | 4 

===

bye
Marcus

0
heuser
4/23/2006 10:28:19 PM
(From Linards)
> Is it documented anywhere which of these opcodes have which cycle counts?

Without checking, they should be the same as the corresponding LDA
opcode with the relevant addressing mode.

(From Marcus)
> There are some discrepancies between the different info files floating around the net.

Yes, I've been collecting these, and collating the information for some
time.

> v3.0

BTW, there's a 3.1 version of this doc floating around.

(From Freddy!)
> DOP (NOP) [SKB]

(Also TOP)
These are badly named. I prefer NOP or RDM (read memory) or perhaps ADR
(address).

(From Freddy!)
> The argument has no significance.

Bzzt! Next contestant please. This puts an address on the bus. This
means you can touch softswitches and I/O locations with these commands.
(Hence my preference for a different mnemonic.) Yes, I know the above
commands are 2 bytes, but the C64 has its I/O regs at $0000, $0001, and
there are a handful of 3-byte NOP $XXXX opcodes which can be used for
this on the Apple II.

Cheers,
Nick.

0
sicklittlemonkey
4/24/2006 12:53:51 AM
sicklittlemonkey wrote:
> (From Linards)
> 
>>Is it documented anywhere which of these opcodes have which cycle counts?
> 
> 
> Without checking, they should be the same as the corresponding LDA
> opcode with the relevant addressing mode.
> 
> (From Marcus)
> 
>>There are some discrepancies between the different info files floating around the net.
> 
> 
> Yes, I've been collecting these, and collating the information for some
> time.

Since there were several versions of the 6502, isn't it likely that
some had *differing* illegal ops and results?

-michael

Music synthesis 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."
0
Michael
4/24/2006 6:11:01 PM
In article <j7Wdne2Ir5coidDZnZ2dnUVZ_vydnZ2d@comcast.com>,
 "Michael J. Mahon" <mjmahon@aol.com> wrote:

> sicklittlemonkey wrote:
> > (From Linards)
> > 
> >>Is it documented anywhere which of these opcodes have which cycle counts?
> > 
> > 
> > Without checking, they should be the same as the corresponding LDA
> > opcode with the relevant addressing mode.
> > 
> > (From Marcus)
> > 
> >>There are some discrepancies between the different info files floating 
> >>around the net.
> > 
> > 
> > Yes, I've been collecting these, and collating the information for some
> > time.
> 
> Since there were several versions of the 6502, isn't it likely that
> some had *differing* illegal ops and results?

Not just likely - Absolutely certain. 

I've long since forgotten the source, but there used to be a listing of 
how the various "illegal" opcodes differed from chip version to chip 
version, and only a very tiny handful of them that worked on one version 
would work (or even do ANYTHING) on another version. 

(which, of course, is why they're "illegal" or "unsupported" or 
"undocumented" opcodes - You can't rely on them except on *THAT 
PARTICULAR CHIP*, and in some cases, not even then because the "what 
comes out the other end" can be influenced by the state of RAM, I/O 
locations, or other things that may or may not be duplicatable from one 
machine to the next!)

-- 
Don Bruder - dakidd@sonic.net - If your "From:" address isn't on my whitelist,
or the subject of the message doesn't contain the exact text "PopperAndShadow"
somewhere, any message sent to this address will go in the garbage without my
ever knowing it arrived. Sorry... <http://www.sonic.net/~dakidd> for more info
0
Don
4/24/2006 6:58:04 PM
> Since there were several versions of the 6502, isn't it likely that
> some had *differing* illegal ops and results?

The surprising answer is yes, but not many. ;-)

The earliest documentation I can find is Apple Assembly Line's
"So-Called Unused Opcodes" from 1981 (
http://bobsc5.home.comcast.net/aal/1981/aal8103.html#a2 ).

In 1995 I unknowingly duplicated this work (in less detail) and my
results on a Rockwell 6502 were almost identical to Bob
Sander-Cederlof's Synertek 6502:
http://www.apple2.org.za/mirrors/ground.icaen.uiowa.edu/Mirrors/uni-kl/hardware/undocumented_6502_opcodes

The Apple-based research doesn't differ much from the more detailed
research done on the C64, Atari and even BBC systems. It seems that
this is because the same MOS 6502 mask was used for the 6510 and other
6502 implementations.

In any case, some Apple games use these opcodes, and many more C64
games do. Although a multibyte NOP is often sufficient, in other cases
the expected operation is required, not hard to implement, and improves
emulation authenticity (e.g. crash behaviour).

Cheers,
Nick.

0
sicklittlemonkey
4/25/2006 3:33:03 AM
sicklittlemonkey wrote:
>
> The Apple-based research doesn't differ much from the more detailed
> research done on the C64, Atari and even BBC systems. It seems that
> this is because the same MOS 6502 mask was used for the 6510 and other
> 6502 implementations.

As the 6510 is a MOS chip this doesn't come as a shock, really  ;o)
And it explains why "illegal opcodes" are so much more popular on the
C64: Only one chip version in all these years (though under different
names).
AFAIK the 6502's in the Ataris were compatible to each other, too.

> In any case, some Apple games use these opcodes, and many more C64
> games do. Although a multibyte NOP is often sufficient, in other cases
> the expected operation is required, not hard to implement, and improves
> emulation authenticity (e.g. crash behaviour).

I agree with you here, Nick. Documenting them as thorough as possible
is definitely important, as they were used.
On the other hand I haven't seen an application where they were
indispensable.
Does anybody have some interesting sources they would share (or can me
point to some)?

bye
Marcus

0
heuser
4/25/2006 4:01:08 AM
Hi Marcus.

The hard thing is collating the documentation!

As for indispensable, I've only seen this one:
http://groups.google.com/group/comp.sys.apple2/msg/cfc5ac0127e3cfb4

Cheers,
Nick.

0
sicklittlemonkey
4/25/2006 4:33:11 AM
Don Bruder wrote:
> In article <j7Wdne2Ir5coidDZnZ2dnUVZ_vydnZ2d@comcast.com>,
>  "Michael J. Mahon" <mjmahon@aol.com> wrote:
> 
> 
>>sicklittlemonkey wrote:
>>
>>>(From Linards)
>>>
>>>
>>>>Is it documented anywhere which of these opcodes have which cycle counts?
>>>
>>>
>>>Without checking, they should be the same as the corresponding LDA
>>>opcode with the relevant addressing mode.
>>>
>>>(From Marcus)
>>>
>>>
>>>>There are some discrepancies between the different info files floating 
>>>>around the net.
>>>
>>>
>>>Yes, I've been collecting these, and collating the information for some
>>>time.
>>
>>Since there were several versions of the 6502, isn't it likely that
>>some had *differing* illegal ops and results?
> 
> 
> Not just likely - Absolutely certain. 
> 
> I've long since forgotten the source, but there used to be a listing of 
> how the various "illegal" opcodes differed from chip version to chip 
> version, and only a very tiny handful of them that worked on one version 
> would work (or even do ANYTHING) on another version. 
> 
> (which, of course, is why they're "illegal" or "unsupported" or 
> "undocumented" opcodes - You can't rely on them except on *THAT 
> PARTICULAR CHIP*, and in some cases, not even then because the "what 
> comes out the other end" can be influenced by the state of RAM, I/O 
> locations, or other things that may or may not be duplicatable from one 
> machine to the next!)

Actually, that was my point.

It's a tribute to the naivete of early game programmers that they
thought it would be OK to use undefined instructions.  It's a good
way of making sure that a game will become obsolete as models advance.

And anyone who couldn't discipline themselves to "get the job done"
on time and under budget by using only documented opcodes isn't much
of a programmer.  The whole thing reeks of high school...  ;-)

-michael

Music synthesis 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."
0
Michael
4/25/2006 7:13:02 AM
Linards Ticmanis <ticmanis@gmx.de> writes:

> what is "the high byte of the target address of the operand"
> in the indirect-y case (93)?

I'd suppose it means what it says. If $FB=33, $FC=$71, .Y=0, the
result probably is the same as in the absolute case, only it takes
one more cycle to perform: AXA ($FB),Y

-- 
Anders Carlsson
0
Anders
4/25/2006 8:11:21 AM
It might have been naivety for some, but also perhaps the necessity for
obfuscation. I'm trying to get hold of original titles that used such
opcodes to see whether there was really a need or advantage.

Cheers,
Nick.

0
sicklittlemonkey
4/25/2006 8:13:05 AM
sicklittlemonkey wrote:
> It might have been naivety for some, but also perhaps the necessity for
> obfuscation. I'm trying to get hold of original titles that used such
> opcodes to see whether there was really a need or advantage.

There are infinitely many ways to make a program obscure without
making it hardware accident-dependent.  ;-)

-michael

Music synthesis 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."
0
Michael
4/25/2006 8:35:31 AM
On Tue, 25 Apr 2006, sicklittlemonkey wrote:

> It might have been naivety for some, but also perhaps the necessity for
> obfuscation. I'm trying to get hold of original titles that used such
> opcodes to see whether there was really a need or advantage.
>
> Cheers,
> Nick.

Ms. Pac-Man on the Apple ][:

The crack group used code involving, iirc, SLO, to verify that the 
signature was intact.  Oddly, it passes on a 65C02, but on an emulated 
6502 without illops it crashes into the monitor.

-uso.
0
Lyrical
4/25/2006 8:51:50 AM
Thanks for all your helpful replies, which are going to find their way 
into an AppleWin improvement soon, if all goes well.

I'm still not quite happy with some ugly details that I haven't seen 
documented too well:

1.) Operation of ARR ($6B) when the decimal flag is SET.

2.) Exact operation of decimal mode ADC and SBC in both the 6502 and the 
65C02.

I'll take a look at the VICE code first. Do you know of any other GOOD 
code for this?

Best wishes,
-- 
Linards Ticmanis
0
Linards
4/25/2006 9:48:08 AM
Actually there are some nice and reliable(!) opcodes which save space
and CPU time. Especially LAX, DCP, ISC and the various NOPs are used by
many homebrew programmers for the Atari 2600 console.

Just stay away from those which are marked as unreliable (e.g. see
http://oxyron.de/html/opcodes02.html)

0
tjentzsch
4/25/2006 10:38:40 AM
Don Bruder wrote:
> In article <j7Wdne2Ir5coidDZnZ2dnUVZ_vydnZ2d@comcast.com>,
>  "Michael J. Mahon" <mjmahon@aol.com> wrote:
> 
>> Since there were several versions of the 6502, isn't it likely that
>> some had *differing* illegal ops and results?
> 
> Not just likely - Absolutely certain. 
> 
> I've long since forgotten the source, but there used to be a listing of 
> how the various "illegal" opcodes differed from chip version to chip 
> version, and only a very tiny handful of them that worked on one version 
> would work (or even do ANYTHING) on another version. 

If we're talking of normal 6502's, then there are almost no differences 
on the illegal opcodes. There are ofcourse extended versions of the 6502 
like the 65CE02 or the 65C02, but these don't count since also the 
documented opcodes have changed...

If we're talking about the illegals and differences, the only thing 
which usually is different is the stability of some illegals, but if you 
know about these it is safe to use the stable ones or cancel out the 
unstability (by ANDing with 0's for example).
0
John
4/25/2006 10:42:56 AM
>>>>> "hm" == heuser marcus <heuser.marcus@freenet.de> writes:

hm> On the other hand I haven't seen an application where they were
hm> indispensable.

There are several C64 demo effects that could not have been done
without illegal opcodes. One good example is 6 sprites on top of an
FLI picture, done by Ninja in Darwin 80%:

  http://noname.c64.org/csdb/release/?id=12732

It's not just one or two illegals here and there either:

  9097   8D 11 D0   STA $D011
  909a   4F 18 D0   SRE $D018
  909d   8D 11 D0   STA $D011
  90a0   4F 02 DD   SRE $DD02
  90a3   8C 11 D0   STY $D011
  90a6   0E 18 D0   ASL $D018
  90a9   8F 11 D0   SAX $D011
  90ac   8C 02 DD   STY $DD02
  90af   8D 11 D0   STA $D011
  90b2   4F 18 D0   SRE $D018
  90b5   8D 11 D0   STA $D011
  90b8   6F 02 DD   RRA $DD02
  90bb   8D 11 D0   STA $D011
  90be   0F 18 D0   SLO $D018
  90c1   8E 11 D0   STX $D011
  90c4   8E 02 DD   STX $DD02
  90c7   8D 11 D0   STA $D011
  90ca   4F 18 D0   SRE $D018
  90cd   8D 11 D0   STA $D011
  90d0   4F 02 DD   SRE $DD02

They were also used in a lot of games - instructions like LAX, SAX are
easy to use and can save a couple of cycles in a critical place.

-- 
    ___          .     .  .         .       . +  .         .      o   
  _|___|_   +   .  +     .     +         .  Per Olofsson, arkadspelare
    o-o    .      .     .   o         +          MagerValp@cling.gu.se
     -       +            +    .     http://www.cling.gu.se/~cl3polof/
0
MagerValp
4/25/2006 12:16:34 PM
> Ms. Pac-Man on the Apple ][

Do you have the original to compare? Since a NOP illop works, it looks
like the functionality is not important. Also Moon Patrol (cracked)
seems to use a #$02 illop, which doesn't make sense since that's
JAM/HLT.

I bought Bug Attack to check the illops in that - when I get the ADT
cable working for my new //c ...

Cheers,
Nick.

0
sicklittlemonkey
4/25/2006 2:13:09 PM
In article <Pine.LNX.4.64.0604250450530.12677@localhost.localdomain>,
 Lyrical Nanoha <andi@dosius.ath.cx> wrote:

> The crack group used code involving, iirc, SLO, to verify that the 
> signature was intact.  Oddly, it passes on a 65C02, but on an emulated 
> 6502 without illops it crashes into the monitor.

Wow, that's the first I've heard of 6502 code using illegal opcodes that 
actually works on a 65C02.
0
Bruce
4/25/2006 3:43:43 PM
Linards Ticmanis <ticmanis@gmx.de> writes:

> Thanks for all your helpful replies, which are going to find their way
> into an AppleWin improvement soon, if all goes well.
> 
> I'm still not quite happy with some ugly details that I haven't seen
> documented too well:
> 
> 1.) Operation of ARR ($6B) when the decimal flag is SET.
> 
> 2.) Exact operation of decimal mode ADC and SBC in both the 6502 and
> the 65C02.

I have C code which emulates ADC and SBC for the 65C02 for all values of
the argments and flags.

> 
> I'll take a look at the VICE code first. Do you know of any other GOOD
> code for this?
> 
> Best wishes,
> -- 
> Linards Ticmanis

-- 
Scott Hemphill	hemphill@alumni.caltech.edu
"This isn't flying.  This is falling, with style."  -- Buzz Lightyear
0
Scott
4/25/2006 6:41:28 PM
Scott Hemphill wrote:
>> I'm still not quite happy with some ugly details that I haven't seen
>> documented too well:
>>
>> 1.) Operation of ARR ($6B) when the decimal flag is SET.
>>
>> 2.) Exact operation of decimal mode ADC and SBC in both the 6502 and
>> the 65C02.
> 
> I have C code which emulates ADC and SBC for the 65C02 for all values of
> the argments and flags.

Thanks Scott! I've copied the algorithm from VICE for now, but that is 
of course NMOS 6502 only, since Commodore never switched to the 65C02 
chips for their own computers. Thus I am very interested in your code 
for better coverage of 65C02. Would you mind posting it here or mailing 
it to me? My From address is valid.

All the Best,
-- 
Linards Ticmanis
0
Linards
4/25/2006 9:00:29 PM
Linards Ticmanis <ticmanis@gmx.de> writes:

> Scott Hemphill wrote:
> >> I'm still not quite happy with some ugly details that I haven't seen
> >> documented too well:
> >>
> >> 1.) Operation of ARR ($6B) when the decimal flag is SET.
> >>
> >> 2.) Exact operation of decimal mode ADC and SBC in both the 6502 and
> >> the 65C02.
> > I have C code which emulates ADC and SBC for the 65C02 for all
> > values of
> > the argments and flags.
> 
> Thanks Scott! I've copied the algorithm from VICE for now, but that is
> of course NMOS 6502 only, since Commodore never switched to the 65C02
> chips for their own computers. Thus I am very interested in your code
> for better coverage of 65C02. Would you mind posting it here or
> mailing it to me? My From address is valid.

OK, here it is.  A is the accumulator, b is the argument (an unsigned 8-bit
quantity).  V, D, and C are booleans which represent the state of the
corresponding flags.  NZ is a byte which holds the state of the N and Z
flags.  The N flag is set if (NZ & 0x80) is true, and the Z flag is set
if (NZ == 0) is true.  w is a 16-bit unsigned scratch location.

These instructions were tested by running a PRODOS program which combined
each of the 256 possible accumulator values with the 256 argument values.
The 64K combinations were output as a 128K file containing a one-byte result
and one byte of flags.  The program was edited to produce 8 different
versions:  (initial C set/clear)x(initial D set/clear)x(ADC/SBC).  The
program versions were run on a Laser 128/EX and on an emulator, and the
results compared.  (All of this was done about 20 years ago.)

#define ADC()                                        \
      do {                                           \
        if ((A^b) & 0x80) V = 0; else V = 1;         \
        if (D) {                                     \
          w = (A & 0xf) + (b & 0xf) + C;             \
          if (w >= 10) w = 0x10 | ((w+6)&0xf);       \
          w += (A & 0xf0) + (b & 0xf0);              \
          if (w >= 160) {                            \
            C = 1;                                   \
            if (V && w >= 0x180) V = 0;              \
            w += 0x60;                               \
          } else {                                   \
            C = 0;                                   \
            if (V && w < 0x80) V = 0;                \
          }                                          \
        } else {                                     \
          w = A + b + C;                             \
          if (w >= 0x100) {                          \
            C = 1;                                   \
            if (V && w >= 0x180) V = 0;              \
          } else {                                   \
            C = 0;                                   \
            if (V && w < 0x80) V = 0;                \
          }                                          \
        }                                            \
        A = (byte)w;                                 \
        NZ = A;                                      \
      } while (0)

#define SBC()                                        \
      do {                                           \
        if ((A^b) & 0x80) V = 1; else V = 0;         \
        if (D) {                                     \
          int tmp;                                   \
          tmp = 0xf + (A & 0xf) - (b & 0xf) + C;     \
          if (tmp < 0x10) {                          \
            w = 0;                                   \
            tmp -= 6;                                \
          } else {                                   \
            w = 0x10;                                \
            tmp -= 0x10;                             \
          }                                          \
          w += 0xf0 + (A & 0xf0) - (b & 0xf0);       \
          if (w < 0x100) {                           \
            C = 0;                                   \
            if (V && w < 0x80) V = 0;                \
            w -= 0x60;                               \
          } else {                                   \
            C = 1;                                   \
            if (V && w >= 0x180) V = 0;              \
          }                                          \
          w += tmp;                                  \
        } else {                                     \
          w = 0xff + A - b + C;                      \
          if (w < 0x100) {                           \
            C = 0;                                   \
            if (V && w < 0x80) V = 0;                \
          } else {                                   \
            C = 1;                                   \
            if (V && w >= 0x180) V = 0;              \
          }                                          \
        }                                            \
        A = (byte)w;                                 \
        NZ = A;                                      \
      } while (0)


-- 
Scott Hemphill	hemphill@alumni.caltech.edu
"This isn't flying.  This is falling, with style."  -- Buzz Lightyear
0
Scott
4/26/2006 2:39:51 AM
Scott Hemphill wrote:
> OK, here it is.  A is the accumulator, b is the argument (an unsigned 8-bit
> quantity).  V, D, and C are booleans which represent the state of the
> corresponding flags.  NZ is a byte which holds the state of the N and Z
> flags.  The N flag is set if (NZ & 0x80) is true, and the Z flag is set
> if (NZ == 0) is true.  w is a 16-bit unsigned scratch location.
> 
> These instructions were tested by running a PRODOS program which combined
> each of the 256 possible accumulator values with the 256 argument values.
> The 64K combinations were output as a 128K file containing a one-byte result
> and one byte of flags.  The program was edited to produce 8 different
> versions:  (initial C set/clear)x(initial D set/clear)x(ADC/SBC).  The
> program versions were run on a Laser 128/EX and on an emulator, and the
> results compared.  (All of this was done about 20 years ago.)

[code snipped]

Thanks a lot! Luckily the problem is small enough to allow for such 
complete verification, but I'm still glad I don't have to do it myself.

The only question that remains: is it true that the 65C02 take one extra 
cycle for ADC/SBC when then D flag is set? I'll have a look at the 
official data sheet.

-- 
Linards Ticmanis
0
Linards
4/26/2006 12:44:47 PM
Linards Ticmanis <ticmanis@gmx.de> wrote:

> The only question that remains: is it true that the 65C02 take one extra
> cycle for ADC/SBC when then D flag is set? I'll have a look at the 
> official data sheet.

Yes, according to information in the data sheets (which I don't have
handy and can't verify).

The issue is that the original 6502 didn't implement all of the status
flags for ADC/SBC in decimal mode: the N flag in particular is not
updated (also the V flag, if I remember right). The Z and C flags are
handled correctly.

On the 65C02 they fixed the N flag for ADC/SBC in decimal mode (and
presumably also the V flag), but in order to do so they had to increase
the execution time of the instruction by one cycle (which only applies
if in decimal mode - in normal/binary mode, execution time is identical
to the 6502).

The 65802/65816 fixed it in a better way, restoring the original
execution time of the 6502.

This little detail (N flag not implemented for ADC/SBC in decimal mode
on the 6502) was used by a routine published in "Programming the 65816
et. al." by David Eyes & Ron Lichty which detected whether your code was
running on a 6502 or something later. A separate test was used to
distinguish between the 65C02 and 65802/65816, relying on the fact that
all undefined opcodes on the 65C02 are guaranteed to be NOPs, unlike the
behaviour of the 6502, so once the decimal ADC had revealed you weren't
on a 6502, it was safe to try using single-byte 65802/65816 instructions
(they would act like NOPs if you have a 65C02).

I recently reposted my extended version of this routine, which also
detects the Rockwell R65C02 and copes with the 65802/65816 running in
native mode with 8-bit registers rather than requiring it to be in
emulation mode (but my routine would also fail if the 65802/65816 was in
native mode with 16-bit registers).
-- 
David Empson
dempson@actrix.gen.nz
0
dempson
4/26/2006 1:05:22 PM
David Empson wrote:

>> The only question that remains: is it true that the 65C02 take one extra
>> cycle for ADC/SBC when then D flag is set? I'll have a look at the 
>> official data sheet.
> 
> Yes, according to information in the data sheets (which I don't have
> handy and can't verify).
> 
> The issue is that the original 6502 didn't implement all of the status
> flags for ADC/SBC in decimal mode: the N flag in particular is not
> updated (also the V flag, if I remember right). The Z and C flags are
> handled correctly.

Accoriding to the algorithm used in VICE, the N and V flags are updated, 
but according to a bunch of crazy formulae which are quite useless 
(unless you're a hardcore demo coder maybe). So you can't rely on them 
staying unchanged either. Nothing's quite as bad as the ARR illegal of 
the NMOS 6502 though (which combines fragments of ADC with fragments of 
ASL and some internal bus contentions, as it seems).

-- 
Linards Ticmanis
0
Linards
4/26/2006 1:12:25 PM
David Empson wrote:

> Yes, according to information in the data sheets (which I don't have
> handy and can't verify).

BTW the 65C02 data sheet is available from WDC as I just found out:

> http://www.westerndesigncenter.com/wdc/datasheets/w65c02s.pdf

Though AFAIK the old 65C02 in the Apple lacked the WAI, STP, BBSx and 
BBRx instructions, right? Since they're not emulated by the old Applewin 
code.

-- 
Linards Ticmanis
0
Linards
4/26/2006 1:15:33 PM
On Wed, 26 Apr 2006, Linards Ticmanis wrote:

>
>
> David Empson wrote:
>
>> Yes, according to information in the data sheets (which I don't have
>> handy and can't verify).
>
> BTW the 65C02 data sheet is available from WDC as I just found out:
>
>> http://www.westerndesigncenter.com/wdc/datasheets/w65c02s.pdf
>
> Though AFAIK the old 65C02 in the Apple lacked the WAI, STP, BBSx and BBRx 
> instructions, right? Since they're not emulated by the old Applewin code.
>
> -- 
> Linards Ticmanis
>

I wouldn't count on them being there, anyway.

-uso.
0
Lyrical
4/26/2006 2:23:19 PM
Linards Ticmanis <ticmanis@gmx.de> wrote:

> David Empson wrote:
> 
> > Yes, according to information in the data sheets (which I don't have
> > handy and can't verify).
> 
> BTW the 65C02 data sheet is available from WDC as I just found out:

I thought as much. I couldn't be bothered looking, and all my Apple II
books are packed away in the basement now (and unlikely to be accessed
again for a while).

> > http://www.westerndesigncenter.com/wdc/datasheets/w65c02s.pdf
> 
> Though AFAIK the old 65C02 in the Apple lacked the WAI, STP, BBSx and
> BBRx instructions, right? Since they're not emulated by the old Applewin
> code.

Not sure about WAI or STP (I seem to recall them being new opcodes on
the 65802/65816). The main ones I recall being added were TSB, TRB, STZ
and BRA plus a few more addressing modes on existing instructions, such
as LDA (etc.) indirect and JSR pre-indexed absolute indirect.

The BBSx, BBRx, SMBx and RMBx instructions are not standard 65C02
opcodes. They were added by Rockwell in their R65C02 and apparently were
also included in some of their earlier R6500 series as well.

A standard 65C02 based on the original specification from WDC does not
have any of these instructions: all of the x3, x7, xB and xF opcodes are
NOPs. These opcodes are used on the 65802/65816 for new addressing modes
and other miscellaneous instructions.

Apple only used the WDC 65C02 or second sources with identical
instruction sets: GTE was most common in my observations; apparently
they also used a Rockwell 65C02 without the extra R65C02 instructions. I
have seen an R65C02 in some IIe clones.

-- 
David Empson
dempson@actrix.gen.nz
0
dempson
4/26/2006 3:20:27 PM
> BTW the 65C02 data sheet is available from WDC as I just found out:
>
> > http://www.westerndesigncenter.com/wdc/datasheets/w65c02s.pdf

Here is the one for the Rockwell R65C02 for comparison:

http://www.6502.org/documents/datasheets/rockwell/rockwell_r65c00_microprocessors.pdf

bye
Marcus

0
heuser
4/26/2006 3:31:43 PM
tjentzsch@yahoo.de wrote:

> Just stay away from those which are marked as unreliable (e.g. see
> http://oxyron.de/html/opcodes02.html)

Which is all of them; the 65C02 and 65816 treat all unused opcodes as
NOP. If you're writing code for the Apple II it's not even worth
considering. Even older Apple II's often have 65C02's fitted nowadays,
either as a replacement or via an accelerator card.

Matt

0
mdj
5/11/2006 12:47:38 AM
mdj wrote:
> tjentzsch@yahoo.de wrote:
> 
>> Just stay away from those which are marked as unreliable (e.g. see
>> http://oxyron.de/html/opcodes02.html)
> 
> Which is all of them;

No? Only two are completely unstable and 6 are "unstable in certain 
aspects" but you can use them if you avoid the unstable conditions.

> the 65C02 and 65816 treat all unused opcodes as
> NOP. If you're writing code for the Apple II it's not even worth
> considering.

Some illegals are quite useful, like SHX/SHY which in some cases can be 
used as STX absolute,Y / STY absolute,X if you use the right. Also you 
can do a CPU test and use different code on different CPUs. The demo 
"Oneder/Oxyron" does this. It works on 6502 with illegal opcodes, and on 
65816 it uses a slower but illegal-free code.
0
John
5/11/2006 11:59:11 AM
John Selck wrote:

> Some illegals are quite useful, like SHX/SHY which in some cases can be
> used as STX absolute,Y / STY absolute,X if you use the right. Also you
> can do a CPU test and use different code on different CPUs. The demo
> "Oneder/Oxyron" does this. It works on 6502 with illegal opcodes, and on
> 65816 it uses a slower but illegal-free code.

This is reasonable on the C64 where all machines were fitted with
6502's, and in the case of a 65816 it's accelerated, so a slower code
section is acceptable.

The Apple II series is essentially 3 platforms, and 3 CPU generations,
all backwards compatible.

I'll concede there is a potential fringe case where a piece of code was
so tight that downconverting from 65C02 to 6502 broke it, and it was
fixable using an undocumented instruction. Damned if I can think of an
example though; there's almost always another way to find a cycle or
two.

Matt

0
mdj
5/12/2006 1:32:50 AM
mdj wrote:
> John Selck wrote:
> 
> 
>>Some illegals are quite useful, like SHX/SHY which in some cases can be
>>used as STX absolute,Y / STY absolute,X if you use the right. Also you
>>can do a CPU test and use different code on different CPUs. The demo
>>"Oneder/Oxyron" does this. It works on 6502 with illegal opcodes, and on
>>65816 it uses a slower but illegal-free code.
> 
> 
> This is reasonable on the C64 where all machines were fitted with
> 6502's, and in the case of a 65816 it's accelerated, so a slower code
> section is acceptable.
> 
> The Apple II series is essentially 3 platforms, and 3 CPU generations,
> all backwards compatible.
> 
> I'll concede there is a potential fringe case where a piece of code was
> so tight that downconverting from 65C02 to 6502 broke it, and it was
> fixable using an undocumented instruction. Damned if I can think of an
> example though; there's almost always another way to find a cycle or
> two.

And in any case, depending on the peculiarities of a particular chip
implementation is just asking to be locked out of future improvements.

-michael

Music synthesis 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."
0
Michael
5/12/2006 2:21:59 AM
In article <1147397570.212608.111710@i40g2000cwc.googlegroups.com>,
 "mdj" <mdj.mdj@gmail.com> wrote:

> John Selck wrote:
> 
> > Some illegals are quite useful, like SHX/SHY which in some cases can be
> > used as STX absolute,Y / STY absolute,X if you use the right. Also you
> > can do a CPU test and use different code on different CPUs. The demo
> > "Oneder/Oxyron" does this. It works on 6502 with illegal opcodes, and on
> > 65816 it uses a slower but illegal-free code.
> 
> This is reasonable on the C64 where all machines were fitted with
> 6502's, and in the case of a 65816 it's accelerated, so a slower code
> section is acceptable.
> 
> The Apple II series is essentially 3 platforms, and 3 CPU generations,
> all backwards compatible.

And of course you've neglected to mention the other major 6502 computer 
series of the era, Atari.  They never used anything but a standard 6502 
core (but with an extra pin added to make DMA easier), so the 65C02 and 
65816 were never an issue.  In fact, Atari's 6502C with the extra signal 
meant that you _couldn't_ just drop a 65C02 into the same socket.

This was even less of an issue on the 2600, which always used a 6507, 
which is a standard 6502 die in a reduced pin count package.  Quite a 
few games used illegal opcodes to reduce cycle count so that they could 
do things that were otherwise impossible with its clock-locked 1-D 
graphics chip.

Oddly enough, the Apple II is where I heard most about people using 
illegal opcodes and side effects like JSR ($xxFF) back in the day, as a 
way to obfuscate copy-protection code.  Like I cared, because I had a 
TRS-80 (then a CoCo, and a 128K Mac), and most of the Z-80 undocumented 
opcodes were obvious, even when they weren't useful.  And none of the 
6809 undocumented opcodes were useful at all, except there was one that 
would do an SWI (equivalent to 6502 BRK) through the FIRQ vector and 
another that would jump through the RESET vector.
0
Bruce
5/12/2006 2:01:06 PM
Bruce Tomlin wrote:
> In article <1147397570.212608.111710@i40g2000cwc.googlegroups.com>,
>  "mdj" <mdj.mdj@gmail.com> wrote:
> 
> 
>>John Selck wrote:
>>
>>
>>>Some illegals are quite useful, like SHX/SHY which in some cases can be
>>>used as STX absolute,Y / STY absolute,X if you use the right. Also you
>>>can do a CPU test and use different code on different CPUs. The demo
>>>"Oneder/Oxyron" does this. It works on 6502 with illegal opcodes, and on
>>>65816 it uses a slower but illegal-free code.
>>
>>This is reasonable on the C64 where all machines were fitted with
>>6502's, and in the case of a 65816 it's accelerated, so a slower code
>>section is acceptable.
>>
>>The Apple II series is essentially 3 platforms, and 3 CPU generations,
>>all backwards compatible.
> 
> 
> And of course you've neglected to mention the other major 6502 computer 
> series of the era, Atari.  They never used anything but a standard 6502 
> core (but with an extra pin added to make DMA easier), so the 65C02 and 
> 65816 were never an issue.  In fact, Atari's 6502C with the extra signal 
> meant that you _couldn't_ just drop a 65C02 into the same socket.

That was DMA for video RAM acces, right?  If so, they just didn't get
how trivial it is to share RAM with a 6502--it only accesses RAM during
half the clock signal!

> This was even less of an issue on the 2600, which always used a 6507, 
> which is a standard 6502 die in a reduced pin count package.  Quite a 
> few games used illegal opcodes to reduce cycle count so that they could 
> do things that were otherwise impossible with its clock-locked 1-D 
> graphics chip.

It's kind of a self-fulfilling prophecy.  If enough people write
applications that depend on undocumented behavior, then that behavior
becomes a "feature" that cannot be changed in future versions--usually
preventing useful improvements.

(Not that I think of the 65C02 as much of an improvement.  All the
changes made in the 65C02 were what is known technically in the
computer architecture community as "mouse nuts".  ;-)

> Oddly enough, the Apple II is where I heard most about people using 
> illegal opcodes and side effects like JSR ($xxFF) back in the day, as a 
> way to obfuscate copy-protection code.  Like I cared, because I had a 
> TRS-80 (then a CoCo, and a 128K Mac), and most of the Z-80 undocumented 
> opcodes were obvious, even when they weren't useful.  And none of the 
> 6809 undocumented opcodes were useful at all, except there was one that 
> would do an SWI (equivalent to 6502 BRK) through the FIRQ vector and 
> another that would jump through the RESET vector.

There were a few cases of using undocumented behavior to obfuscate, but
it was never much more than a curiosity on the Apple II platform.

-michael

Music synthesis 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."
0
Michael
5/13/2006 12:44:01 AM
> It's kind of a self-fulfilling prophecy.  If enough people write applications
> that depend on undocumented behavior, then that behavior becomes
> a "feature" that cannot be changed in future versions--usually
> preventing useful improvements.

IMHO Atari didn't even seriously consider replacing the 6502. The 8-bit
platform was virtually unchanged for ten years. The machines were cash
cows and the Tramiel-aera Atari concentrated in making them cheaper and
cheaper (to compete with Commodore and reach the Eastern Europe market)
- so there was small room to get innovative.

The case with the 2600 is even clearer IMHO: It used the cheaper 6507
and the video game market crash in 1983 did the rest.

I really don't think that Atari even had the telephone number of WDC...

> (Not that I think of the 65C02 as much of an improvement.  All the
> changes made in the 65C02 were what is known technically in the
> computer architecture community as "mouse nuts".  ;-)

Ha ha - now that's a technical term I can learn quickly!

bye
Marcus

0
heuser
5/13/2006 5:28:00 AM
In article <b_2dnVaBwopOtvjZRVn-uQ@comcast.com>,
 "Michael J. Mahon" <mjmahon@aol.com> wrote:

> That was DMA for video RAM acces, right?  If so, they just didn't get
> how trivial it is to share RAM with a 6502--it only accesses RAM during
> half the clock signal!

As I understand it, they actually halted the CPU for DMA so as to get 
more memory bandwidth than "half the clock signal", and they needed to 
know when the CPU had actually stopped so that they could start DMA.  
This was also done on the Atari 7800.

I've heard that in the original 400/800 they actually used a regluar 
6502, but the extra signal allowed them to save all the external 
circuitry that figured this out.

Again, I grew up on the TRS-80, so all of this is stuff that I've 
learned about the old Atari hardware in the past five years or so.
0
Bruce
5/13/2006 2:56:51 PM
heuser.marcus@freenet.de wrote:
>>It's kind of a self-fulfilling prophecy.  If enough people write applications
>>that depend on undocumented behavior, then that behavior becomes
>>a "feature" that cannot be changed in future versions--usually
>>preventing useful improvements.
> 
> 
> IMHO Atari didn't even seriously consider replacing the 6502. The 8-bit
> platform was virtually unchanged for ten years. The machines were cash
> cows and the Tramiel-aera Atari concentrated in making them cheaper and
> cheaper (to compete with Commodore and reach the Eastern Europe market)
> - so there was small room to get innovative.

So it seems the message is, "If you have good reason to believe that
you are programming for an 'end of the line' platform, then do anything
that works--it won't matter anyway".

Of course, now *all* 8-bit platforms are unchanging, but some of them,
in particular the Apple II, went through several implementations of
the processor.

So, even though I don't feel any need to provide for *future* changes,
I still am motivated to cover all the *past* changes, by coding for the
widest range of systems that makes sense--particularly since there is a
negligible "cost" of doing so.

> The case with the 2600 is even clearer IMHO: It used the cheaper 6507
> and the video game market crash in 1983 did the rest.

In the case of a video game machine, I wouldn't expect any compatible
upgrade path, and the entire hardware arrangement was very ideosyncratic
anyway--so there would be no reason not to do "anything that worked".

-michael

Music synthesis 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."
0
Michael
5/14/2006 5:52:57 AM
Bruce Tomlin wrote:
> In article <b_2dnVaBwopOtvjZRVn-uQ@comcast.com>,
>  "Michael J. Mahon" <mjmahon@aol.com> wrote:
> 
> 
>>That was DMA for video RAM acces, right?  If so, they just didn't get
>>how trivial it is to share RAM with a 6502--it only accesses RAM during
>>half the clock signal!
> 
> 
> As I understand it, they actually halted the CPU for DMA so as to get 
> more memory bandwidth than "half the clock signal", and they needed to 
> know when the CPU had actually stopped so that they could start DMA.  
> This was also done on the Atari 7800.

Wow--they needed more than a megabyte/second of video data?  I guess
if you have about the same resolution as an Apple II, but twice the
color depth, then you do...  The //c and following Apple II's got
around this by providing another memory bank in parallel with the
main memory bank.

> I've heard that in the original 400/800 they actually used a regluar 
> 6502, but the extra signal allowed them to save all the external 
> circuitry that figured this out.

Of course, all 6502's had the RDY line that allowed a trivial amount
of glue logic to halt the CPU between instructions.  (Of course, you
couldn't get away with this during a Disk ][ I/O on the Apple II, since
it would mess up the instruction timing.)

-michael

Music synthesis 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."
0
Michael
5/14/2006 5:59:06 AM
> So it seems the message is, "If you have good reason to believe that
> you are programming for an 'end of the line' platform, then do anything
> that works--it won't matter anyway".

In my opinion this approach is too fatalistic - after all Commodore and
Atari didn't really offer CPU-upgrades. The C128 is more or less
completely compatible (illegal opcodes supported) and Atari didn't
offer anything faster or based on a more modern chip.

Therefore their programmers (third party or hobbyists) never really had
to worry about doing something "illegal" when using these opcodes.

Apple on the other hand introduced the IIc quite early in comparison.
It's success and the subsequent enhancement kit for the IIe /
modernized IIe effectively killed the usage of these opcodes in the
Apple world. Side note: I would love to hear from Apple why they chose
the 65C02 - because of the much less power using CMOS design or the
additional features...

And then of course came the 68K-platforms and took over the market...

> In the case of a video game machine, I wouldn't expect any compatible
> upgrade path, and the entire hardware arrangement was very ideosyncratic
> anyway--so there would be no reason not to do "anything that worked".

Good points.

What would be interesting to know is when did the 6502 programmers
begin using illegal/undocumented opcodes. Right from the start? I
vaguely remember hearing about them first in the mid-eighties.

bye
Marcus

0
heuser
5/14/2006 8:34:33 AM
> Wow--they needed more than a megabyte/second of video data?
> I guess if you have about the same resolution as an Apple II, but twice
> the color depth, then you do...  The //c and following Apple II's got
> around this by providing another memory bank in parallel with the
> main memory bank.

The Atari and C64 use an official maximum of 8K RAM for the frame
buffer. The C64 has an additional kilobyte for color information which
is accessed in parallel, AFAIK. So they are comparable to an Apple
without double-hires mode.

The Atari has some possibilities to double the memory by page flipping
but this halves the screen refresh rate. Its also possible to change
the video mode in the middle of a scan line - but this results only in
a different "color interpretion" of the memory cells, not actually
"more" memory cells.

The C64 supports some advanced trickery to do some more colors than
initially thought and officially advertised but this is again more for
static displays.

I can't really speak technically for the C64 but in the case of the
Atari the situation is more complicated than in a "standard" Apple: The
video processor (ANTIC) really takes over the system for the time it
halts the 6502.

You see, ANTIC really is an, albeit very very simple, processor: It has
its own instructions, programs (called display lists) and memory. In
fact in can access the complete RAM, ROM and even the custom chip
register area of the system. This means that you can for example
display a "live view" of the zero page and stack with memory cells
changing all the time...

So I guess Atari chose to keep it simple in making this "multiprocessor
system" work by stopping the 6502 for the moment when ANTIC needs to
maintain the display.

The effect was quite drastic on performance so they clocked the 6502
much higher than in the Apple or C64 system (1,78 MHz). In the end all
three systems were comparable in speed when using the same video
resolutions or text mode.
When ANTIC is switched off the computer is indeed much faster - a
feature of the popular fractal generators of the time.

> Of course, all 6502's had the RDY line that allowed a trivial amount
> of glue logic to halt the CPU between instructions.  (Of course, you
> couldn't get away with this during a Disk ][ I/O on the Apple II, since
> it would mess up the instruction timing.)

The Atari and C64 could - with careful programming - even use clean
display interrupts (to change colors or the scroll registers on the
fly) while accessing the disk. But that's mainly due to the more
intelligent disk drive designs - and the slow disk accesses...

bye
Marcus

0
heuser
5/14/2006 9:05:38 AM
>>>>> "MJM" == Michael J Mahon <mjmahon@aol.com> writes:

MJM> Wow--they needed more than a megabyte/second of video data?

No, but they need more than one byte per clock cycle, in some
situations. The C64 does the same thing, during badlines and sprite
access. So yes, if you fill the screen with badlines and cover it with
sprites, you would theoretically need about 2 MB/s, but in reality you
only need it in short bursts.

-- 
    ___          .     .  .         .       . +  .         .      o   
  _|___|_   +   .  +     .     +         .  Per Olofsson, arkadspelare
    o-o    .      .     .   o         +          MagerValp@cling.gu.se
     -       +            +    .     http://www.cling.gu.se/~cl3polof/
0
MagerValp
5/14/2006 11:30:20 AM
heuser.marcus@freenet.de wrote:
>>So it seems the message is, "If you have good reason to believe that
>>you are programming for an 'end of the line' platform, then do anything
>>that works--it won't matter anyway".
> 
> 
> In my opinion this approach is too fatalistic - after all Commodore and
> Atari didn't really offer CPU-upgrades. The C128 is more or less
> completely compatible (illegal opcodes supported) and Atari didn't
> offer anything faster or based on a more modern chip.
> 
> Therefore their programmers (third party or hobbyists) never really had
> to worry about doing something "illegal" when using these opcodes.

That's what "end of the line" platform means.  No upgrades.

The fact that both companies used "custom" 6502 processors for their
machines is no doubt part of the reason that they never moved forward.

> Apple on the other hand introduced the IIc quite early in comparison.
> It's success and the subsequent enhancement kit for the IIe /
> modernized IIe effectively killed the usage of these opcodes in the
> Apple world. Side note: I would love to hear from Apple why they chose
> the 65C02 - because of the much less power using CMOS design or the
> additional features...

I think it was simply a matter of a modern design with multiple sources.
The ASICs in the //c and //e changed the setup and hold times so that
a 2MHz processor was needed to run reliably at 1MHz, and I'm sure there
was no quantity source for 2MHz NMOS processors by that time.

> And then of course came the 68K-platforms and took over the market...

I'm not sure I'd agree with that assessment.  But it is certainly
true that 68K-heads took over the Apple management team.  ;-)

>>In the case of a video game machine, I wouldn't expect any compatible
>>upgrade path, and the entire hardware arrangement was very ideosyncratic
>>anyway--so there would be no reason not to do "anything that worked".
> 
> 
> Good points.
> 
> What would be interesting to know is when did the 6502 programmers
> begin using illegal/undocumented opcodes. Right from the start? I
> vaguely remember hearing about them first in the mid-eighties.

Right from the start.  The first people to play with 6502s were the
hard-core experimenters, and for them, you take it all apart and put
it back together before you even turn it on the first time.  ;-)

It's only after you begin to think that code you write may be useful
on future extensions of a platform that portablity and definitions
become important.

Non-portable code is written for two quite different reasons:

1) Because the coder doesn't even think about portability or
    doesn't understand it, non-portablility happens.
2) Because the coder understands perfectly, and chooses to
    write non-portable code on purpose.  (One-time use, static
    platform, compelling need,...?)

-michael

Music synthesis 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."
0
Michael
5/14/2006 7:04:11 PM
<heuser.marcus@freenet.de> wrote ...
>
> What would be interesting to know is when did the 6502 programmers
> begin using illegal/undocumented opcodes. Right from the start? I
> vaguely remember hearing about them first in the mid-eighties.

I remember hearing about undocumented opcodes in the mid 80's.  But I don't
think I heard the term "illegal opcodes" was used in the Commodore world back
then.  Perhaps what was called "undocumented" in the Commodore world was
called "illegal" in the Apple world?

Then, when the two worlds crossed paths via Usenet the difference between
illegal and undocumented became blurred.  I suppose we will get over it when
all the 8-bit processors die and go to silicon heaven.    :-)
-- 
Best regards,

Sam Gillett

Change is inevitable,
except from vending machines!



0
Sam
5/14/2006 7:28:25 PM
> I suppose we will get over it when all the 8-bit processors die and
> go to silicon heaven.    :-)

Never, then.

;o)

bye
Marcus

0
heuser
5/14/2006 7:54:20 PM
Sam Gillett wrote:
> <heuser.marcus@freenet.de> wrote ...
> 
>>What would be interesting to know is when did the 6502 programmers
>>begin using illegal/undocumented opcodes. Right from the start? I
>>vaguely remember hearing about them first in the mid-eighties.
> 
> 
> I remember hearing about undocumented opcodes in the mid 80's.  But I don't
> think I heard the term "illegal opcodes" was used in the Commodore world back
> then.  Perhaps what was called "undocumented" in the Commodore world was
> called "illegal" in the Apple world?

The difference between the two terms is dependent on point of view.

The chip/system designer tends to regard undocumented or undefined
behavior as the territory reserved for future expansion.  Of course,
if the space is not protected, either by trapping or by behaving
as a NOP, then it is "reserved" only by convention, not by silicon.

The on-the-metal programmer sometimes feels that "undefined" is just
an invitation to experiment, and proceeds to at least document, if
not define, the actions that the chip designer did not intend and
has no intention to preserve.

If a chip/system is successful, there comes a time when follow-on
designs are done.  If the officially undefined behaviors have become
sufficiently widely used, then they represent a barrier to the orderly
expansion of the design--such as new instructions requiring previously
undefined opcodes that may have been widely, but unwisely, used.

The new designer quickly comes to resent any such barriers, and would
therefore like to think of them as prohibited, or "illegal", but what
is really missing is discipline--on the part of the original designer,
who failed to "protect" the undefined space (to save a few transistors),
and on the part of coders who couldn't resist the temptation to use
whatever they found--even without any guarantee of future support
(to save a cycle or two).

Ironically, the combination of these two lapses in discipline can result
in there being no acceptable space for the expansion of a design, and
therefore they mortgage the future for a pittance today.

(If it isn't obvious, I've played both the designer's part and, earlier,
the coder's part.  ;-)

-michael

Music synthesis 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."
0
Michael
5/14/2006 10:42:08 PM
Michael J. Mahon <mjmahon@aol.com> wrote:
> is really missing is discipline--on the part of the original designer,
> who failed to "protect" the undefined space (to save a few transistors),

Not really.  At the time every gate on the chip was expensive and saving
them was a valid concern.  When I studied VLSI design we called these
undefined cased "Don't care" conditions; invalid input meant we didn't
care about the output.  You can see this on some cheap LED digital
clocks where pressing wierd button combinations can cause odd displays;
invalid input.  That can actually cut down the number of gates by 20%
or more and so reduce the cost, accordingly.

Handling these "don't care" conditions actually requires a level of
optimisation which doesn't exist in a naive design.  So it's not a case
of the designers failing to protect the undefined space, but of them
optimising the circuitry for efficiency.

It is a valid design decision.

With the 6502 essentially not having a microcode level, this
optimisation is exposed to the programmer.  This also shows up in the
regularity of the opcodes, and allowed hackers to make educated guesses
as to what the undocumented codes could do.

-- 
                                 Stephen  Harris
                                usenet@spuddy.org
      The truth is the truth, and opinion just opinion.  But what is what?
       My employer pays to ignore my opinions; you get to do it for free.
0
usenet
5/15/2006 12:08:12 AM
Stephen Harris wrote:
> Michael J. Mahon <mjmahon@aol.com> wrote:
> 
>>is really missing is discipline--on the part of the original designer,
>>who failed to "protect" the undefined space (to save a few transistors),
> 
> 
> Not really.  At the time every gate on the chip was expensive and saving
> them was a valid concern.  When I studied VLSI design we called these
> undefined cased "Don't care" conditions; invalid input meant we didn't
> care about the output.  You can see this on some cheap LED digital
> clocks where pressing wierd button combinations can cause odd displays;
> invalid input.  That can actually cut down the number of gates by 20%
> or more and so reduce the cost, accordingly.

True, but the decoding in the 6502 is handled by a kind of PLA, so
it would likely not be very expensive (in real estate) to trap or
NOP the invalid combinations.

But your point is well taken, it's a tradeoff of the present vs.
the future of your chip.

> Handling these "don't care" conditions actually requires a level of
> optimisation which doesn't exist in a naive design.  So it's not a case
> of the designers failing to protect the undefined space, but of them
> optimising the circuitry for efficiency.
> 
> It is a valid design decision.

Yes, but not without implications for the future--see above.
The 6502 was already a much less expensive processor than its
competitors, because of a mask retouching technique MOS Technology
developed that saved mask iterations.

Admittedly, though, the microprocessor design culture at that time
was not oriented toward "protecting" undefined space, as they all
have been in the years since.

When you have just done it, you aren't weighting how you will proceed
over the next 15 years very highly.  ;-)

> With the 6502 essentially not having a microcode level, this
> optimisation is exposed to the programmer.  This also shows up in the
> regularity of the opcodes, and allowed hackers to make educated guesses
> as to what the undocumented codes could do.

Right--with all the negative implications for the future that I
discussed.

I was discussing the nature of the "undefined" problem in general,
and in light of current practice.  If I had been designing the 6502,
I likely would have made the same choice.  (But as a coder, I would
have regarded undefined ops as a curiosity, not as an opportunity
to save a few cycles at the expense of future utility.)

-michael

Music synthesis 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."
0
Michael
5/15/2006 4:31:04 AM
In article <d4CdnR_y__CUmfXZnZ2dnUVZ_s-dnZ2d@comcast.com>,
 "Michael J. Mahon" <mjmahon@aol.com> writes:
|> True, but the decoding in the 6502 is handled by a kind of PLA, so
|> it would likely not be very expensive (in real estate) to trap or
|> NOP the invalid combinations.

You are too today-centric.

Back in the 1970s even that "likely not very expensive" decision raised
the costs significantly and introduced complexity to the chip which was 
unnecessary from a technical and marketing point of view.

|> If I had been designing the 6502,
|> I likely would have made the same choice.

Probably everyone would have. Leaving out the illegal opcode traps or
mapping them to NOP did no harm, implementing them would just raise
costs.

|> (But as a coder, I would have regarded undefined ops as a curiosity, 
|> not as an opportunity to save a few cycles at the expense of future 
|> utility.)

If a platform stays identical over a long-enough period of time
then why not starting to squeeze the last out of it by using undocumented
behavior. After all, the use of such undocumented behavior in the end 
led to enhanced capabilities, even the chip designers didn't envision
in the first place.

I'm especially thinking about all the fancy stuff coders did with the
C64's video chip, which like the original 6502 (and the hereon based 6510) 
is a hardwired design.

And back then noone really thought about future utility. Maybe apart from
the Apple II those machines were pretty much integrated & rather unexpandable
boxes -- even more, in the early homecomputer and video game market there was 
no sense for a "family concept" where software from the old machine would just 
run on its next generation successor, cause that most likely was an entirely
new box.

Think of Atari 400/800 vs. 600/800XL, Commodore VIC20 vs. C64, Sinclair ZX81
vs. Spectrum just to name a few.

Rainer
0
buchty
5/15/2006 9:58:26 AM
Michael J. Mahon <mjmahon@aol.com> wrote:


> Stephen Harris wrote:
> > Not really.  At the time every gate on the chip was expensive and saving
> > them was a valid concern.  When I studied VLSI design we called these
> > undefined cased "Don't care" conditions; invalid input meant we didn't
> > care about the output.  You can see this on some cheap LED digital
> > clocks where pressing wierd button combinations can cause odd displays;
> > invalid input.  That can actually cut down the number of gates by 20%
> > or more and so reduce the cost, accordingly.

> True, but the decoding in the 6502 is handled by a kind of PLA, so
> it would likely not be very expensive (in real estate) to trap or
> NOP the invalid combinations.

Remember, the 6502 was designed in 1975.  Every single gate was expensive.
Optimisation of the "don't care" conditions was an important skill that
had a very real impact on the production cost.  Cost was important on this
chip, being a lot cheaper than the competition.

Note that when WDC designed the CMOS version of the chip (65C02) they _did_
NOP the undefined instructions but that was a later design using newer
technologies (CMOS vs NMOS).

> I likely would have made the same choice.  (But as a coder, I would
> have regarded undefined ops as a curiosity, not as an opportunity
> to save a few cycles at the expense of future utility.)

The home computer I'm most used to that used the R6502 (the Rockwell
version) at 2Mhz was the Acorn BBC Micro.  About the only programs that
used the undocumented codes were games that used them for disassembly
protection; most disassemblers at the time didn't recognise them so
would display a single ??? and then try to decode the next byte as an
opcode.  Since the R6502 really treated it as a 2 or 3 byte NOP this
caused bad dissassembly.  Later disassemblers were updated to handle
this :-)

It caused some minor issues, though, when the BBC Master came out, which
used the 65C02.  Oops!  Magazines at the time would publish "hacks" to
fix the few popular rogue programs :-)

-- 
                                 Stephen  Harris
                                usenet@spuddy.org
      The truth is the truth, and opinion just opinion.  But what is what?
       My employer pays to ignore my opinions; you get to do it for free.
0
usenet
5/15/2006 1:35:13 PM
> And back then noone really thought about future utility. Maybe apart from
> the Apple II those machines were pretty much integrated & rather unexpandable
> boxes -- even more, in the early homecomputer and video game market there was
> no sense for a "family concept" where software from the old machine would just
> run on its next generation successor, cause that most likely was an entirely
> new box.
> Think of Atari 400/800 vs. 600/800XL, Commodore VIC20 vs. C64, Sinclair ZX81
> vs. Spectrum just to name a few.

The Ataris are not a good example - they are mostly compatible
(hardware and software). Think of their 8-bit machines simply as
"family members" - not different hardware generations like the other
machines.

bye
Marcus

0
heuser
5/15/2006 4:15:59 PM
In article <d4CdnR_y__CUmfXZnZ2dnUVZ_s-dnZ2d@comcast.com>,
 "Michael J. Mahon" <mjmahon@aol.com> wrote:

> True, but the decoding in the 6502 is handled by a kind of PLA, so
> it would likely not be very expensive (in real estate) to trap or
> NOP the invalid combinations.

Nope, it's handled by good old random logic.  A PLA is designed to be a 
programmable generic replacement for random logic, and is way too 
inefficient for high-volume VLSI.
0
Bruce
5/15/2006 4:16:28 PM
Bruce Tomlin wrote:
> In article <d4CdnR_y__CUmfXZnZ2dnUVZ_s-dnZ2d@comcast.com>,
>  "Michael J. Mahon" <mjmahon@aol.com> wrote:
> 
> 
>>True, but the decoding in the 6502 is handled by a kind of PLA, so
>>it would likely not be very expensive (in real estate) to trap or
>>NOP the invalid combinations.
> 
> 
> Nope, it's handled by good old random logic.  A PLA is designed to be a 
> programmable generic replacement for random logic, and is way too 
> inefficient for high-volume VLSI.

My mistake--from this chip photo, I incorrectly identified either
the registers or the ALU as a PLA:

http://micro.magnet.fsu.edu/chipshots/mos/6502large.html

Still, given the relatively ordered distribution of 6502 undefined
ops, I think their detection would have been relatively simple.

Of course, this is moot for at least two reasons:  it wasn't done,
and most designers of the time wouldn't have done it anyway.

-michael

Music synthesis 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."
0
Michael
5/15/2006 7:46:59 PM
Rainer Buchty wrote:
> In article <d4CdnR_y__CUmfXZnZ2dnUVZ_s-dnZ2d@comcast.com>,
>  "Michael J. Mahon" <mjmahon@aol.com> writes:
> |> True, but the decoding in the 6502 is handled by a kind of PLA, so
> |> it would likely not be very expensive (in real estate) to trap or
> |> NOP the invalid combinations.
> 
> You are too today-centric.
> 
> Back in the 1970s even that "likely not very expensive" decision raised
> the costs significantly and introduced complexity to the chip which was 
> unnecessary from a technical and marketing point of view.
> 
> |> If I had been designing the 6502,
> |> I likely would have made the same choice.
> 
> Probably everyone would have. Leaving out the illegal opcode traps or
> mapping them to NOP did no harm, implementing them would just raise
> costs.
> 
> |> (But as a coder, I would have regarded undefined ops as a curiosity, 
> |> not as an opportunity to save a few cycles at the expense of future 
> |> utility.)
> 
> If a platform stays identical over a long-enough period of time
> then why not starting to squeeze the last out of it by using undocumented
> behavior. After all, the use of such undocumented behavior in the end 
> led to enhanced capabilities, even the chip designers didn't envision
> in the first place.

I suspect that we don't disagree very much about this.  But note that
the 6502 was not such a platform.  Being relatively successful, it went
on through multiple generations of implementation, and unintended
behaviors are not, in general, maintained in subsequent implementations.

Although early experimenters could not have predicted the course of the
architecture's evolution, it was still common culture, since the 1950s,
not to "exploit" accidental, and therefore unsupported, "instructions"
that might exist in particular computer implementations.  The problems
in maintenance and upgrading that this caused were well known.

Commercial computing recognized the significant advantages of creating
an object code-compatible line of machines, with scalable performance,
by the end of the 1950s, and major computer lines were designed with
this in mind by the early 1960s.

It has often been noted that the microprocessor community apparently
needed to rediscover all the lessons already learned by the mainframe
computer culture, but two decades later.  A general presumption that
"things will always be as they are now" is one misconception that it
took people a while to correct.

> I'm especially thinking about all the fancy stuff coders did with the
> C64's video chip, which like the original 6502 (and the hereon based 6510) 
> is a hardwired design.

As it turned out, the presumption that these were immutable chips was
correct.

As I stated earlier, if you have good reason to believe that you are
programming for an end-of-the-line system, then you are free to do
anything that works.  But I consider this a pessimistic assumption
unless the platform has really fossilized--as the platforms we are
celebrating here have.

> And back then noone really thought about future utility. Maybe apart from
> the Apple II those machines were pretty much integrated & rather unexpandable
> boxes -- even more, in the early homecomputer and video game market there was 
> no sense for a "family concept" where software from the old machine would just 
> run on its next generation successor, cause that most likely was an entirely
> new box.
> 
> Think of Atari 400/800 vs. 600/800XL, Commodore VIC20 vs. C64, Sinclair ZX81
> vs. Spectrum just to name a few.

No one is praiseworthy for not thinking about future utility!

It seems hard to imagine now that--almost 20 years after commercial
computers had all moved to scalable, compatible lines to leverage
code investments--the idea that this might be at least as valuable
in the microcomputer marketplace did not influence design decisions.

Until the Mac, all of Apple's computers were designed with application
compatibility with previous machines in mind.  Of course, the same has
been true since in the Mac line, and in the entire PC line (after a few
early not-quite-clone dead ends).

I suppose I must fault the undisciplined early coders for participating
in the newest, most radical advance in computing without a real vision
of what success would mean.  The lesson was already clear for anyone
who was paying attention.  (Note that I have no problem whatever with
someone *using* undocumented features themselves--the problem is when
code that uses such features is released for wider use.)

-michael

Music synthesis 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."
0
Michael
5/15/2006 8:19:20 PM
In article <kKCdnXMGZogpR_XZRVn-qw@comcast.com>,
 "Michael J. Mahon" <mjmahon@aol.com> wrote:

> My mistake--from this chip photo, I incorrectly identified either
> the registers or the ALU as a PLA:
> 
> http://micro.magnet.fsu.edu/chipshots/mos/6502large.html

See that mess of spaghetti in the middle?  I think that's the 
instruction decoder.
0
Bruce
5/16/2006 6:02:10 AM
Bruce Tomlin wrote:
> In article <kKCdnXMGZogpR_XZRVn-qw@comcast.com>,
>  "Michael J. Mahon" <mjmahon@aol.com> wrote:
> 
> 
>>My mistake--from this chip photo, I incorrectly identified either
>>the registers or the ALU as a PLA:
>>
>>http://micro.magnet.fsu.edu/chipshots/mos/6502large.html
> 
> 
> See that mess of spaghetti in the middle?  I think that's the 
> instruction decoder.

It would actually be fun to see the real logic diagram of the
6502.  ;-)

All of the "internals" documentation I've found is very abstract
with no detail where it would be most interesting.

-michael

Music synthesis 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."
0
Michael
5/16/2006 8:19:28 AM
Michael J. Mahon wrote:

> The fact that both companies used "custom" 6502 processors for their
> machines is no doubt part of the reason that they never moved forward.

Huh? They did move forward. 6510 -> 8500 -> 8502. And also, I don't 
think it's any kind of problem for Commodore to use customized CPUs 
since they owned MOS, the owners and producers of 6502 tech back then :)

> Non-portable code is written for two quite different reasons:
> 
> 1) Because the coder doesn't even think about portability or
>    doesn't understand it, non-portablility happens.
> 2) Because the coder understands perfectly, and chooses to
>    write non-portable code on purpose.  (One-time use, static
>    platform, compelling need,...?)

3) Slow-as-hell 8 Bit platforms don't have a proper abstraction layer 
for any of their hardware, no matter if sound, graphics, timers, ports 
or CPU.
0
John
5/17/2006 3:02:23 PM
> Huh? They did move forward. 6510 -> 8500 -> 8502.

And what exactly were the differences between these chips?

> And also, I don't think it's any kind of problem for Commodore to use
> customized CPUs since they owned MOS, the owners and producers
> of 6502 tech back then :)

And, yes, MOS made all the funky custom chips - but the 6502-core chips
were AFAIK the most advanced CPUs designed/modified/produced by them.

bye
Marcus

0
heuser
5/17/2006 3:31:17 PM
John Selck wrote:
> Michael J. Mahon wrote:
> 
>> The fact that both companies used "custom" 6502 processors for their
>> machines is no doubt part of the reason that they never moved forward.
> 
> 
> Huh? They did move forward. 6510 -> 8500 -> 8502. And also, I don't 
> think it's any kind of problem for Commodore to use customized CPUs 
> since they owned MOS, the owners and producers of 6502 tech back then :)

And these new processors preserved the undefined opcode behavior?

If so, they are almost certainly *not* new processor designs.

If not, then they are a good illustration of why it's a bad idea
to depend on undefined behavior.

>> Non-portable code is written for two quite different reasons:
>>
>> 1) Because the coder doesn't even think about portability or
>>    doesn't understand it, non-portablility happens.
>> 2) Because the coder understands perfectly, and chooses to
>>    write non-portable code on purpose.  (One-time use, static
>>    platform, compelling need,...?)
> 
> 
> 3) Slow-as-hell 8 Bit platforms don't have a proper abstraction layer 
> for any of their hardware, no matter if sound, graphics, timers, ports 
> or CPU.

Nonsense.  The "abstraction" we are discussing is the published
documentation for the processor/system.  What it documents is the
abstraction that future implementations will preserve.  What it
doesn't document will generally not be preserved.

The only exception to this is when rampant exploitation of undocumented
features makes their preservation a marketing necessity.  In the latter
case, many extensions to the system functionality will be hampered by
the need to provide the undocumented functionality, making evolution
less attractive.

Most early micro systems suffered from this problem.  Many didn't live
long enough or attract enough user base to face the issue.  But those
who did face it had to decide what undocumented behaviors of the early
platform to leave behind, along with any software that exploited them.

-michael

Music synthesis 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."
0
Michael
5/17/2006 9:45:18 PM
>It would actually be fun to see the real logic diagram of the
>6502.  ;-) 

I'd love to see it.

Rich

0
aiiadict
5/17/2006 9:53:22 PM
Michael J. Mahon wrote:
> John Selck wrote:
>> Huh? They did move forward. 6510 -> 8500 -> 8502. And also, I don't 
>> think it's any kind of problem for Commodore to use customized CPUs 
>> since they owned MOS, the owners and producers of 6502 tech back then :)
> 
> And these new processors preserved the undefined opcode behavior?
> 
> If so, they are almost certainly *not* new processor designs.

Same opcodes but faster clockspeed. Also, CBM switched from NMOS to HMOS.

>> 3) Slow-as-hell 8 Bit platforms don't have a proper abstraction layer 
>> for any of their hardware, no matter if sound, graphics, timers, ports 
>> or CPU.
> 
> Nonsense.  The "abstraction" we are discussing is the published
> documentation for the processor/system.  What it documents is the
> abstraction that future implementations will preserve.  What it
> doesn't document will generally not be preserved.

What about the bugs in the decimal mode? They were fixed on later 
processor designs, this also renders the CPUs incompatible for some 
programs.
0
John
5/18/2006 6:09:59 AM
Michael J. Mahon wrote:
> True, but the decoding in the 6502 is handled by a kind of PLA, so
> it would likely not be very expensive (in real estate) to trap or
> NOP the invalid combinations.

The 6502 is a design to have as few transistors as possible. The whole 
CPU only has a few thousand of them. Handling the illegals would have 
increased this small amount a lot.

> Admittedly, though, the microprocessor design culture at that time
> was not oriented toward "protecting" undefined space, as they all
> have been in the years since.

It's not about culture, it's about being able to do more with just a few 
transistors. What CPU would you buy? The one which can do less has NOPs 
instead of illegals, or the one which can do more?

Removing illegals is ok if you only waste 1000 transistors of 1000000, 
but if it's 1000 transistors of 6000, then it's a whole different matter.
0
John
5/18/2006 6:15:10 AM
Michael J. Mahon wrote:

> It would actually be fun to see the real logic diagram of the
> 6502.  ;-)
 >
 > All of the "internals" documentation I've found is very abstract
 > with no detail where it would be most interesting.

Some hungarian maniacs have reverse engineered the 6502:

http://impulzus.sch.bme.hu/6502/6502/

Sadly the site is in hungarian language, but atleast the logic diagrams 
speak for themselves.
0
John
5/18/2006 6:27:15 AM
John Selck wrote:
> Michael J. Mahon wrote:
> 
>> John Selck wrote:
>>
>>> Huh? They did move forward. 6510 -> 8500 -> 8502. And also, I don't 
>>> think it's any kind of problem for Commodore to use customized CPUs 
>>> since they owned MOS, the owners and producers of 6502 tech back then :)
>>
>>
>> And these new processors preserved the undefined opcode behavior?
>>
>> If so, they are almost certainly *not* new processor designs.
> 
> 
> Same opcodes but faster clockspeed. Also, CBM switched from NMOS to HMOS.

So this was an algorithmic rework of the original design for a new
process, not a new logical design.

>>> 3) Slow-as-hell 8 Bit platforms don't have a proper abstraction layer 
>>> for any of their hardware, no matter if sound, graphics, timers, 
>>> ports or CPU.
>>
>>
>> Nonsense.  The "abstraction" we are discussing is the published
>> documentation for the processor/system.  What it documents is the
>> abstraction that future implementations will preserve.  What it
>> doesn't document will generally not be preserved.
> 
> 
> What about the bugs in the decimal mode? They were fixed on later 
> processor designs, this also renders the CPUs incompatible for some 
> programs.

Processor bugs (or "errata") are cases where the implementation does not
behave as the documentation says that it should.  The decimal bugs in
the original 6502 were not part of its documentation, and therefore
should not be depended upon.  (Of course, in the presence of the bug,
code cannot depend on the documented *correct* behavior either; it must
be written to "work around" the bug without depending on undocumented
behavior.)

Errata are always a special case.  The designers always hope that code
that runs correctly on the original, buggy processor will still run
correctly on a fixed processor.  In other words, they hope that no
one has written code that *depends* on buggy behavior.

To summarize, code written to the specifications of a processor will
work correctly on all implementations, *except* where an implementation
is faulty.  Code written to work around a fault can still be written
to the specifications, but avoiding the faulty case(s).

On the other hand, code written to *require* faulty behavior to run does
not conform to the specification, and may not run correctly on a later
implementation of the processor.

Compatibility is always with the specification--not with undocumented
and possibly faulty behavior exhibited by a particular implementation.
Such a specification describes the abstraction known as the processor
"instruction set architecture" (ISA).

-michael

Music synthesis 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."
0
Michael
5/18/2006 7:39:47 AM
John Selck wrote:
> Michael J. Mahon wrote:
> 
>> It would actually be fun to see the real logic diagram of the
>> 6502.  ;-)
> 
>  >
>  > All of the "internals" documentation I've found is very abstract
>  > with no detail where it would be most interesting.
> 
> Some hungarian maniacs have reverse engineered the 6502:
> 
> http://impulzus.sch.bme.hu/6502/6502/
> 
> Sadly the site is in hungarian language, but atleast the logic diagrams 
> speak for themselves.

What do you know!  The decoding *is* done with a PLA after all!

-michael

Music synthesis 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."
0
Michael
5/18/2006 8:08:04 AM
John Selck wrote:
> Michael J. Mahon wrote:
> 
>> True, but the decoding in the 6502 is handled by a kind of PLA, so
>> it would likely not be very expensive (in real estate) to trap or
>> NOP the invalid combinations.
> 
> 
> The 6502 is a design to have as few transistors as possible. The whole 
> CPU only has a few thousand of them. Handling the illegals would have 
> increased this small amount a lot.

Actually, neither of us has the data on how much would have been
required.  I argued that if the decoding is regular--as in PLA--
then the cost might have been relatively modest.

 From looking at the Hungarian reverse engineering of the 6502, it
appears that I was right about the PLA decoder.  A PLA is used to
derive control signals from the op register.

>> Admittedly, though, the microprocessor design culture at that time
>> was not oriented toward "protecting" undefined space, as they all
>> have been in the years since.
> 
> 
> It's not about culture, it's about being able to do more with just a few 
> transistors. What CPU would you buy? The one which can do less has NOPs 
> instead of illegals, or the one which can do more?

The difference would be in die size, and therefore cost.

And just "getting it done" with absolute minimal die size *is* a design
culture.  (One that is no longer current in commercial microprocessors.)

Moore's "Law" has provided a great deal of freedom in design cultures.
;-)

> Removing illegals is ok if you only waste 1000 transistors of 1000000, 
> but if it's 1000 transistors of 6000, then it's a whole different matter.

I admit that I don't have a quantitative estimate of the number of
transistors (PLA terms) required to protect at least most of the
unused opcode space, but I suspect it would not be more than a few
hundred (out of about 3700 in the 6502).

Since the decoding is done with a regular (rectangular) PLA, the real
issue is not the number of transistors, but the number of rows and
columns required to make a "complete" decoder.  This would add slightly
to the chip dimensions.  Adding terms to the PLA within the existing
matrix would not add to chip size.

Any quantitative estimate would need to be based on the actual 6502
implementation.

-michael

Music synthesis 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."
0
Michael
5/18/2006 8:22:08 AM
Hello,

aiiadict@gmail.com <aiiadict@gmail.com> schrieb:

>>It would actually be fun to see the real logic diagram of the 6502.
>>;-) 
>
> I'd love to see it.

According to http://www.ncsu.edu/wcae/WCAE1/hanson.pdf (see also
http://www.ncsu.edu/wcae/WCAE1/), there must exist a blueprint at the
University of Mississippi, Department of Electrical Engineering.

So, perhaps, there might be a source of a possible logic diagram
available, if someone could get in touch with that University?

Regards,
   Spiro.

-- 
Spiro R. Trikaliotis                              http://cbm4win.sf.net/
http://www.trikaliotis.net/                     http://www.viceteam.org/
0
Spiro
5/18/2006 9:56:57 AM
In article <e4fdtv$2fj$1@rzsun03.rrz.uni-hamburg.de>,
John Selck  <selck_j@informatik.hgv-hamburg.de> wrote:

> Michael J. Mahon wrote:
..............
>> Non-portable code is written for two quite different reasons:
>> 
>> 1) Because the coder doesn't even think about portability or
>>    doesn't understand it, non-portablility happens.
>> 2) Because the coder understands perfectly, and chooses to
>>    write non-portable code on purpose.  (One-time use, static
>>    platform, compelling need,...?)
> 
> 3) Slow-as-hell 8 Bit platforms don't have a proper abstraction layer 
> for any of their hardware, no matter if sound, graphics, timers, ports 
> or CPU.

???????????????????

Could you point at one single case where use of undocumented opcodes did
significantly speed up an application on the 6502 platform?

-- 
----------------------------------------------------------------
Paul Schlyter,  Grev Turegatan 40,  SE-114 38 Stockholm,  SWEDEN
e-mail:  pausch at stockholm dot bostream dot se
WWW:     http://stjarnhimlen.se/
0
pausch
5/18/2006 2:14:06 PM
References trimmed.

John Selck <selck_j@informatik.hgv-hamburg.de> writes:

>Same opcodes but faster clockspeed. Also, CBM switched from NMOS to HMOS.

Strictly speaking, HMOS *is* NMOS because they both still use n-type MOSFETs.

--
      Cameron Kaiser * ckaiser@floodgap.com * posting with a Commodore 128
                personal page: http://www.armory.com/%7Espectre/
  ** Computer Workshops: games, productivity software and more for C64/128! **
                  ** http://www.armory.com/%7Espectre/cwi/ **
0
Cameron
5/18/2006 3:22:01 PM
In article <e4htrq$1ktj$1@merope.saaf.se>,
 pausch@saaf.se (Paul Schlyter) writes:
|> Could you point at one single case where use of undocumented opcodes did
|> significantly speed up an application on the 6502 platform?

Depends on how you define "significantly".

If you understand it as "I want to see it on the stop-watch in my hand",
then of course you won't find any.

There are quite some "it wouldn't work otherwise" examples, though,
which require those undocumented opcodes to meet strict timing.

Rainer

0
buchty
5/18/2006 5:38:37 PM
Spiro Trikaliotis wrote:
> Hello,
> 
> aiiadict@gmail.com <aiiadict@gmail.com> schrieb:
> 
> 
>>>It would actually be fun to see the real logic diagram of the 6502.
>>>;-) 
>>
>>I'd love to see it.
> 
> 
> According to http://www.ncsu.edu/wcae/WCAE1/hanson.pdf (see also
> http://www.ncsu.edu/wcae/WCAE1/), there must exist a blueprint at the
> University of Mississippi, Department of Electrical Engineering.
> 
> So, perhaps, there might be a source of a possible logic diagram
> available, if someone could get in touch with that University?

And the excellent detailed block diagram on the last page of
Hanson's paper is a welcome addition to my library!

-michael

Music synthesis 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."
0
Michael
5/18/2006 7:29:43 PM
Am 18.05.2006, 16:14 Uhr, schrieb Paul Schlyter <pausch@saaf.se>:

> Could you point at one single case where use of undocumented opcodes did
> significantly speed up an application on the 6502 platform?

Bresenham interpolation.

Without illegal opcodes:

STA $12
TXA
STA $FE00,Y
TAX
LDA $12
SBC $10
BCS .skip
ADC $11
INX
..skip

With illegal opcodes:

SHX $FE00,Y
SBC $10
BCS .skip
ADC $11
INX
..skip

Best case: 21 vs 11 clock cycles (almost 2x speed with illegal)
Worst case: 25 vs 15 clock cycles (still 1.67x speed)
0
John
5/18/2006 8:12:47 PM
"John Selck" <gpjiweg@t-online.de> writes:

> STA $12
> TXA
> STA $FE00,Y
> TAX
> LDA $12
> SBC $10
> BCS .skip
> ADC $11
> INX
> .skip

I don't know the circumstances, but why the TAX?

-- 
Anders Carlsson
0
Anders
5/18/2006 8:21:03 PM
Am 18.05.2006, 10:22 Uhr, schrieb Michael J. Mahon <mjmahon@aol.com>:

> I admit that I don't have a quantitative estimate of the number of
> transistors (PLA terms) required to protect at least most of the
> unused opcode space, but I suspect it would not be more than a few
> hundred (out of about 3700 in the 6502).

And you think people would waste a few hundred just for that? Also,
you have propably noticed the lack of space on the cpu... If they
had space for a few hundred more transistors, they would rather have
added another adressing mode or opcodes like PLX/PHX or TXY etc, but
not NOP'ing out the illegals.

Btw, also x86 CPUs have undocumented opcodes aswell... and programs
do use them.
0
John
5/18/2006 8:23:43 PM
Am 18.05.2006, 22:21 Uhr, schrieb Anders Carlsson  
<anders.carlsson@sfks.se>:

> "John Selck" <gpjiweg@t-online.de> writes:
>
>> STA $12
>> TXA
>> STA $FE00,Y
>> TAX
>> LDA $12
>> SBC $10
>> BCS .skip
>> ADC $11
>> INX
>> .skip
>
> I don't know the circumstances, but why the TAX?

Just drop it...

Best case: 19 vs 11 clock cycles (1.73x speed)
Worst case: 23 vs 15 clock cycles (1.53x speed)

Fact remains: illegals can make a difference on certain tasks.
0
John
5/18/2006 8:30:26 PM
Michael J. Mahon wrote:

> Errata are always a special case.  The designers always hope that code
> that runs correctly on the original, buggy processor will still run
> correctly on a fixed processor.  In other words, they hope that no
> one has written code that *depends* on buggy behavior.
>
> To summarize, code written to the specifications of a processor will
> work correctly on all implementations, *except* where an implementation
> is faulty.  Code written to work around a fault can still be written
> to the specifications, but avoiding the faulty case(s).

A classic example of this from the real 6502, is the Indirect Absolute
JMP bug. It's trivial, once you know it's there to work around it. But
if you pick a workaround that exploits the bug, your code won't work on
any of the later parts.

Did anyone actually do this? I certainly hope not

Matt

0
mdj
5/19/2006 4:19:12 AM
John Selck wrote:

> Best case: 21 vs 11 clock cycles (almost 2x speed with illegal)
> Worst case: 25 vs 15 clock cycles (still 1.67x speed)

Nice... It would be amusing to see a game title on the Apple II+
running faster than on the IIe :-)

Of course, the point remains though that your would never do this on
the Apple II series, as you'd limit your target market to the earliest
machine, rather than just the lowest common denominator of all machines
(64k, 6502 code that's documented and unbuggy)

If I were coding on a different 6502 platform, I might consider using
these.

But then, I'm very much a 65C02 coder these days, as pretty much
everything I write is intended for a IIe/IIc and wouldn't run on an
older Apple II anyway.

Michael will probably shoot me down for saying this, but when I mean
BRA, I write BRA. It's clearer code, and I really wish that anyone who
writes code specifically for the earlier processors would comment their
unconditional branches accordingly.

But then I'm also pretty carefree about not bumping into the old 6502
bugs either ;-)

Matt

0
mdj
5/19/2006 4:28:03 AM
Michael J. Mahon wrote:
> John Selck wrote:
>> Same opcodes but faster clockspeed. Also, CBM switched from NMOS to HMOS.
> 
> So this was an algorithmic rework of the original design for a new
> process, not a new logical design.

This is splitting hairs.  Bill Mensch created the 65C816 and 65C02 
designs, which are most definitely *new*, as they did not share any of 
the original design.  However, the '02 was not a new logical design, 
just a redo of the existing NMOS 6502 to take advantage of CMOS.

As well, I know there are ways to create new CPU designs that preserve 
undocumented behavior of older designs, designs that add extensive 
feature sets to the original design (8->16 bit transition, etc.)  Even 
Intel has done so (the FFFF segment wrap in the 8086) as they created 
news designs.

At the end of the day, enough time passed with the NMOS 6502 core in 
play in the CBM world that it became the norm.  It was (and is) not 
always seen as bad programming practice in the context of CBM 
development to utilize the illops.

Jim
0
Jim
5/19/2006 5:22:07 AM
Michael J. Mahon wrote:
> What do you know!  The decoding *is* done with a PLA after all!

I don't think a PLA allows X (don't care) states.  The large logic 
matrix at the bottom of the diagram is a wired-or matrix, which is why 
the illops exist.

Jim
0
Jim
5/19/2006 5:28:31 AM
Michael J. Mahon wrote:
> And just "getting it done" with absolute minimal die size *is* a design
> culture.  (One that is no longer current in commercial microprocessors.)
True.  At the time, cost was the absolute concern.  8080's were hundreds 
and 6800s were as well.  MOS wanted a $20.00 or so CPU, to undercut the 
market.  die size meant a lot.  MOS had just hired the 6800 design team 
not too much earlier, and did not have a NMOS process in place when the 
design team came onboard.  They no doubt wanted to cram as much into a 
die as they feared the yield would be low on the first batches.

Jim
0
Jim
5/19/2006 5:38:18 AM
On 2006-05-18, John Selck <gpjiweg@t-online.de> wrote:

0$: stx $fe00
    sbc $10
    bcs 1$
    adc $11
    inc 0$+1
$1:

> Best case: 19 vs 11 clock cycles (1.73x speed)
> Worst case: 23 vs 15 clock cycles (1.53x speed)

Best case:  10 vs 11 clock cycles (0.9x speed)
Worst case: 18 (17 if zeropage) vs 15 cycles (1.2x or 1.13x speed)

> Fact remains: illegals can make a difference on certain tasks.

In best-case your routine is slower than without illegals,
and in average it is about the same speed.

-Pasi
-- 
"There's only one thing more dangerous than Mr. Garibaldi
 when he's loud. .. It's when he's dead silent."
	-- Sheridan to Lochley in Babylon 5:"Phoenix Rising"
0
Pasi
5/19/2006 6:48:51 AM
Jim Brain wrote:
> Michael J. Mahon wrote:
> 
>> John Selck wrote:
>>
>>> Same opcodes but faster clockspeed. Also, CBM switched from NMOS to 
>>> HMOS.
>>
>>
>> So this was an algorithmic rework of the original design for a new
>> process, not a new logical design.
> 
> 
> This is splitting hairs.  Bill Mensch created the 65C816 and 65C02 
> designs, which are most definitely *new*, as they did not share any of 
> the original design.  However, the '02 was not a new logical design, 
> just a redo of the existing NMOS 6502 to take advantage of CMOS.

Not so.  The logical elements of the NMOS design are not present in
the same form in CMOS.  And the instruction decoding was clearly
redesigned, as was the control section (changed timings and bus cycle
patterns, new instructions).

It would be difficult to design new logic for a processor that preserved
the undocumented behavior of an earlier version--and impossible if new
instructions are added.

> As well, I know there are ways to create new CPU designs that preserve 
> undocumented behavior of older designs, designs that add extensive 
> feature sets to the original design (8->16 bit transition, etc.)  Even 
> Intel has done so (the FFFF segment wrap in the 8086) as they created 
> news designs.

That kind of behavior is of a completely different kind than random
bus clashes as multiple data sources are unintentionally gated onto
a bus!

> At the end of the day, enough time passed with the NMOS 6502 core in 
> play in the CBM world that it became the norm.  It was (and is) not 
> always seen as bad programming practice in the context of CBM 
> development to utilize the illops.

Not the norm, I would say, but the *only* 6502 implementation ever
used on that platform.  I'd say that it illustrates my original point.

Long after the 65C02 design was available, lower power, faster, and
cheaper to make, the CBM line could not easily make use of it.

-michael

Music synthesis 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."
0
Michael
5/19/2006 6:53:16 AM
Jim Brain wrote:
> Michael J. Mahon wrote:
> 
>> What do you know!  The decoding *is* done with a PLA after all!
> 
> 
> I don't think a PLA allows X (don't care) states.  The large logic 
> matrix at the bottom of the diagram is a wired-or matrix, which is why 
> the illops exist.

In the area of processor design these days, a wired ROM decoder is often
referred to as a PLA, since it is an array and it is "programmable" by
wiring choices at design time.  Wire-ORing is common to many logic
configurations.

-michael

Music synthesis 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."
0
Michael
5/19/2006 6:56:14 AM
mdj wrote:
> John Selck wrote:
> 
> 
>>Best case: 21 vs 11 clock cycles (almost 2x speed with illegal)
>>Worst case: 25 vs 15 clock cycles (still 1.67x speed)
> 
> 
> Nice... It would be amusing to see a game title on the Apple II+
> running faster than on the IIe :-)
> 
> Of course, the point remains though that your would never do this on
> the Apple II series, as you'd limit your target market to the earliest
> machine, rather than just the lowest common denominator of all machines
> (64k, 6502 code that's documented and unbuggy)
> 
> If I were coding on a different 6502 platform, I might consider using
> these.
> 
> But then, I'm very much a 65C02 coder these days, as pretty much
> everything I write is intended for a IIe/IIc and wouldn't run on an
> older Apple II anyway.
> 
> Michael will probably shoot me down for saying this, but when I mean
> BRA, I write BRA. It's clearer code, and I really wish that anyone who
> writes code specifically for the earlier processors would comment their
> unconditional branches accordingly.

No shooting from here.  ;-)

I agree that "unconditional" branches should always be commented so,
even when they are written as conditional.  I have found only a very
small fraction of unconditional jumps that cannot be perfectly safely
with the right conditional jump.

-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."
0
Michael
5/19/2006 7:01:51 AM
"Michael J. Mahon" <mjmahon@aol.com> writes:
> The 6502 was already a much less expensive processor than its
> competitors, because of a mask retouching technique MOS Technology
> developed that saved mask iterations.

I saw that claim on Wikipedia.  Is there any published reference?

Stephen Harris wrote:
> With the 6502 essentially not having a microcode level, this
> optimisation is exposed to the programmer.

The PLA is essentially equivalent to microcode.  The difference is
that it is addressed by the instruction register and a few state bits,
rather than a micro-PC.

Eric
0
Eric
5/19/2006 7:13:32 AM
Michael J. Mahon
> True, but the decoding in the 6502 is handled by a kind of PLA, so
> it would likely not be very expensive (in real estate) to trap or
> NOP the invalid combinations.

Bruce Tomlin wrote:
> Nope, it's handled by good old random logic.  A PLA is designed to be a 
> programmable generic replacement for random logic, and is way too 
> inefficient for high-volume VLSI.

Sorry, but Michael is correct.  It is definitely a PLA.  You can see it
on the die (or a photomicrograph); it's the most regular structure.  It
is near one edge of the die, takes up an area about 1/6 of the long
dimension of the chip by most of the short dimension.

If I've counted correctly, the logical size of the product term array is
21 inputs by 137 product terms.  15 of the inputs are from the
instruction register; they are the true and complement forms of each bit
except bit 1.  It appears that two inputs come from the clock generator,
and four from a state counter, but I haven't studied it in enough detail
to be certain of that.  Most of the product terms control gating of
signals between registers.

MOS PLA design is actually quite space-efficient, and for functions like
instruction decode is usually more space-efficicent than equivalent
random logic would be.  This is especially true of the NMOS 6502, for
which the instruction encoding was designed in such a way that they did
not need to OR together many (any?) of the product terms.

It's not a *field* programmable logic array, if that's what you were
thinking of.  It's mask programmed by the presence or absence of
transistors at specific locations in the array.

Many microprocessors in the 1970s, and almost all newer ones use PLAs
for instruction decode and other tasks.  Even the lowly TMS1000 four-bit
microprocessor, the epitome of cheap microprocessors in the mid-1970s,
used PLAs.

Eric
0
Eric
5/19/2006 7:43:47 AM
Jim Brain <brain@jbrain.com> writes:
> I don't think a PLA allows X (don't care) states.

Certainly it does.  That's one of the primary distinguishing characteristics
of a PLA as opposed to a ROM.

Eric
0
Eric
5/19/2006 7:47:36 AM
Michael J. Mahon wrote:
> The fact that both companies used "custom" 6502 processors for their
> machines is no doubt part of the reason that they never moved forward.

John Selck <selck_j@informatik.hgv-hamburg.de> writes:
> Huh? They did move forward. 6510 -> 8500 -> 8502.

That was a progression of nearly insignificant changes.  Not comparable
to e.g. the 8086/80286/80386 progression, or even to the
6502/65C02/65816 progression.

> And also, I don't
> think it's any kind of problem for Commodore to use customized CPUs
> since they owned MOS, the owners and producers of 6502 tech back then

Yes, it was a problem for them.  Designing (or even just modifying)
a processor costs a lot of money, even if you own the fab.  You don't
do it unless you have a business plan with a reasonable expectation
of (more than) recouping those costs.

In a modern process, a production mask set costs about $0.5-$1 million
if you don't own the fab, maybe 20% of that if you do.  Back in the
1980s with larger process geometries the costs were lower, but still
not insignificant.
0
Eric
5/19/2006 7:53:20 AM
John Selck <selck_j@informatik.hgv-hamburg.de> writes:
> Same opcodes but faster clockspeed. Also, CBM switched from NMOS to HMOS.

HMOS is just NMOS with smaller process geometry.  The NMOS to HMOS
transition was a bigger change than for instance going from 1 micron
to 0.8 micron CMOS, but not nearly as big a change as switching from
PMOS to NMOS, or from NMOS/HMOS to CMOS.
0
Eric
5/19/2006 7:55:42 AM
buchty@atbode100.lrr.in.tum.de (Rainer Buchty) writes:
> There are quite some "it wouldn't work otherwise" examples, though,
> which require those undocumented opcodes to meet strict timing.

Such as?
0
Eric
5/19/2006 7:56:36 AM
Am 19.05.2006, 08:48 Uhr, schrieb Pasi Ojala  
<albert@pikkukorppi.cs.tut.fi>:

> On 2006-05-18, John Selck <gpjiweg@t-online.de> wrote:
>
> 0$: stx $fe00
>     sbc $10
>     bcs 1$
>     adc $11
>     inc 0$+1
> $1:
>
>> Best case: 19 vs 11 clock cycles (1.73x speed)
>> Worst case: 23 vs 15 clock cycles (1.53x speed)
>
> Best case:  10 vs 11 clock cycles (0.9x speed)
> Worst case: 18 (17 if zeropage) vs 15 cycles (1.2x or 1.13x speed)
>
>> Fact remains: illegals can make a difference on certain tasks.
>
> In best-case your routine is slower than without illegals,
> and in average it is about the same speed.

Yes true your routine is faster, but it does not do any Bresenham
interpolation.
0
John
5/19/2006 8:34:43 AM
Am 19.05.2006, 06:28 Uhr, schrieb mdj <mdj.mdj@gmail.com>:

> Of course, the point remains though that your would never do this on
> the Apple II series, as you'd limit your target market to the earliest
> machine, rather than just the lowest common denominator of all machines
> (64k, 6502 code that's documented and unbuggy)

It's easy to do a processor check.
0
John
5/19/2006 8:51:22 AM
On 2006-05-19, John Selck <gpjiweg@t-online.de> wrote:
> Yes true your routine is faster, but it does not do any Bresenham
> interpolation.

Neither did yours. It was just a small part of the actual routine
so that you could quote such a large improvement, right?:-)

At least I think that my routine was equivalent as long as $0+1
and X are setup the same way.

-Pasi
-- 
"There's only one thing more dangerous than Mr. Garibaldi
 when he's loud. .. It's when he's dead silent."
	-- Sheridan to Lochley in Babylon 5:"Phoenix Rising"
0
Pasi
5/19/2006 9:45:07 AM
Am 19.05.2006, 11:45 Uhr, schrieb Pasi Ojala  
<albert@pikkukorppi.cs.tut.fi>:

> On 2006-05-19, John Selck <gpjiweg@t-online.de> wrote:
>> Yes true your routine is faster, but it does not do any Bresenham
>> interpolation.
>
> Neither did yours. It was just a small part of the actual routine
> so that you could quote such a large improvement, right?:-)

What a crap argumentation. I said it is Bresenham interpolation and
it was kinda obvious that it is the inner loop of an either looped
or unrolled Bresenham. Do you want me to write down all 100 repeats
of that code?

> At least I think that my routine was equivalent as long as $0+1
> and X are setup the same way.

Bla bla yeah whatever. You forgot the INX, it's not my fault so
don't try to make it my fault.
0
John
5/19/2006 9:52:16 AM
On 2006-05-19, John Selck <gpjiweg@t-online.de> wrote:
> Bla bla yeah whatever. You forgot the INX, it's not my fault so
> don't try to make it my fault.

Bla bla, thans for pointing that out. Mixed Y and X there.
The fixed inner loop version is even faster:

yidx:	STX $FE00
	SBC $10
	BCS .skip
	ADC $11
	INX
..skip:

whereever Y is changed, do it to yidx+1

Best case 10 vs 11 for using invalids,
worst case 14 vs 15 for using invalids.
This shows that the inner loop that uses invalids is slower!

Also, in your routine the target buffer must be at $fe00
or the routine does not work. If you had the zero page free
(music routines tend to use ZP), you could change SHX $fe00,y
to STX $00,y and save a cycle.

Now do you see that inner loop alone does not say anything
about the speed of the routine?

It is like arguing that
	lax #16
is 100% faster than
	lda #16
	ldx #16

-Pasi
-- 
"There's only one thing more dangerous than Mr. Garibaldi
 when he's loud. .. It's when he's dead silent."
	-- Sheridan to Lochley in Babylon 5:"Phoenix Rising"
0
Pasi
5/19/2006 10:56:23 AM
Am 19.05.2006, 12:56 Uhr, schrieb Pasi Ojala  
<albert@pikkukorppi.cs.tut.fi>:

> On 2006-05-19, John Selck <gpjiweg@t-online.de> wrote:
>> Bla bla yeah whatever. You forgot the INX, it's not my fault so
>> don't try to make it my fault.
>
> Bla bla, thans for pointing that out. Mixed Y and X there.
> The fixed inner loop version is even faster:
>
> yidx:	STX $FE00
> 	SBC $10
> 	BCS .skip
> 	ADC $11
> 	INX
> .skip:
>
> whereever Y is changed, do it to yidx+1

??? What are you trying to do with such a routine?

The ,Y is there for multiple reasons: You can loop the
whole code easily without "INC yidx". Ok, you need INY or DEY
but you need that for the loop anyway.

Another reason would be unrolled code where you try to save
memory, for example: have one interpolation buffer at
$FE00-$FE7F and the second one at $FE80-$FEFF (for left/right
edges of a vector surface maybe).

Or even better you could do partly unrolled code, like
having the Bresenham iteration 8 times unrolled, and then
loop it. This combines the speed gain of loop unrolling with
the memory saving of a loop.

> Now do you see that inner loop alone does not say anything
> about the speed of the routine?
>
> It is like arguing that
> 	lax #16
> is 100% faster than
> 	lda #16
> 	ldx #16

We don't need to argue about this, because LAX #immediate is one
of the unstable opcodes and should not be used as LDA/LDX replacement.

Anyway, this whole discussion went way off: The Bresenham example
was just one example where you could use an opcode. And SHX/SHY are
really useful opcodes, since you can use them as STX abs,Y/STY abs,X
which the normal 6502 does not have (sadly).

There are other example of illegal usage, one where really many
different illegals are used and it's absolutely impossible to
do it without the illegals is the "6 sprites over FLI" code.
0
John
5/19/2006 12:23:31 PM
>> The 6502 was already a much less expensive processor than its
>> competitors, because of a mask retouching technique MOS Technology
>> developed that saved mask iterations.
>
> I saw that claim on Wikipedia.  Is there any published reference?

There is book about the history of Commodore which is rather detailed
(and entertaining) about the MOS history, too:
http://www.commodorebook.com

The MOS chapter can be read freely here:
http://www.commodorebook.com/view.php?content=toc

Excerpt:

At MOS Technology, John Pavinen pioneered a new way to fabricate
microprocessors. "They were one of the first companies to use
non-contact mask liners," says Peddle. "At that time everybody was
using contact masks."

With non-contact masks, the metal die did not touch the wafer. Once the
engineers worked out all the flaws in the mask, it would last
indefinitely.

---

I guess, Chuck Peddle is a good enough reference ;-)

bye
Marcus

0
heuser
5/19/2006 1:45:24 PM
> Some hungarian maniacs have reverse engineered the 6502:
>
> http://impulzus.sch.bme.hu/6502/6502/
>
> Sadly the site is in hungarian language, but atleast the logic diagrams
> speak for themselves.

Maniacs indeed! Thanks for the link, John!

Now - does anybody know something equivalent for the Z80?

[ducks]

bye
Marcus

0
heuser
5/19/2006 1:49:06 PM
Am 17.05.2006, 17:31 Uhr, schrieb <heuser.marcus@freenet.de>:

>> Huh? They did move forward. 6510 -> 8500 -> 8502.
>
> And what exactly were the differences between these chips?

8502 allows 2 MHz and afaik also has some extra pins for zeropage
addressing mode and stack detection.

8500 is ofcourse basically a 6510 :)

>> And also, I don't think it's any kind of problem for Commodore to use
>> customized CPUs since they owned MOS, the owners and producers
>> of 6502 tech back then :)
>
> And, yes, MOS made all the funky custom chips - but the 6502-core chips
> were AFAIK the most advanced CPUs designed/modified/produced by them.

The VIC or SID are about 3 times bigger than the 6502. But ofcourse the
6502 is ingenious :) the only bad thing about it is, that they wasted
transistor space for something like BCD mode. I would have preferred
some small extra commands like ADD without carry or TXY.
0
John
5/19/2006 2:07:13 PM
In article <qh1wuqmoqz.fsf@ruckus.brouhaha.com>,
 Eric Smith <eric@brouhaha.com> writes:
|> buchty@atbode100.lrr.in.tum.de (Rainer Buchty) writes:
|> > There are quite some "it wouldn't work otherwise" examples, though,
|> > which require those undocumented opcodes to meet strict timing.
|> 
|> Such as?

IIRC the S-JiffyDOS patch uses illegal opcodes to speed up GCR decoding.
(Jochen, are you reading here and can comment?)

And I'm sure quite some demos contain illegal opcodes to either make
effects possible at all or get the max out of the raster timing.

Rainer
0
buchty
5/19/2006 2:36:46 PM
> The VIC or SID are about 3 times bigger than the 6502. But ofcourse the
> 6502 is ingenious :)

That's why I wrote "advanced CPUs" ;-)

> the only bad thing about it is, that they wasted transistor space for
> something like BCD mode. I would have preferred some small extra
> commands like ADD without carry or TXY.

I guess, all of us have some wishes for design changes and I agree with
your propositions (though I would've called it TYX - sounds better).

Additionally I would've dumped the indexed-indirect addressing mode and
simply made an indirect-indexed-mode with the X register. IMHO this
would've been infinitely more useful.

For a long time I wished for a block move instruction but I've already
seen too many cases of non-contiguous blocks. A block fill on the other
hand...

bye
Marcus

0
heuser
5/19/2006 2:37:20 PM
Am 19.05.2006, 16:37 Uhr, schrieb <heuser.marcus@freenet.de>:

> I guess, all of us have some wishes for design changes and I agree with
> your propositions (though I would've called it TYX - sounds better).

You could need both, TXY and TYX. Also PHX/PLX/PHY/PLY would have been
nice and propably would have been possible with only few extra transistors.

> For a long time I wished for a block move instruction but I've already
> seen too many cases of non-contiguous blocks. A block fill on the other
> hand...

And then we would have ended up like the Z80: That a copy loop is faster
than the actual block copy instruction :D

Anyway, you don't need block fill since you can use block copy for filling
too, just write the fill-byte to the start address and then start copying
to bufferstart+1, it will do the same.

Anyway, things could have been better but at the same time they could have
been way worse. We're actually pretty lucky with the existing  
implementations
of the 6502 and also VIC + SID.
0
John
5/19/2006 6:45:32 PM
"John Selck" <gpjiweg@t-online.de> writes:
> And then we would have ended up like the Z80: That a copy loop is faster
> than the actual block copy instruction :D

Can you cite an example?  The block move instructions on the Z80 are
actually fairly efficient.  They use three memory cycles to move a byte,
vs. the theoretical minimum of two.  Doing a block copy via a software
loop is going to require at least five memory cycles per byte moved, and
probably more.
0
Eric
5/19/2006 8:34:26 PM
Eric Smith wrote:
> Jim Brain <brain@jbrain.com> writes:
>> I don't think a PLA allows X (don't care) states.
> 
> Certainly it does.  That's one of the primary distinguishing characteristics
> of a PLA as opposed to a ROM.

I'll defer.  All I know is the DTV designer said she originally did not 
include any illops in the design because she could not emulate the 
wored-or matrix in the FPGA in a space efficient manner.  I assumed the 
FPGA is a superset functionality of the PLA, and thus if it can't be 
easily dealt with with in there, I didn;t think it could in the PLA.

Jim
0
Jim
5/19/2006 10:03:15 PM
Michael J. Mahon wrote:
> Not so.  The logical elements of the NMOS design are not present in
> the same form in CMOS.  And the instruction decoding was clearly
> redesigned, as was the control section (changed timings and bus cycle
> patterns, new instructions).

I guess we'll agree to disagree on the point.  I say all the design 
elements are there (the 8 bit ALU, decimal mode, the 16 bit instruction 
pointer, etc.)  As for the instruction decoding, Bill just cleaned up 
the don't cares, as I see it.  Hardly a huge new design.  The physical 
elements changed, yes, but the logical perspective stayed the same. 
When I interviewed him back in 1995, he said as much.  He simply wanted 
to clean up the design and lay it out so he could take advantage of not 
only the CMOS process but the ability to shrink the feature size every 
so many years.  He hasn;t changed his design since the original.  He 
just shrinks the design using the newer process and re-fabs.  That's how 
he stated he got his speed increases.

> That kind of behavior is of a completely different kind than random
> bus clashes as multiple data sources are unintentionally gated onto
> a bus!
I'll agree they are different, but the point was that they are both 
undocumented behavior.  Intel found the undocumented behavior was used 
all over, so they had to build in support for it.  Therefore, every new 
Intel CPU supports this "undocumented behavior".  Of course, it is now 
documented, so it becomes legitimate by virtue of so many people 
exploiting it that it became the std.

> Not the norm, I would say, but the *only* 6502 implementation ever
> used on that platform.  I'd say that it illustrates my original point.

It probably does not qualify, but the C65 used a different 
implementation of the 02, and the CLCD used a CMOS '02 as well.

> Long after the 65C02 design was available, lower power, faster, and
> cheaper to make, the CBM line could not easily make use of it.

If it had made economic sense, CBM would have tasked Mensch to add the 
errata into the C02.  Apple got Bill to change the 816 timings, and CBM 
had more clout with Bill, since they originally helped set up WDC.

But, I'll concede the point that it would have required more cash and 
time than the Apple II line needed.

I guess, in priciple, I agree with you that undocs fly against the rule 
of programming.  HOwever, in the CBM environment, the rules are a bit 
different.  As well, regardless of how one views the use of undocs, I'm 
not willing to be harsh on the MOS folks for what they did.  They made a 
$20 CPU and got Woz and the Bushnell interested in using CPUs, which 
brought all of us to where we are today.  I won't let a few space and 
time saving details that made perfect since in the early 1970's cloud that.

Jim
0
Jim
5/19/2006 10:16:35 PM
Jim Brain wrote:
> I don't think a PLA allows X (don't care) states.

I wrote:
> Certainly it does.  That's one of the primary distinguishing
> characteristics
> of a PLA as opposed to a ROM.

Jim Brain <brain@jbrain.com> writes:
> I'll defer.  All I know is the DTV designer said she originally did
> not include any illops in the design because she could not emulate the
> wored-or matrix in the FPGA in a space efficient manner.

That's true.

> I assumed the FPGA is a superset functionality of the PLA, and thus if it
> can't be easily dealt with with in there, I didn;t think it could in the
> PLA.

There's a lot of difference between an FPGA being conceptually a superset
of a PLA, and an FPGA being able to efficiently implement any particular
PLA.  I've been trying to cram the logic of the DEC J11 microprocessor
into an FPGA, and the decode PLA in that, which is relatively small in
the actual J11 chip, takes up an enormous amount of FPGA space.

The problem is that an FPGA cell is much more coarse-grained than a
PLA "cell", which is just a transistor.

Eric

0
Eric
5/19/2006 10:50:55 PM
Michael J. Mahon wrote:
> Not so.  The logical elements of the NMOS design are not present in
> the same form in CMOS.  And the instruction decoding was clearly
> redesigned, as was the control section (changed timings and bus cycle
> patterns, new instructions).

Jim Brain <brain@jbrain.com> writes:
> I guess we'll agree to disagree on the point.  I say all the design
> elements are there (the 8 bit ALU, decimal mode, the 16 bit
> instruction pointer, etc.)  As for the instruction decoding, Bill just
> cleaned up the don't cares, as I see it.

You're talking about two completely different design levels.  Michael
is talking about transistors, gates, PLAs, and flip-flops.  You (Jim)
are talking about the programmer-visible processor architecture.

It's possible to produce two processors with vastly different
implementations that have the same architecture, e.g., IBM System 360/30
versus System 360/67, which shared almost no commonality of hardware
design, but could run the same software.

It's also possible to produce two processors with nearly the same
hardware implementation, but dramatically different architecture.

The 65C02 architecture is almost a superset of the 6502.  The implementation
is *much* different.

> Hardly a huge new design.

Tell us that after you design a 6502 replacement in a new technology.

> The physical elements changed, yes, but the logical perspective stayed
> the same. When I interviewed him back in 1995, he said as much.

The "physical elements changed" is basically stating that the entire
chip was redesigned.

We could build a very slow 6502-compatible processor out of a lot of
tinkertoys, and still have the same "logical perspective".  I don't think
you'd try to claim that it wasn't a huge new design.

0
Eric
5/19/2006 10:57:51 PM
On 2006-05-19, heuser.marcus@freenet.de wrote:
>> Some hungarian maniacs have reverse engineered the 6502:
>> http://impulzus.sch.bme.hu/6502/6502/
>> Sadly the site is in hungarian language, but atleast the logic diagrams
>> speak for themselves.
> Maniacs indeed! Thanks for the link, John!
> Now - does anybody know something equivalent for the Z80?

Sure, here's one:
http://www.ieee-virtual-museum.org/media/Y9pqVm6tdZqV.jpg
-- 
Matthew W. Miller <mwmiller@columbus.rr.com>
Om mani padme sum.
0
Matthew
5/20/2006 2:15:25 AM
In article <qhwtch92jx.fsf@ruckus.brouhaha.com>,
 Eric Smith <eric@brouhaha.com> wrote:

> "John Selck" <gpjiweg@t-online.de> writes:
> > And then we would have ended up like the Z80: That a copy loop is faster
> > than the actual block copy instruction :D
> 
> Can you cite an example?  The block move instructions on the Z80 are
> actually fairly efficient.  They use three memory cycles to move a byte,
> vs. the theoretical minimum of two.  Doing a block copy via a software
> loop is going to require at least five memory cycles per byte moved, and
> probably more.

That was my understanding as well, having actually done machine language 
on a Z-80 (typing in hex like ED B0 because it was faster than using an 
assembler).
0
Bruce
5/20/2006 4:45:24 AM
Be careful or Captain Zilog crushes you!

http://www.milehighcomics.com/cgi-bin/backissue.cgi?action=fullsize&issue=14882664687%201

;o)

bye
Marcus

0
heuser
5/20/2006 7:01:27 AM
Michael J. Mahon wrote:

> Wow--they needed more than a megabyte/second of video data?  I guess
> if you have about the same resolution as an Apple II, but twice the
> color depth, then you do...  The //c and following Apple II's got
> around this by providing another memory bank in parallel with the
> main memory bank.

The C64 mainly needed it for its text mode. Unlike the Apple, the 
character shapes reside within the Video chip's AND the CPUs normal 
memory map, are read over the normal address bus, and can be redefined 
by pointing a register to RAM instead of ROM.

So once every line of characters the CPU has to stop for 40 cycles, so 
that the character numbers can be read and stored. Then during the 
normal video cycles only the character shapes are read. Color numbers 
for the characters, on the other hand, are read in parallel from a 
special SRAM with its own addressing lines going to the video chip.

The Apple reads the character numbers on every line during its normal 
video access, and reads the character shapes in parallel from a ROM 
that's not visible to the CPU. Thus you have fixed character shapes.#

In multicolor hires mode, the same system is used to read a larger set 
of color registers (instead of the character numbers). Sprites (movable 
object blocks) are created with a similar process.

The C64 design is an improvement on the VIC 20. The VIC also uses 
changable character shapes, but because it doesn't stop the CPU it gets 
only those 22 (or 23?) super broad characters per line. No time to read 
more if you need to read both character numbers and character shapes 
with no more than 1MHz of bandwidth.

Of course redefinable characters made for very nice (and fast) building 
blocks of game backgrounds, and were used extensively in scroller type 
games. That's one of the reasons why there are so many scrollers for the 
Commodores and so few for the Apple.

-- 
Linards Ticmanis
0
Linards
5/20/2006 8:22:05 AM
Am 19.05.2006, 22:34 Uhr, schrieb Eric Smith <eric@brouhaha.com>:

> "John Selck" <gpjiweg@t-online.de> writes:
>> And then we would have ended up like the Z80: That a copy loop is faster
>> than the actual block copy instruction :D
>
> Can you cite an example?  The block move instructions on the Z80 are
> actually fairly efficient.  They use three memory cycles to move a byte,
> vs. the theoretical minimum of two.  Doing a block copy via a software
> loop is going to require at least five memory cycles per byte moved, and
> probably more.

LDIR eats 21 clock cycles per iteration, doing the same with other Z80
instructions can be way faster.

I tried to use the Z80 in the C128 for block copy/fill because I thought
"hey, it has a block copy command, so I guess it is fast" but it wasn't.
Then I tried normal opcodes, it was way faster than using LDIR but still
not faster than copying the stuff with the 8502.

Here's a list of Z80 instruction and their clock cycles:

http://www.ftp83plus.net/Tutorials/z80inset1A.htm
0
John
5/20/2006 9:17:13 AM
Am 12.05.2006, 04:21 Uhr, schrieb Michael J. Mahon <mjmahon@aol.com>:

> And in any case, depending on the peculiarities of a particular chip
> implementation is just asking to be locked out of future improvements.

Like I stated several times now: You can easily do a processor check and
use different code. On plain 6502 you use the faster routine with illegals
and on 65816 etc you use a normal routine. It's 5 minutes work to do that.
0
John
5/20/2006 9:20:17 AM
Hello,

just some nit-picking:

Linards Ticmanis <ticmanis@gmx.de> schrieb:

> So once every line of characters the CPU has to stop for 40 cycles, so 
> that the character numbers can be read and stored. Then during the 
> normal video cycles only the character shapes are read. Color numbers 
> for the characters, on the other hand, are read in parallel from a 
> special SRAM with its own addressing lines going to the video chip.

The color RAM has its own DATA lines, but the same address lines.

It is D8-D11 on the VIC-II.

Regards,
   Spiro.

-- 
Spiro R. Trikaliotis                              http://cbm4win.sf.net/
http://www.trikaliotis.net/                     http://www.viceteam.org/
0
Spiro
5/20/2006 9:50:08 AM
In article <op.s9uev3d6ru4cq2@news.t-online.de>,
John Selck <gpjiweg@t-online.de> wrote:
>Am 12.05.2006, 04:21 Uhr, schrieb Michael J. Mahon <mjmahon@aol.com>:
>
>> And in any case, depending on the peculiarities of a particular chip
>> implementation is just asking to be locked out of future improvements.
>
>Like I stated several times now: You can easily do a processor check and
>use different code. On plain 6502 you use the faster routine with illegals
>and on 65816 etc you use a normal routine. It's 5 minutes work to do that.

....and how do you account for future versions of 6502 in that
processor tests?

That's of course a non-issue for the 6502, where there will be no
future versions.  But the issue is still valid for other processors
where there may be future versions.


-- 
----------------------------------------------------------------
Paul Schlyter,  Grev Turegatan 40,  SE-114 38 Stockholm,  SWEDEN
e-mail:  pausch at stockholm dot bostream dot se
WWW:     http://stjarnhimlen.se/
0
pausch
5/20/2006 10:12:46 AM
In article <e4kl5u$5qq$1@news.lrz-muenchen.de>,
Rainer Buchty <buchty@atbode100.lrr.in.tum.de> wrote:

> In article <qh1wuqmoqz.fsf@ruckus.brouhaha.com>,
>  Eric Smith <eric@brouhaha.com> writes:
> |> buchty@atbode100.lrr.in.tum.de (Rainer Buchty) writes:
> |> > There are quite some "it wouldn't work otherwise" examples, though,
> |> > which require those undocumented opcodes to meet strict timing.
> |> 
> |> Such as?
> 
> IIRC the S-JiffyDOS patch uses illegal opcodes to speed up GCR decoding.
> (Jochen, are you reading here and can comment?)

That can also be done without illegal opcodes.  The Apple Pascal RWTS
did it, and was able to read all sectors of a floppy on one revolution
of the disk -- oncluding GCR decoding on-the-fly.

 
> And I'm sure quite some demos contain illegal opcodes to either make
> effects possible at all or get the max out of the raster timing.
> 
> Rainer

Only demos?  Not sharp applications?  :-)

-- 
----------------------------------------------------------------
Paul Schlyter,  Grev Turegatan 40,  SE-114 38 Stockholm,  SWEDEN
e-mail:  pausch at stockholm dot bostream dot se
WWW:     http://stjarnhimlen.se/
0
pausch
5/20/2006 10:12:46 AM
John Selck <gpjiweg@t-online.de> wrote:

> Am 12.05.2006, 04:21 Uhr, schrieb Michael J. Mahon <mjmahon@aol.com>:

> > And in any case, depending on the peculiarities of a particular chip
> > implementation is just asking to be locked out of future improvements.

> Like I stated several times now: You can easily do a processor check and
> use different code. On plain 6502 you use the faster routine with illegals
> and on 65816 etc you use a normal routine. It's 5 minutes work to do that.

And now you've introduced program bloat, dual code paths, extra potential for
bugs...

-- 
                                 Stephen  Harris
                                usenet@spuddy.org
      The truth is the truth, and opinion just opinion.  But what is what?
       My employer pays to ignore my opinions; you get to do it for free.
0
usenet
5/20/2006 1:36:18 PM
heuser.marcus@freenet.de wrote:
> Be careful or Captain Zilog crushes you!

> http://www.milehighcomics.com/cgi-bin/backissue.cgi?action=fullsize&issue=14882664687%201

This was actually an ad for Zilog's Z8000 processor, not the Z80 :-)


Regards,

Laust
0
Laust
5/20/2006 2:29:45 PM
Paul Schlyter wrote:

>> IIRC the S-JiffyDOS patch uses illegal opcodes to speed up GCR decoding.
>> (Jochen, are you reading here and can comment?)
> 
> That can also be done without illegal opcodes.  The Apple Pascal RWTS
> did it, and was able to read all sectors of a floppy on one revolution
> of the disk -- oncluding GCR decoding on-the-fly.

But isn't Apple GCR a bit simpler than commodore GCR? Apple's 16-sector 
format stores three data bytes per four disk bytes (3:4), Commodore gets 
in four data bytes per five disk bytes (4:5) IIRC.

-- 
Linards Ticmanis
0
Linards
5/20/2006 8:38:37 PM
John Selck wrote:
> Am 19.05.2006, 22:34 Uhr, schrieb Eric Smith <eric@brouhaha.com>:
> 
>> "John Selck" <gpjiweg@t-online.de> writes:
>>
>>> And then we would have ended up like the Z80: That a copy loop is faster
>>> than the actual block copy instruction :D
>>
>>
>> Can you cite an example?  The block move instructions on the Z80 are
>> actually fairly efficient.  They use three memory cycles to move a byte,
>> vs. the theoretical minimum of two.  Doing a block copy via a software
>> loop is going to require at least five memory cycles per byte moved, and
>> probably more.
> 
> 
> LDIR eats 21 clock cycles per iteration, doing the same with other Z80
> instructions can be way faster.
> 
> I tried to use the Z80 in the C128 for block copy/fill because I thought
> "hey, it has a block copy command, so I guess it is fast" but it wasn't.
> Then I tried normal opcodes, it was way faster than using LDIR but still
> not faster than copying the stuff with the 8502.
> 
> Here's a list of Z80 instruction and their clock cycles:
> 
> http://www.ftp83plus.net/Tutorials/z80inset1A.htm

I would like to point out that these are 21 Z80 clocks going twice the 
rate of a 6502 (I don't know if this is true for C128 but 1MHz 6502 is 
comparable to a 2MHz Z80 and were competing side by side). If you are 
going to move only a few bytes it is more efficient to do so by load, 
store, load, store etc... less setup and no looping.

I think you are wrong if you are talking about more data. LDIR is the 
most convenient and fastest way to copy a block of data with the Z80. I 
think doing any form of loop is slower. (Even if you use the POP 
instruction and keep within a page you end up at 21.5 clocks per byte).

The Z80 is not a memory oriented processor its strength is to have many 
registers (for the mid/late 70's) and to have efficient instructions 
using them. 6502 is contrary, it has almost no registers but do memory 
access more efficiently and ends up with a fairly similar performance. 
6502 might well do a memory block move faster than Z80.

To say something on this threads topic the Z80 also has 
undocumented/illegal opcodes and a few are convenient to use. These are 
a result of the instruction decoding and work in all the real Z80's. 
Most of the "illegal" instructions are just "advanced" NOP's that takes 
longer than a normal NOP. Some with strange effects on flags though. It 
is especially a topic for emulators, to do these correctly...

Knut
0
Knut
5/20/2006 11:01:40 PM
In article <446f7e4c$0$4512$9b4e6d93@newsread2.arcor-online.net>,
 Linards Ticmanis <ticmanis@gmx.de> wrote:

> Paul Schlyter wrote:
> 
> >> IIRC the S-JiffyDOS patch uses illegal opcodes to speed up GCR decoding.
> >> (Jochen, are you reading here and can comment?)
> > 
> > That can also be done without illegal opcodes.  The Apple Pascal RWTS
> > did it, and was able to read all sectors of a floppy on one revolution
> > of the disk -- oncluding GCR decoding on-the-fly.
> 
> But isn't Apple GCR a bit simpler than commodore GCR? Apple's 16-sector 
> format stores three data bytes per four disk bytes (3:4), Commodore gets 
> in four data bytes per five disk bytes (4:5) IIRC.

I've tinkered with code to decode both using a catweasel board.  The 
Apple GCR is more robust, but more complicated.  It has extra codes used 
for data marks (so there is no question where the data begins), it 
encodes 5 or 6 bits in 8 for more redundancy (you are more likely to get 
a bad nibble and know the sector is bad with no need for a checksum), 
and more important, the encoding relies on every nibble starting with a 
'1' bit, so after an error it has a good chance of getting back in 
nibble sync (and you might get some useful data from a bad sector).

However, the bits are stored in a crazy order.  After reading an Apple 
GCR sector, you have to run the 5-bit or 6-bit decoded nibble data 
through an unscrambler, which is different between 13 sector and 16 
sector encodings.  The 13 sector decoder is a total mess in C.

Commodore's GCR relies on long strings of 1s to synchronize, so if there 
is a glitch in the gap, you will think you see data, and by the time you 
figure it out, you could have gone too far and missed the real sector 
header.  I had lots of problems keeping sync with the sector headers.  I 
can't remember exactly, but I know I had to do a lot of tweaking to 
avoid false syncs.  And nibbles can start with either a 0 or a 1, so if 
you get lost, you will remain hopelessly out of sync with your data.
0
Bruce
5/21/2006 4:12:12 AM
Jim Brain wrote:
> Michael J. Mahon wrote:
> 
>> Not so.  The logical elements of the NMOS design are not present in
>> the same form in CMOS.  And the instruction decoding was clearly
>> redesigned, as was the control section (changed timings and bus cycle
>> patterns, new instructions).
> 
> 
> I guess we'll agree to disagree on the point.  I say all the design 
> elements are there (the 8 bit ALU, decimal mode, the 16 bit instruction 
> pointer, etc.)

I was referring to the precharge and transfer gates in the NMOS process.
Different gate designs are preferred in a CMOS process, and so different
circuits.

>  As for the instruction decoding, Bill just cleaned up 
> the don't cares, as I see it.  Hardly a huge new design.  The physical 
> elements changed, yes, but the logical perspective stayed the same. When 
> I interviewed him back in 1995, he said as much.  He simply wanted to 
> clean up the design and lay it out so he could take advantage of not 
> only the CMOS process but the ability to shrink the feature size every 
> so many years.  He hasn;t changed his design since the original.  He 
> just shrinks the design using the newer process and re-fabs.  That's how 
> he stated he got his speed increases.

The term "logical design" when applied to a processor means the
circuit diagram at the level of gates.

If the same circuit design is implemented in a different process,
the processor behavior will be identical, since it is the same
logical design (same signals, flows, timing, etc.).

If the same *architecture* is re-implemented with a new circuit
design, then only the *documented* behavior is likely to be
identical, since everything else is formally a "don't care".

>> That kind of behavior is of a completely different kind than random
>> bus clashes as multiple data sources are unintentionally gated onto
>> a bus!
> 
> I'll agree they are different, but the point was that they are both 
> undocumented behavior.  Intel found the undocumented behavior was used 
> all over, so they had to build in support for it.  Therefore, every new 
> Intel CPU supports this "undocumented behavior".  Of course, it is now 
> documented, so it becomes legitimate by virtue of so many people 
> exploiting it that it became the std.

*All* undocumented behavior includes both "well-behaved but
undocumented", "wierd but predictable undocumented behavior",
and "weird and unpredictable undocumented behavior".

The well-behaved stuff obeys the principle of least surprise,
and may be candidates for documentation and full support.

The rest is *never* such a candidate.  ;-)

And for a designer to be "forced" to support previously undocumented
behavior because it is "used all over" is *exactly* the point I've been
trying to make all along--this is *almost always* a bad thing.

The only exception I can think of is when a sensible design behaves
sensibly in some situations that the designer somehow neglected to
document, but should have.  Of course, the only real problem then is
correcting the documentation, since any "reasonable" design will be
likely to support the behavior in any case.

Even in this case, the matter should be broached publicly and an
agreement reached about what part of the originally undocumented
behavior will become documented, and thus sanctioned by the designer
in any future implementations.

>> Long after the 65C02 design was available, lower power, faster, and
>> cheaper to make, the CBM line could not easily make use of it.
> 
> 
> If it had made economic sense, CBM would have tasked Mensch to add the 
> errata into the C02.  Apple got Bill to change the 816 timings, and CBM 
> had more clout with Bill, since they originally helped set up WDC.

Possibly, but clout is usually dependent on the promise of orders,
not good feelings...  ;-)

If WDC didn't get money from CBM, they wouldn't have much influence.

I'm guessing that CBM just kept turning the crank on their proprietary
6502 implementation(s), and were not motivated to pursue the 65C02.

> But, I'll concede the point that it would have required more cash and 
> time than the Apple II line needed.
> 
> I guess, in priciple, I agree with you that undocs fly against the rule 
> of programming.  HOwever, in the CBM environment, the rules are a bit 
> different.  As well, regardless of how one views the use of undocs, I'm 
> not willing to be harsh on the MOS folks for what they did.  They made a 
> $20 CPU and got Woz and the Bushnell interested in using CPUs, which 
> brought all of us to where we are today.  I won't let a few space and 
> time saving details that made perfect since in the early 1970's cloud that.

I don't fault them for what they did, either--I was just pointing out
that we don't do things that way anymore, and for good reason: we
found out by (sad) experience that programmers cannot be trusted
to "keep off the undocumented grass".  ;-)

And I also agree that for any platform with a single, unchanging
implementation, as most retro platforms are today, the use of
stable undocumented behavior is not a practical problem.

My whole point is that it is a *very* bad idea for an evolving
platform, since it can seriously hamper evolution by causing
compatibility breaks.

-michael

Music synthesis 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."
0
Michael
5/22/2006 8:24:23 AM
Stephen Harris wrote:

> And now you've introduced program bloat, dual code paths, extra potential for
> bugs...

That's the way you handle low level stuff. All your Windows XP drivers 
are doing the same, and all the games which support SSE or MMX instructions.

Doing it the "one routine works for every condition" way usually means 
10 times slower programs.
0
John
5/22/2006 12:09:26 PM
In article <446f7e4c$0$4512$9b4e6d93@newsread2.arcor-online.net>,
Linards Ticmanis  <ticmanis@gmx.de> wrote:

> Paul Schlyter wrote:
> 
>>> IIRC the S-JiffyDOS patch uses illegal opcodes to speed up GCR decoding.
>>> (Jochen, are you reading here and can comment?)
>> 
>> That can also be done without illegal opcodes.  The Apple Pascal RWTS
>> did it, and was able to read all sectors of a floppy on one revolution
>> of the disk -- oncluding GCR decoding on-the-fly.
> 
> But isn't Apple GCR a bit simpler than commodore GCR? Apple's 16-sector 
> format stores three data bytes per four disk bytes (3:4), Commodore gets 
> in four data bytes per five disk bytes (4:5) IIRC.

Dunny about that.  Apple 13-sector format stored 5 data bytes ber 8 disk bytes
(5:8), which was less efficient than (3:4) --- still, the denibblizing code
was a bit longer in the (5:8) case than the (3:4) case.

-- 
----------------------------------------------------------------
Paul Schlyter,  Grev Turegatan 40,  SE-114 38 Stockholm,  SWEDEN
e-mail:  pausch at stockholm dot bostream dot se
WWW:     http://stjarnhimlen.se/
0
pausch
5/22/2006 12:13:20 PM
In article <e4s9lm$r0g$1@rzsun03.rrz.uni-hamburg.de>,
John Selck  <selck_j@informatik.hgv-hamburg.de> wrote:
>Stephen Harris wrote:
>
>> And now you've introduced program bloat, dual code paths, extra potential for
>> bugs...
>
>That's the way you handle low level stuff. All your Windows XP drivers 
>are doing the same, and all the games which support SSE or MMX instructions.

You can do that today, with GigaBytes of RAM available.  But doing it on
an Apple II, with 48k (or less) RAM is a waste of memory resources.


>Doing it the "one routine works for every condition" way usually means 
>10 times slower programs.

....of course "10 times slower" doesn't matter much with today's fast
processors.  That's why Java has succeeded while UCSD Pascal failed,
even though they both built upon the same concept: portable binary code
which was to be interpreted on the target hardware.


-- 
----------------------------------------------------------------
Paul Schlyter,  Grev Turegatan 40,  SE-114 38 Stockholm,  SWEDEN
e-mail:  pausch at stockholm dot bostream dot se
WWW:     http://stjarnhimlen.se/
0
pausch
5/22/2006 12:43:05 PM
Michael J. Mahon wrote:

> The term "logical design" when applied to a processor means the
> circuit diagram at the level of gates.
I thought that was called the "logic" design.  Maybe they switched terms 
since my VLSI days.  By that definition, I agree vehemently.  Mensch 
would have used the subsequent years knowledge and best practices of 
CMOS to design the WDC parts.

> The rest is *never* such a candidate.  ;-)

Splitting hairs, but I'd put some of the NMOS illops in the well-behaved 
category.  The illops that simply performed two ALU operations (and / 
xor, or whatever) would be well-behaved.
> And for a designer to be "forced" to support previously undocumented
> behavior because it is "used all over" is *exactly* the point I've been
> trying to make all along--this is *almost always* a bad thing.
Can't argue there.  I seem to recall Bill even balked at having to 
change his C816 design for the IIGS.  I don;t recall the details though. 
  Something about the timing.  He would have really taken exception at 
supporting don;'t cares.

> Possibly, but clout is usually dependent on the promise of orders,
> not good feelings...  ;-)
Again, no argument there.  The story is that Jack helped set Bill up 
with WDC, promising orders, and then cancelled the projects that would 
have made those orders.  But, he did not drag Bill to court, which is 
surprising.  I think he hedged his bets, assuming they would eventually 
need the new process, but they never did.

> I'm guessing that CBM just kept turning the crank on their proprietary
> 6502 implementation(s), and were not motivated to pursue the 65C02.
Bagnall's book stated that Peddle and others knew the 6502 design had 
run out of steam in the early 1980's, but the project to move it on 
never thrived.  It was a cash cow by that time.  And, Jack cared not at 
all for backward compatibility, so all of this discussion is moot in the 
CBM environment.  If there had been some financial incentive to design a 
new CPU, it would not have included the illops, and it may have changed 
the architecture and opcode set as well.

> I don't fault them for what they did, either--I was just pointing out
> that we don't do things that way anymore, and for good reason: we
> found out by (sad) experience that programmers cannot be trusted
> to "keep off the undocumented grass".  ;-)
I wasn't directing that at you per se.  I just saw a lot of posts on 
this thread along the lines of "If I had designed the CPU..."  Bah, I 
say.  Those guys taped out a CPU when you still had to use tape.  Kudos 
to them.

> And I also agree that for any platform with a single, unchanging
> implementation, as most retro platforms are today, the use of
> stable undocumented behavior is not a practical problem.
It does cause issues, as emulator authors have to jump through hoops to 
support it, and the DTV designer left illops out of the original version 
of the unit, due to complexity and time issues.
0
Jim
5/22/2006 2:25:29 PM
Paul Schlyter wrote:
> You can do that today, with GigaBytes of RAM available.  But doing it on
> an Apple II, with 48k (or less) RAM is a waste of memory resources.

Since you know what CPU your code is running on, nobody forces you to 
keep both routines in memory.

> ...of course "10 times slower" doesn't matter much with today's fast
> processors.  That's why Java has succeeded while UCSD Pascal failed,
> even though they both built upon the same concept: portable binary code
> which was to be interpreted on the target hardware.

It depends on what you do. If you do lot's of graphics and sound stuff, 
Java is definitely a bad choice.
0
John
5/23/2006 12:00:15 PM
In article <e4utgf$f21$1@rzsun03.rrz.uni-hamburg.de>,
John Selck  <selck_j@informatik.hgv-hamburg.de> wrote:
>Paul Schlyter wrote:
>> You can do that today, with GigaBytes of RAM available.  But doing it on
>> an Apple II, with 48k (or less) RAM is a waste of memory resources.
>
>Since you know what CPU your code is running on, nobody forces you to 
>keep both routines in memory.

Swapping pieces of code on/off to floppy disks would be QUITE slow... :-)

>> ...of course "10 times slower" doesn't matter much with today's fast
>> processors.  That's why Java has succeeded while UCSD Pascal failed,
>> even though they both built upon the same concept: portable binary code
>> which was to be interpreted on the target hardware.
>
>It depends on what you do. If you do lot's of graphics and sound stuff, 
>Java is definitely a bad choice.

In such a case, UCSD Pascal would be an even worse choice.....


-- 
----------------------------------------------------------------
Paul Schlyter,  Grev Turegatan 40,  SE-114 38 Stockholm,  SWEDEN
e-mail:  pausch at stockholm dot bostream dot se
WWW:     http://stjarnhimlen.se/
0
pausch
5/23/2006 2:43:52 PM
Paul Schlyter wrote:
> Swapping pieces of code on/off to floppy disks would be QUITE slow... :-)

Where do you see any swapping (if it hasn't been there before)?

>> It depends on what you do. If you do lot's of graphics and sound stuff, 
>> Java is definitely a bad choice.
> 
> In such a case, UCSD Pascal would be an even worse choice.....

That's why C/C++ is used for such tasks with a bit of inline assembly 
for the inner loops.
0
John
5/23/2006 4:00:40 PM
John Selck wrote:
> Stephen Harris wrote:
> 
>> And now you've introduced program bloat, dual code paths, extra 
>> potential for
>> bugs...
> 
> 
> That's the way you handle low level stuff. All your Windows XP drivers 
> are doing the same, and all the games which support SSE or MMX 
> instructions.

This works only when the behavior of all versions are known, and they
can be differentiated by software tests.

Since it is difficult to predict which undocumented behavior(s) would
be present in a future chip, it cannot, in general, allow for future
chips, except in the special case where the "test" encompasses *exactly*
the behavior that the exploiting code uses (no more, no less).

> Doing it the "one routine works for every condition" way usually means 
> 10 times slower programs.

Oh, come now--even the wildest example given (just the inner loop) was
less than a factor of 2 different.  The vast majority of uses of such
undocumented "features" have negligible effects on any important
measure--they are just hacks, in the worst sense.

Modern programming practice does allow for code (and even algorithms)
tailored to specific processor levels, but only when there is a method
for differentiating implementations that is architectural, and therefore
sanctioned by the manufacturer(s).  Of course, most compilers don't
offer support for this, except in some embedded environments.

-michael

Music synthesis 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."
0
Michael
5/23/2006 9:52:49 PM
Jim Brain wrote:
> Michael J. Mahon wrote:

>> I don't fault them for what they did, either--I was just pointing out
>> that we don't do things that way anymore, and for good reason: we
>> found out by (sad) experience that programmers cannot be trusted
>> to "keep off the undocumented grass".  ;-)
> 
> I wasn't directing that at you per se.  I just saw a lot of posts on 
> this thread along the lines of "If I had designed the CPU..."  Bah, I 
> say.  Those guys taped out a CPU when you still had to use tape.  Kudos 
> to them.

Actually, they didn't even use mag tape--they used rubylith tape to make
the optical masters for the masks.

The actual layout was done on the floor of a large room using little
scooting "skateboards" like mechanics use to go under cars, and using
Xacto knives!

Ah, those were the days of "wooden chips and iron men".  ;-)

>> And I also agree that for any platform with a single, unchanging
>> implementation, as most retro platforms are today, the use of
>> stable undocumented behavior is not a practical problem.
> 
> It does cause issues, as emulator authors have to jump through hoops to 
> support it, and the DTV designer left illops out of the original version 
> of the unit, due to complexity and time issues.

Yes, that's true.  Emulators *are* the "new implementation" for these
old platforms, and they incur the full penalty for any exploitation
of undocumented behavior--both in determing what it is (since it's
undocumented ;-), and then in replicating it.

-michael

Music synthesis 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."
0
Michael
5/23/2006 10:01:43 PM
Eric Smith wrote:
> "Michael J. Mahon" <mjmahon@aol.com> writes:
> 
>>The 6502 was already a much less expensive processor than its
>>competitors, because of a mask retouching technique MOS Technology
>>developed that saved mask iterations.
> 
> 
> I saw that claim on Wikipedia.  Is there any published reference?

I saw it in an interview published on the web, but I apparently
didn't bookmark it.  I'll let you know if I find it...

> Stephen Harris wrote:
> 
>>With the 6502 essentially not having a microcode level, this
>>optimisation is exposed to the programmer.
> 
> 
> The PLA is essentially equivalent to microcode.  The difference is
> that it is addressed by the instruction register and a few state bits,
> rather than a micro-PC.

Exactly.  I once worked on a machine that had an unusual "distributed
PLA" approach:  the opcode register and state counter were bussed
along the backplane of the machine, and each opcode (or small family
of similar ops) was decoded on the plugin card(s) that implemented
it.  It was the only machine I ever saw where individual ops could
be removed from the machine by unplugging their cards!

-michael

Music synthesis 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."
0
Michael
5/23/2006 10:08:07 PM
heuser.marcus@freenet.de wrote:
>>>The 6502 was already a much less expensive processor than its
>>>competitors, because of a mask retouching technique MOS Technology
>>>developed that saved mask iterations.
>>
>>I saw that claim on Wikipedia.  Is there any published reference?
> 
> 
> There is book about the history of Commodore which is rather detailed
> (and entertaining) about the MOS history, too:
> http://www.commodorebook.com
> 
> The MOS chapter can be read freely here:
> http://www.commodorebook.com/view.php?content=toc
> 
> Excerpt:
> 
> At MOS Technology, John Pavinen pioneered a new way to fabricate
> microprocessors. "They were one of the first companies to use
> non-contact mask liners," says Peddle. "At that time everybody was
> using contact masks."
> 
> With non-contact masks, the metal die did not touch the wafer. Once the
> engineers worked out all the flaws in the mask, it would last
> indefinitely.
> 
> ---
> 
> I guess, Chuck Peddle is a good enough reference ;-)

But clearly the author didn't "get" the subject very well...

Here, he clearly means "the metal *mask* did not touch...", and
later he refers to one of the metal layers being *germanium*!

-michael

Music synthesis 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."
0
Michael
5/23/2006 11:32:18 PM
Eric Smith wrote:
> "Michael J. Mahon" <mjmahon@aol.com> writes:
> 
>>The 6502 was already a much less expensive processor than its
>>competitors, because of a mask retouching technique MOS Technology
>>developed that saved mask iterations.
> 
> 
> I saw that claim on Wikipedia.  Is there any published reference?

Although the target was dead, the Google cached page at:

http://66.102.7.104/search?q=cache:uNXP83T5hq0J:www.commodore.ca/history/company/mos/mos_technology.htm+6502+die+photo&hl=en&gl=us&ct=clnk&cd=5

(sorry about the length) is "The Rise of MOS Technology & The 6502" 
Written by Ian Matthews of commodore.ca February 15, 2003, Seriously 
revised and expanded on January 18, 2006.

The relevant excerpt follows:

 >>>
In the 1970's, 70% of the industries chip production were defective and 
therefore garbage. This substantially increases the cost of each viable 
chip. When a chip is being laid out for etching on a silicon wafer, it 
drawn at a large scale and then photo reduced over an over again (just 
like a photocopy reduction) until its microscopic size will fit on the 
required die. Each reduction layer is called a Mask. MOS figured out a 
process to repair Masks as they are reduced. The end result was that 
they had a 70% success rate. This obviously reduced the per chip cost of 
manufacturing and made the $25 processor a possibility.
<<<

Frankly, this article (like virtually all technology articles) has
enough casual inaccuracies (like spelling Mensch's name Mench), that
I can't be sure that this is an accurate rendition of the truth.
But is is a plausible story, since repairing a mask master later
than the rubylith stage is a time and cost win.

-michael

Music synthesis 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."
0
Michael
5/24/2006 12:00:12 AM
John Selck wrote:
> Am 19.05.2006, 06:28 Uhr, schrieb mdj <mdj.mdj@gmail.com>:
> 
>> Of course, the point remains though that your would never do this on
>> the Apple II series, as you'd limit your target market to the earliest
>> machine, rather than just the lowest common denominator of all machines
>> (64k, 6502 code that's documented and unbuggy)
> 
> 
> It's easy to do a processor check.

It's not easy unless you either 1) know exactly how all machines
that your code will ever see behave, or 2) test *exactly* the
undocumented behavior that you use--no more and no less.  Even
in the latter case, you risk the test code being error trapped,
so you have to cover that case, too.  (Hard if the error trap
comes along in the future using an architecture extension that
you don't know in the past. ;-)

So *both* strategies depend on knowing the future, which, as
Yogi pointed out, is diffcult.  ;-)

-michael

Music synthesis 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."
0
Michael
5/24/2006 12:10:43 AM
Linards Ticmanis wrote:
> Michael J. Mahon wrote:
> 
>> Wow--they needed more than a megabyte/second of video data?  I guess
>> if you have about the same resolution as an Apple II, but twice the
>> color depth, then you do...  The //c and following Apple II's got
>> around this by providing another memory bank in parallel with the
>> main memory bank.
> 
> 
> The C64 mainly needed it for its text mode. Unlike the Apple, the 
> character shapes reside within the Video chip's AND the CPUs normal 
> memory map, are read over the normal address bus, and can be redefined 
> by pointing a register to RAM instead of ROM.
> 
> So once every line of characters the CPU has to stop for 40 cycles, so 
> that the character numbers can be read and stored. Then during the 
> normal video cycles only the character shapes are read. Color numbers 
> for the characters, on the other hand, are read in parallel from a 
> special SRAM with its own addressing lines going to the video chip.
> 
> The Apple reads the character numbers on every line during its normal 
> video access, and reads the character shapes in parallel from a ROM 
> that's not visible to the CPU. Thus you have fixed character shapes.#

Of course, the character generator ROM could have been an SRAM, and
could have been made visible (byte sequentially, say) on an Apple.

It was a conscious choice to make the Apple character set fixed.
(And it's nice to have a character set fully defined at power-up.)

-michael

Music synthesis 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."
0
Michael
5/24/2006 12:17:20 AM
> It depends on what you do. If you do lot's of graphics and sound stuff,
> Java is definitely a bad choice.

Ha. You think so? I have friends in the mobile handset game market that
would disagree with you. In fact even on the PC it's not "definitely a
bad choice". Have you had a look at Java Quake?

All this 10 times slower stuff for managed code is nonsense. Tell that
to Microsoft, who are betting on .NET binaries compatible across all
their platforms. This relates directly to your topic of discussion. JIT
compiles at runtime for YOUR processor. Not the lowest common
denominator.

Cheers,
Nick.

0
sicklittlemonkey
5/24/2006 10:36:01 AM
"Michael J. Mahon" <mjmahon@aol.com> writes:

>>The C64 mainly needed it for its text mode. Unlike the Apple, the 
>>character shapes reside within the Video chip's AND the CPUs normal 
>>memory map, are read over the normal address bus, and can be redefined 
>>by pointing a register to RAM instead of ROM.

[...]
>It was a conscious choice to make the Apple character set fixed.
>(And it's nice to have a character set fully defined at power-up.)

This is a marginal diversion, but I'm not sure what you mean by "fully
defined" since the C64's is, of course, also fully defined in the sense
that it's there. :)

--
      Cameron Kaiser * ckaiser@floodgap.com * posting with a Commodore 128
                personal page: http://www.armory.com/%7Espectre/
  ** Computer Workshops: games, productivity software and more for C64/128! **
                  ** http://www.armory.com/%7Espectre/cwi/ **
0
Cameron
5/24/2006 12:04:04 PM
> It depends on what you do. If you do lot's of graphics and sound stuff,
> Java is definitely a bad choice.

Are we talking about Java 1.2 or are we talking about the modern
1.4/1.5 java runtimes with JIT compiler support.  Surely you must have
looked at the advances in java technology before making such a blanket
statement!

And as for pushing heavy graphics and sound through an apple computer,
the apple game server works very well in java, thank you very much!  :-P

0
BLuRry
5/24/2006 2:24:36 PM
Cameron Kaiser wrote:
> "Michael J. Mahon" <mjmahon@aol.com> writes:
> 
> 
>>>The C64 mainly needed it for its text mode. Unlike the Apple, the 
>>>character shapes reside within the Video chip's AND the CPUs normal 
>>>memory map, are read over the normal address bus, and can be redefined 
>>>by pointing a register to RAM instead of ROM.
> 
> 
> [...]
> 
>>It was a conscious choice to make the Apple character set fixed.
>>(And it's nice to have a character set fully defined at power-up.)
> 
> 
> This is a marginal diversion, but I'm not sure what you mean by "fully
> defined" since the C64's is, of course, also fully defined in the sense
> that it's there. :)

I meant that there was no SRAM to initialize to provide a character
set--but perhaps I misunderstood the explanation of character generation
in the C=64.

-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."
0
Michael
5/24/2006 3:09:13 PM
sicklittlemonkey wrote:
>> It depends on what you do. If you do lot's of graphics and sound stuff,
>> Java is definitely a bad choice.
> 
> Ha. You think so? I have friends in the mobile handset game market that
> would disagree with you. In fact even on the PC it's not "definitely a
> bad choice". Have you had a look at Java Quake?

Lol, yeah Java on mobile is an especially cool example of "Java power" 
where Giana Sisters runs jerky as hell on a ~300 MHz CPU, while a lame 
old 1 MHz 8 bit computer could do it smooth in 50 fps.

> JIT compiles at runtime for YOUR processor. Not the lowest common
> denominator.

I have yet to see an example of pure rendering where a JIT comes even 
close to lame C++ programming.
0
John
5/24/2006 4:17:33 PM
Michael J. Mahon wrote:

> This works only when the behavior of all versions are known, and they
> can be differentiated by software tests.
> 
> Since it is difficult to predict which undocumented behavior(s) would
> be present in a future chip, it cannot, in general, allow for future
> chips, except in the special case where the "test" encompasses *exactly*
> the behavior that the exploiting code uses (no more, no less).

SHX/SHY have been replaced with STZ on later CPUs, so there is no 
problem with future chips since either these chip's expand the old 
instruction set which has STZ already, or it is incompatible anyway 
since it does not implement all the former legal opcodes.

> Modern programming practice does allow for code (and even algorithms)
> tailored to specific processor levels, but only when there is a method
> for differentiating implementations that is architectural, and therefore
> sanctioned by the manufacturer(s).  Of course, most compilers don't
> offer support for this, except in some embedded environments.

Ok, next time I will ask MOS if the use of illegal opcodes is sanctioned 
by them... Oh wait, MOS doesn't exist anymore for almost 20 years now :D
0
John
5/24/2006 4:47:56 PM
In article <1148480676.109301.184350@y43g2000cwc.googlegroups.com>,
BLuRry <brendan.robert@gmail.com> wrote:

> > It depends on what you do. If you do lot's of graphics and sound stuff,
> > Java is definitely a bad choice.
> 
> Are we talking about Java 1.2 or are we talking about the modern
> 1.4/1.5 java runtimes with JIT compiler support.

Let's talk about Java 2 !!!  :-)

> Surely you must have looked at the advances in java technology before
> making such a blanket statement!
> 
> And as for pushing heavy graphics and sound through an apple computer,
> the apple game server works very well in java, thank you very much!  :-P

-- 
----------------------------------------------------------------
Paul Schlyter,  Grev Turegatan 40,  SE-114 38 Stockholm,  SWEDEN
e-mail:  pausch at stockholm dot bostream dot se
WWW:     http://stjarnhimlen.se/
0
pausch
5/24/2006 7:13:30 PM
>Let's talk about Java 2 !!!  :-)

**vomits**

Ok, I'll give the critics that much.  Java 1.2 was far from fantastic
in terms of performance. ;-)  But if anyone has still neglected to
update to at least 1.3, I have no pity...

(hey, when is this thread gonna die?!)

0
BLuRry
5/24/2006 8:16:34 PM
Well, the virtualization of the java screen buffer is meant for
portability.  Meaning, there's a thick layer of abstraction designed to
make average GUI apps easy to develop and port to other systems.  Even
if JIT speeds up some aspects of the emulation, those layers are still
present.  It is unfortunate.

However, if you were to take an approach more similar to SWT where
everything is native (albeit much less portable) then I think you'd see
a performance difference.  Eclipse users claim there is a significant
difference in that regard, where SWT originated.  Supposedly java 1.6
will address the slowness of the AWT/Swing layer.   We shall see.

Obviously you don't have a very thick layer for UI stuff in MIDP
applications so there's less crap for the embedded JRE to wade through
to draw a tiny little screen.

So compare apples to apples -- raw computing power in "headless"
programs is pretty comparable when you compare Java/JIT vs. native C++
-- oops I meant to say .NET c++ runtimes.  And .NET "technology" is
inherently a recycled and improved version of the technology microsoft
was court-ordered to stop producing as "java", but you didn't expect
they would just throw it away did you?  I mean, with all those
non-standard compiler directives you know they were going to try to
poison java's portability anyway so they stay at the top.

Except without a lot of third-party libraries (kudos to apache and
gnu!), creating complex data structures (without fear of memory leaks)
and performing heavy data manipulation -- especially xml -- in c++ is a
royal pain in the you-know-what.  I'll stick with java for my day-job
and 6502 for my hobby. :-)

(weren't we talking about illegal opcodes?  is that an arrestable
offense?)

0
BLuRry
5/24/2006 9:59:39 PM
"Michael J. Mahon" <mjmahon@aol.com> writes:

>>>>The C64 mainly needed it for its text mode. Unlike the Apple, the 
>>>>character shapes reside within the Video chip's AND the CPUs normal 
>>>>memory map, are read over the normal address bus, and can be redefined 
>>>>by pointing a register to RAM instead of ROM.

>>>It was a conscious choice to make the Apple character set fixed.
>>>(And it's nice to have a character set fully defined at power-up.)

>>This is a marginal diversion, but I'm not sure what you mean by "fully
>>defined" since the C64's is, of course, also fully defined in the sense
>>that it's there. :)

>I meant that there was no SRAM to initialize to provide a character
>set--but perhaps I misunderstood the explanation of character generation
>in the C=64.

Ah, okay. In the C64's case, there isn't a need to copy to RAM either; the
VIC-II video chip can simply use Character ROM as it is positioned in the
default memory map. The sole difference is that the character set doesn't
*have* to come from the Character ROM; it can come from most other places
in RAM, too. But it is fully defined and ready to go on start-up without
loading it into RAM, yes.

--
      Cameron Kaiser * ckaiser@floodgap.com * posting with a Commodore 128
                personal page: http://www.armory.com/%7Espectre/
  ** Computer Workshops: games, productivity software and more for C64/128! **
                  ** http://www.armory.com/%7Espectre/cwi/ **
0
Cameron
5/24/2006 10:42:03 PM
"Michael J. Mahon" <mjmahon@aol.com> writes:
> Of course, the character generator ROM could have been an SRAM, and
> could have been made visible (byte sequentially, say) on an Apple.
> 
> It was a conscious choice to make the Apple character set fixed.
> (And it's nice to have a character set fully defined at power-up.)

The Apple III used an SRAM for the character generator, but it wasn't
directly memory mapped.

The boot ROM contained a very crude partial character set which was
decompressed and loaded into the character generator RAM at power-up.

Once the operating system was booted, the SOS driver for .CONSOLE was
responsible for the character generator.  It loads a default character
set, and provides a way for an application to change it.

The Apple II emulation disk loads the Apple II character set.

The way the hardware works is that you load the character set image
into main RAM, then set a bit on one of the VIA ports.  This makes
the video hardware copy the character set from main RAM into the
character generator RAM.  Pretty clever, and it avoids needing
faster main RAM that would be needed if the character generator was
mapped in main RAM.
0
Eric
5/24/2006 11:11:27 PM
> Lol, yeah Java on mobile is an especially cool example of "Java power"
> where Giana Sisters runs jerky as hell on a ~300 MHz CPU, while a lame
> old 1 MHz 8 bit computer could do it smooth in 50 fps.

It's not clear what you're criticisizing here. A poor re-implementation
of a particular game; a poor JVM implementation on a particular
platform ...

> I have yet to see an example of pure rendering where a JIT comes even
> close to lame C++ programming.

This is why I mentioned Java Quake (Jake2) which in some cases exceeds
the framerate of the original C version:
http://www.bytonic.de/html/benchmarks.html

Anyway, we seem to have strayed off the path ...

Cheers,
Nick.

0
sicklittlemonkey
5/25/2006 2:49:35 AM
In article <1148507979.618765.249330@j73g2000cwa.googlegroups.com>,
BLuRry <brendan.robert@gmail.com> wrote:

> I mean, with all those non-standard compiler directives you know they were
> going to try to poison java's portability anyway so they stay at the top.

What "Java portability" ????

Java is not a portable language.  Java is less portable than both
FORTRAN, C or C++, which runs on several platforms.  Java runs on one
single platform only: the Java platform.

The Java platform doesn't exist in hardware - it must be simulated
in software.  "But that means Java is portable: I can run my JVM on
several other platforms" -- true, but if you define "portability" in
such a way, then all Windows software becomes equally portable: just
start your favourite Windows emulator on either your Mac or your Linux
machine, and run your Windows software on it....

-- 
----------------------------------------------------------------
Paul Schlyter,  Grev Turegatan 40,  SE-114 38 Stockholm,  SWEDEN
e-mail:  pausch at stockholm dot bostream dot se
WWW:     http://stjarnhimlen.se/
0
pausch
5/25/2006 6:42:48 AM
Paul Schlyter wrote:

> What "Java portability" ????
>
> Java is not a portable language.  Java is less portable than both
> FORTRAN, C or C++, which runs on several platforms.  Java runs on one
> single platform only: the Java platform.

Sorry, this isn't true. The Java language specification is quite
deliberately void of any language construct  that would bind it, or any
program written in it to a specific architecture. The key concepts that
are missing here are pointers, and more specifically, the ability to
perform arbitrary arithmetic on pointer types. Additionally, the
language specification defines EXACTLY the size and precision of each
data type. C and C++ on the other hand, not only allow arbitrary
pointer arithmetic, but also only define in the standard, the minimum
size requirements of each data type.

It is impossible to write a Java program that's bound to a specific
machine architecture. With C/C++ it's easy, and common to do so. In
fact, the ability of C/C++ to do such things is what makes it such a
useful language for low level programming, virtually replacing the need
for assembly language, except in cases of utilising the varied
coprocessors that adorn modern CPU's. Ever tried porting some C code to
a 64 bit platform? Many C compilers implement int as a 32 bit quantity
even on 64 bit architectures, which completely hoses an enormous amount
of C code, which wrongly assumes that int and int * are the same size,
simply because for many years on most implementations, it was.

You could point out that this is terrible coding practice, and I'd
agree with you. It was however one of the most common optimisations you
could do in C, and was frequently done precisely because of the
performance advantage it had.

The first 64 bit platform that GNU/Linux was self hosting on was the
Alpha (God bless it's soul). This particular portability issue with C
was the primary reason many good open source programs were not
available on this architecture.

Java can, and has, been implemented without the virtual machine. The
GNU compiler for Java for instance, can generate machine-code 'class'
files that run on a UNIX platform using the standard dynamic library
loader mechanisms available there. It can do this from both Java
source, and Java bytecode. Even if the VM is taken away, the source
level representation is still portable to any other Java
implementation.

Amusingly, there are a few higher level scripting languages out there
that are actually 'less portable' than java, because they provide
machine level access facilities that totally destroy the independence
of code written to use them.

> The Java platform doesn't exist in hardware - it must be simulated
> in software.  "But that means Java is portable: I can run my JVM on
> several other platforms" -- true, but if you define "portability" in
> such a way, then all Windows software becomes equally portable: just
> start your favourite Windows emulator on either your Mac or your Linux
> machine, and run your Windows software on it....

I'd be interested to hear a definition of 'portable' that doesn't apply
to Java, platform or language. I'd be prepared to conceed that perhaps
Linux could be considered "more portable" as it's a 'platform' that's
been ported to more architectures than perhaps any other in history.
The fact remains though, than even with Linux, one must be very
cautious not to write code in a machine dependant way while using it's
'natural' languages.

The big issue that existed with Microsofts implementation of Java, was
that they extended the language to permit pointer manipulation and
direct calls to native code segments, so that you can directly call the
Win32 API. This enabled them to easily generate Java stubs for the
entire Win32 API. This compromises not only the portability of Java
programs, but also the security model provided by the Java platform,
which is dependent on programs not being able to access memory that
belong to the VM, or any other program that's running in the same
memory space.

Ironically, Microsoft made the same design decision with .NET, by
providing the facility of unmanaged code. While this allows you to
easily leverage existing functionality, it also ties you to it, and is
undoubtedly the primary reason there was no 64 bit .NET VM for IA64 for
so long. Is there even one now? I bet Intel people, particularly on the
64 bit side of the fence curse Microsoft every night, as without the
ties that MS has between it's operating system and x86 architecture,
there'd be a lot more room in the marketplace for  a successor to x86,
rather than just another extension.

My only real gripe with the Java platform is that it's controlled,
essentially, by a single company with it's own agenda. There's still no
complete implementation of Java that's independent of Suns, and
everyone on the supposed JCP ultimately has to play second fiddle to
Suns iron first. To be though, this is still significantly better than
being tied to both a proprietary platform, and a machine architecture,
which is essentially the position that Microsoft developers are now in.

For me, the reason UNIX has endured as a platform for so long is that
it remains the ONLY platform which has a well specified, simple,
architecture agnostic API, and as a result has been implemented and
ported many times over. The next most ported platform after UNIX, is
probably Java, and it'll probably stay that way for quite some time.

Matt

0
mdj
5/25/2006 8:10:21 AM
In article <e53i7m$1set$1@merope.saaf.se>,
 pausch@saaf.se (Paul Schlyter) wrote:

> The Java platform doesn't exist in hardware - it must be simulated
> in software.  "But that means Java is portable: I can run my JVM on

I thought Java bytecodes, or at least a significant portion of them, 
actually had been implemented in hardware.  But I know for certain that 
UCSD P-code had been implemented in hardware once at least once in the 
mid '80s.  I think it was called the "P-Engine", and Jerry Pournelle 
mentioned it in his column in Byte.

Likewise, I recall that a significant portion of Smalltalk bytecodes and 
primitives were implemented in hardware at Xerox, using the Dorado's 
capability for downloadable microcode.

So just because someone makes up an instruction set for a virtual 
machine doesn't mean that it can't (or won't) be implemented in 
hardware.  There may be a few of the more complicated instructions that 
have to be trapped out and implemented in terms of the less complicated 
instructions, but if someone feels a need to do so, it can get 
implemented in hardware.  (So when is someone going to take up the 
challenge and implement Zork's instruction set in VHDL?)
0
Bruce
5/25/2006 2:37:40 PM
> I thought Java bytecodes, or at least a significant portion of them,
> actually had been implemented in hardware.

There are indeed implementations.

IIRC Sun tried to establish a hardware platform for "web computing"
(those small diskless PCs with funky colors looking like coffee
machines):

http://news.com.com/Java+chip+not+picking+up+steam/2100-1033_3-216359.html

It failed miserably, but that didn't stop others

http://www.xilinx.com/prs_rls/0134lavacore.htm
http://www.particle.kth.se/~lindsey/JavaCourse/Book/Part3/Chapter24/chips.html

bye
Marcus

0
heuser
5/25/2006 4:34:53 PM
Paul Schlyter wrote:
> The Java platform doesn't exist in hardware - it must be simulated
> in software.  "But that means Java is portable: I can run my JVM on

Bruce Tomlin wrote:
> I thought Java bytecodes, or at least a significant portion of them, 
> actually had been implemented in hardware.

Yes, Sun offered several chips that executed Java bytecodes.  They
were not commercially successful.

> But I know for certain that 
> UCSD P-code had been implemented in hardware once at least once in the 
> mid '80s.  I think it was called the "P-Engine", and Jerry Pournelle 
> mentioned it in his column in Byte.

Western Digital "Pascal Microengine".  It implemented the p-code interpreter
in microcode, on the same chipset used in the LSI-11 and Alpha Micro AM100.

> Likewise, I recall that a significant portion of Smalltalk bytecodes and 
> primitives were implemented in hardware at Xerox, using the Dorado's 
> capability for downloadable microcode.

Yes, and before that on the Xerox Alto.

> (So when is someone going to take up the 
> challenge and implement Zork's instruction set in VHDL?)

Sounds like a fun project; if I didn't already have a zillion projects
I want to do, I'd be tempted.
0
Eric
5/25/2006 8:02:09 PM
In article <1148544621.115246.248890@y43g2000cwc.googlegroups.com>,
mdj <mdj.mdj@gmail.com> wrote:

> Paul Schlyter wrote:
> 
>> What "Java portability" ????
>>
>> Java is not a portable language.  Java is less portable than both
>> FORTRAN, C or C++, which runs on several platforms.  Java runs on one
>> single platform only: the Java platform.
> 
> Sorry, this isn't true. The Java language specification is quite
> deliberately void of any language construct that would bind it, or any
> program written in it to a specific architecture.

Java is not unique in this respect - languages like FORTRAN, C, C++,
Pascal and Ada are also void of any language construct that would bind
it, or any program written in it, to a specific architecture.  To
write non-portable programs in these languages you almost always have
to use implementation specific extensions (with the exception of C and C++,
where you can use pointes for a lot of architecture dependent stuff -- otoh
if you read the standards of these languages carefully, the behaviour of
such programs is described as "undefined").

> The key concepts that are missing here are pointers, and more specifically,
> the ability to perform arbitrary arithmetic on pointer types.

FORTRAN, Pascal and Ada lacks this too.

> Additionally, the language specification defines EXACTLY the size and
> precision of each data type.

....which will limit Java to architectures having exactly these sizes and
precisions of their data types.  Do you need 128-bit binary floating-point
numbers for your number crunching stuff?  Forget about Java then....  or
does your hardware have 1-complement signed integers?  Java requires
integers to be 2-complement, i.e. you must then have some emulation layer
on top of your native integer format - that's inefficient.

> C and C++ on the other hand, not only allow arbitrary pointer arithmetic,
> but also only define in the standard, the minimum size requirements of each
> data type.

.....which will enable you to use the underlying hardware more efficiently.
Do you want to write a program which runs on a 64-bit machine?, and use
the increased size of the basic data type?  Forget about Java - that language
has a 32-bit architecture more or less hardwired into it.  Just like UCSD
Pascal (which has a concept similar to Java: portable binary code which is
to be interpreted on the target machine) had a 16-bit architecture more or less
hardwired into it.

> It is impossible to write a Java program that's bound to a specific
> machine architecture.

....actually, it's quite easy to do that:  just use some of the common Java
class libraries in your program, then try to run it on some architecture
except the java architecture, i.e. without a JVM ......

> With C/C++ it's easy, and common to do so. In fact, the ability of C/C++
> to do such things is what makes it such a useful language for low level
> programming, virtually replacing the need for assembly language, except
> in cases of utilising the varied coprocessors that adorn modern CPU's.

.....in Java, you must use JNI, and C, to do this.......  :-)

> Ever tried porting some C code to a 64 bit platform?

I've ported some 8-bit and 16-bit C code to 32 bit platforms, so I'm well
acquainted with the problems which then may arise.  Porting from 32-bit
to 64-bit is probably not much different.

> Many C compilers implement int as a 32 bit quantity even on 64 bit
> architectures,

Those C compilers aren't follow ANSI C compliant, I would say.

> which completely hoses an enormous amount of C code, which wrongly assumes
> that int and int * are the same size, simply because for many years on most
> implementations, it was.

Check out:

http://www.doc.ic.ac.uk/lab/secondyear/cstyle/node32.html#SECTION000260000000000000000

in particular point 10, the last point.

C code which assumes a pointer to be of the same size as an int is
broken.  That assumption was invalid already in the 16-bit world,
where an int naturally was 16 bits while a pointer could be 16 or 32
bits, depending on the memory model.  In one and the same program, a
function pointer could even be of a different size than a data
pointer.

> You could point out that this is terrible coding practice, and I'd
> agree with you. It was however one of the most common optimisations you
> could do in C, and was frequently done precisely because of the
> performance advantage it had.

I don't see the performance advantage here.  In what way would it
degrade performance to keep int's separare from pointers?  At least
the people doing this could have typedef'ed int to some name clearly
indicating this int actually held a pointer.


> The first 64 bit platform that GNU/Linux was self hosting on was the
> Alpha (God bless it's soul). This particular portability issue with C
> was the primary reason many good open source programs were not
> available on this architecture.
> 
> Java can, and has, been implemented without the virtual machine. The
> GNU compiler for Java for instance, can generate machine-code 'class'
> files that run on a UNIX platform using the standard dynamic library
> loader mechanisms available there. It can do this from both Java
> source, and Java bytecode. Even if the VM is taken away, the source
> level representation is still portable to any other Java
> implementation.

I know about these implementations -- but how well do these non-JVM
Java compilers run most Java programs originally written for JVM-Java?
They lack a number of classes in the Java class library, don't they?
Java is, by itself, such a small language that you cannot do much
interesting with it without using the Java class libraries.

> Amusingly, there are a few higher level scripting languages out there
> that are actually 'less portable' than java, because they provide
> machine level access facilities that totally destroy the independence
> of code written to use them.

You can do that in Java too -- read up on JNI !!!!!

>> The Java platform doesn't exist in hardware - it must be simulated
>> in software.  "But that means Java is portable: I can run my JVM on
>> several other platforms" -- true, but if you define "portability" in
>> such a way, then all Windows software becomes equally portable: just
>> start your favourite Windows emulator on either your Mac or your Linux
>> machine, and run your Windows software on it....
> 
> I'd be interested to hear a definition of 'portable' that doesn't apply
> to Java, platform or language. I'd be prepared to conceed that perhaps
> Linux could be considered "more portable" as it's a 'platform' that's
> been ported to more architectures than perhaps any other in history.
> The fact remains though, than even with Linux, one must be very
> cautious not to write code in a machine dependant way while using it's
> 'natural' languages.
> 
> The big issue that existed with Microsofts implementation of Java, was
> that they extended the language to permit pointer manipulation and
> direct calls to native code segments, so that you can directly call the
> Win32 API. This enabled them to easily generate Java stubs for the
> entire Win32 API.

You can do that also in Sun's Java - just use JNI and some glue C code....

> This compromises not only the portability of Java
> programs, but also the security model provided by the Java platform,
> which is dependent on programs not being able to access memory that
> belong to the VM, or any other program that's running in the same
> memory space.

How well is that security model maintained in GNU's Java implementation
which runs without any VM and generates native code?

> Ironically, Microsoft made the same design decision with .NET, by
> providing the facility of unmanaged code.

....and Java did it with JNI....

> While this allows you to
> easily leverage existing functionality, it also ties you to it, and is
> undoubtedly the primary reason there was no 64 bit .NET VM for IA64 for
> so long. Is there even one now? I bet Intel people, particularly on the
> 64 bit side of the fence curse Microsoft every night, as without the
> ties that MS has between it's operating system and x86 architecture,
> there'd be a lot more room in the marketplace for a successor to x86,
> rather than just another extension.
> 
> My only real gripe with the Java platform is that it's controlled,
> essentially, by a single company with it's own agenda.

Yep -- Java was about to be standardized some years ago, but then Sun
changed its mind and stopped that.  Even C# now has an (ECMA) standard.

> There's still no
> complete implementation of Java that's independent of Suns, and
> everyone on the supposed JCP ultimately has to play second fiddle to
> Suns iron first. To be though, this is still significantly better than
> being tied to both a proprietary platform, and a machine architecture,
> which is essentially the position that Microsoft developers are now in.

Here you compare two platforms.  I agree with what you say here, however
it does illuminate my point:  Java isn't platform independent, Java is
a platform.  And here you compare the Java platform with the Windows
platform.  That makes sense.  It would not have made sense to compare
the Windows platform with e.g. C or C++, because they are languages,
not platforms.

> For me, the reason UNIX has endured as a platform for so long is that
> it remains the ONLY platform which has a well specified, simple,
> architecture agnostic API, and as a result has been implemented and
> ported many times over. The next most ported platform after UNIX, is
> probably Java, and it'll probably stay that way for quite some time.
> 
> Matt

Now even you call Java a platform....

Btw, UNIX isn't "a platform". UNIX is a collection of several similar
platforms which still are different enough to make some programs
written for e.g. Linux source incompatible with e.g. Free-BSD, HP-UX or AIX.



-- 
----------------------------------------------------------------
Paul Schlyter,  Grev Turegatan 40,  SE-114 38 Stockholm,  SWEDEN
e-mail:  pausch at stockholm dot bostream dot se
WWW:     http://stjarnhimlen.se/
0
pausch
5/26/2006 12:43:23 PM
In article <bruce#fanboy.net-628A67.09374025052006@news.newsreader.com>,
Bruce Tomlin  <bruce#fanboy.net@127.0.0.1> wrote:

> In article <e53i7m$1set$1@merope.saaf.se>,
>  pausch@saaf.se (Paul Schlyter) wrote:
> 
>> The Java platform doesn't exist in hardware - it must be simulated
>> in software.  "But that means Java is portable: I can run my JVM on
> 
> I thought Java bytecodes, or at least a significant portion of them, 
> actually had been implemented in hardware.  But I know for certain that 
> UCSD P-code had been implemented in hardware once at least once in the 
> mid '80s.  I think it was called the "P-Engine", and Jerry Pournelle 
> mentioned it in his column in Byte.
> 
> Likewise, I recall that a significant portion of Smalltalk bytecodes and 
> primitives were implemented in hardware at Xerox, using the Dorado's 
> capability for downloadable microcode.
> 
> So just because someone makes up an instruction set for a virtual 
> machine doesn't mean that it can't (or won't) be implemented in 
> hardware.  There may be a few of the more complicated instructions that 
> have to be trapped out and implemented in terms of the less complicated 
> instructions, but if someone feels a need to do so, it can get 
> implemented in hardware.  (So when is someone going to take up the 
> challenge and implement Zork's instruction set in VHDL?)

Yes, there have been some processors which runs Java bytecode directly.
But they weren't successful.

Western Digital's Pascal Microengine was an attempt to make a CPU which
ran UCSD Pascal P-code directly, as you pointed out.  But that too was
unsuccessful.

Another attempt was Intel's first 32-bit CPU, the iAPX-432.  It
consisted of a few chips, and ran Ada "P-code" directly.  But that too
was unsuccessful.

The reason of the failure of these CPU's was bad performance.  Soon after
Intel released the 80386, it stopped producing the iAPX-432:  the 80386
ran much faster.

-- 
----------------------------------------------------------------
Paul Schlyter,  Grev Turegatan 40,  SE-114 38 Stockholm,  SWEDEN
e-mail:  pausch at stockholm dot bostream dot se
WWW:     http://stjarnhimlen.se/
0
pausch
5/26/2006 12:43:23 PM
In comp.sys.apple2 Paul Schlyter <pausch@saaf.se> wrote:
>> Sorry, this isn't true. The Java language specification is quite
>> deliberately void of any language construct that would bind it, or any
>> program written in it to a specific architecture.
> 
> Java is not unique in this respect - languages like FORTRAN, C, C++,
> Pascal and Ada are also void of any language construct that would bind
> it, or any program written in it, to a specific architecture.  To
> write non-portable programs in these languages you almost always have
> to use implementation specific extensions (with the exception of C and C++,
> where you can use pointes for a lot of architecture dependent stuff -- otoh
> if you read the standards of these languages carefully, the behaviour of
> such programs is described as "undefined").

This is better in, say, C99, which declares the existence of "inttypes.h",
with types like "int32_t" (a signed 32-bit integer).

I've seen FORTRAN code that initialized multiple global arrays, of
varying types, with a single integer "clear memory area to zero" loop.
The author knew exactly how large all of the types were, how they packed,
how they were laid out in memory, what the floating point representation of
"all bits zero" meant, and so on.  Any change to the way the compiler
worked would have broken it.

There's nothing implementation-specific about it; the language clearly
allows it.  No pointers involved.  C/C++ would allow it too.  Java does not.

>> Additionally, the language specification defines EXACTLY the size and
>> precision of each data type.
> 
> ...which will limit Java to architectures having exactly these sizes and
> precisions of their data types.  Do you need 128-bit binary floating-point
> numbers for your number crunching stuff?  Forget about Java then....  or
> does your hardware have 1-complement signed integers?  Java requires
> integers to be 2-complement, i.e. you must then have some emulation layer
> on top of your native integer format - that's inefficient.

Yes.  Java trades portability and safety for efficiency.  That's rather
the point of the exercise.

>> It is impossible to write a Java program that's bound to a specific
>> machine architecture.
> 
> ...actually, it's quite easy to do that:  just use some of the common Java
> class libraries in your program, then try to run it on some architecture
> except the java architecture, i.e. without a JVM ......

With C/C++ the machine architecture and compiler configuration/capabilities
are significant.  With gcc on a 32-bit architecture you are likely to get
the same results on multiple platforms, but the "class libraries" can be
different.  You're usually okay so long as you stick with POSIX.

With Java we're talking about a virtual machine architecture, which is
the same everywhere.  Writing to Java is like knowing that you're always
going to be running on x86 Linux with libc6.

We're getting into a pedantic/semantic argument over what "portability"
means, but I think the rigid definitions of the Java language, VM, and
class libraries make it significantly more likely that you will be able
to write code once and have it run everywhere.  And you don't need to
have an autoconf script to make that happen.

>> Many C compilers implement int as a 32 bit quantity even on 64 bit
>> architectures,
> 
> Those C compilers aren't follow ANSI C compliant, I would say.

Check the spec.

> C code which assumes a pointer to be of the same size as an int is
> broken.  That assumption was invalid already in the 16-bit world,
> where an int naturally was 16 bits while a pointer could be 16 or 32
> bits, depending on the memory model.  In one and the same program, a
> function pointer could even be of a different size than a data
> pointer.

It's not broken -- it runs fine on the architecture for which it was
written -- it just isn't portable.  This is the argument for Java.  If
you believe that code of this nature is actually broken, then you will
be pleased to discover that it is impossible to write broken code of
this type in Java.

> I know about these implementations -- but how well do these non-JVM
> Java compilers run most Java programs originally written for JVM-Java?
> They lack a number of classes in the Java class library, don't they?
> Java is, by itself, such a small language that you cannot do much
> interesting with it without using the Java class libraries.

You actually cannot do anything -- several fundamental types required
by the VM are, in theory, part of the class libraries.  The idea is not
to do without the VM or class libraries, but rather to skip the "JIT"
part of compilation.

>> The big issue that existed with Microsofts implementation of Java, was
>> that they extended the language to permit pointer manipulation and
>> direct calls to native code segments, so that you can directly call the
>> Win32 API. This enabled them to easily generate Java stubs for the
>> entire Win32 API.
> 
> You can do that also in Sun's Java - just use JNI and some glue C code....

It's not quite as dramatic in JNI.  You can get and set types, and do
some fancy things with arrays, but the VM can decide that data should be
copied in and out rather than giving you direct access.  The .NET stuff
is more aware of what the VM is doing, which can make it more efficient
but also ties the C# VM to a specific data model.

>> This compromises not only the portability of Java
>> programs, but also the security model provided by the Java platform,
>> which is dependent on programs not being able to access memory that
>> belong to the VM, or any other program that's running in the same
>> memory space.
> 
> How well is that security model maintained in GNU's Java implementation
> which runs without any VM and generates native code?

Probably as secure as a VM-based implementation, which is itself just a
bunch of native code.

> Here you compare two platforms.  I agree with what you say here, however
> it does illuminate my point:  Java isn't platform independent, Java is
> a platform.  And here you compare the Java platform with the Windows
> platform.  That makes sense.  It would not have made sense to compare
> the Windows platform with e.g. C or C++, because they are languages,
> not platforms.

Getting to the pedantic/semantic part.  When people say "Java is portable",
they assume that you have a Java VM running on your platform of choice.
Programs running inside the Java VM are portable, but whether or not Java
is available on your Apple II is a different issue.

> Btw, UNIX isn't "a platform". UNIX is a collection of several similar
> platforms which still are different enough to make some programs
> written for e.g. Linux source incompatible with e.g. Free-BSD, HP-UX or AIX.

Java is a collection of several similar platforms (Sun's, GNU classpath,
several commercial versions, some open source versions) running similar
goodies, but each has been limited or extended in some way.

If you think of a "POSIX + gcc" platform, it's fairly similar to Java.

-- 
Send mail to fadden@fadden.com (Andy McFadden) - http://www.fadden.com/
CD-Recordable FAQ - http://www.cdrfaq.org/
CiderPress Apple II archive utility for Windows - http://www.faddensoft.com/
Fight Internet Spam - http://spam.abuse.net/spam/ & http://spamcop.net/
0
Andy
5/26/2006 3:28:09 PM
In article <44771e89$0$65426$742ec2ed@news.sonic.net>,
Andy McFadden  <fadden@fadden.com> wrote:

> In comp.sys.apple2 Paul Schlyter <pausch@saaf.se> wrote:
>>> Sorry, this isn't true. The Java language specification is quite
>>> deliberately void of any language construct that would bind it, or any
>>> program written in it to a specific architecture.
>> 
>> Java is not unique in this respect - languages like FORTRAN, C, C++,
>> Pascal and Ada are also void of any language construct that would bind
>> it, or any program written in it, to a specific architecture.  To
>> write non-portable programs in these languages you almost always have
>> to use implementation specific extensions (with the exception of C and C++,
>> where you can use pointes for a lot of architecture dependent stuff -- otoh
>> if you read the standards of these languages carefully, the behaviour of
>> such programs is described as "undefined").
> 
> This is better in, say, C99, which declares the existence of "inttypes.h",
> with types like "int32_t" (a signed 32-bit integer).

Somewhat in the spirit of Ada then, where you declare a numeric variable
as the number of decimal digits it should be able to hold, at a minimum.
 
> I've seen FORTRAN code that initialized multiple global arrays, of
> varying types, with a single integer "clear memory area to zero" loop.
> The author knew exactly how large all of the types were, how they packed,
> how they were laid out in memory, what the floating point representation of
> "all bits zero" meant, and so on.  Any change to the way the compiler
> worked would have broken it.

There are indeed a lot of ugly tricks you can do in FORTRAN.  A lot of
them involve "interesting" uses of EQUIVALENCE ......

> There's nothing implementation-specific about it; the language clearly
> allows it.

Sorry, but such tricks becomes *very* implementation dependent....

When handling strings in FORTRAN-66, you even HAD to resort to these
tricks.  FORTRAN-66 lacked string variables, so strings of characters
had to be stored in arrays of numeric variables.  Now, the number of
characters which could be stored in an INTEGER or a REAL varied
between implementation ... on machines with 8-bit bytes and 32-bit
integers or reals one could store 4 characters in each numeric
variable (or 8 characters in a DOUBLE PRECISION or COMPLEX variable),
while on machines with 6-bit bytes and 60-bit integers and reals, one
could store 10 characters in each numeric variable (or 20 characters
in a DOUBLE PRECISION or COMPLEX variable).

> No pointers involved.  C/C++ would allow it too.

Yep - C has unions....

> Java does not.

Which is curious, since Java prescribes the way numeris variables should
be represented, it would actually work there.

Otoh Java is too restrictive -- it's a real mess to handle unsigned
data in Java, since Java lacks unsigned integer types.


>>> Additionally, the language specification defines EXACTLY the size and
>>> precision of each data type.
>> 
>> ...which will limit Java to architectures having exactly these sizes and
>> precisions of their data types.  Do you need 128-bit binary floating-point
>> numbers for your number crunching stuff?  Forget about Java then....  or
>> does your hardware have 1-complement signed integers?  Java requires
>> integers to be 2-complement, i.e. you must then have some emulation layer
>> on top of your native integer format - that's inefficient.
> 
> Yes.  Java trades portability and safety for efficiency.  That's rather
> the point of the exercise.

Java loses some portability though -- I'm not aware of any JVM targeted
for hardware using 1-complement integer arithmetic, or non-IEEE f.p.
formats.  In this respect, C and C++ will be more portable than Java.

>>> It is impossible to write a Java program that's bound to a specific
>>> machine architecture.
>> 
>> ...actually, it's quite easy to do that:  just use some of the common Java
>> class libraries in your program, then try to run it on some architecture
>> except the java architecture, i.e. without a JVM ......
> 
> With C/C++ the machine architecture and compiler configuration/capabilities
> are significant.  With gcc on a 32-bit architecture you are likely to get
> the same results on multiple platforms, but the "class libraries" can be
> different.  You're usually okay so long as you stick with POSIX.
> 
> With Java we're talking about a virtual machine architecture, which is
> the same everywhere.

.....that's called "single platform"....

> Writing to Java is like knowing that you're always
> going to be running on x86 Linux with libc6.

Yep -- another example of single platform development.  WHatever
platform you're using, you can write your program for that platform only,
ignoring what might happen the day your program is ported to another
platform.

> We're getting into a pedantic/semantic argument over what "portability"
> means, but I think the rigid definitions of the Java language, VM, and
> class libraries make it significantly more likely that you will be able
> to write code once and have it run everywhere.  And you don't need to
> have an autoconf script to make that happen.

No --- Java programs will run only on the Java platform without problems.
And there are even problems between different versions of the JVM: if
you upgrade the JVM to the latest version on your web browser, some older
applets will cease working properly.  For that reason, I still keep an
old Netscape 4.7 web browser available, with its own very old JVM, for
applets which won't run on the latest JVM's.

So the claim that "Java programs run everywhere without problems" is
a myth -- even among different JVM's on the same computer!

>> Many C compilers implement int as a 32 bit quantity even on 64 bit
>>> architectures,
>> 
>> Those C compilers aren't follow ANSI C compliant, I would say.
> 
> Check the spec.

I just did.  ANSI X3.159-1989, paragraph "3.1.2.5 Types", says:

# A "plain" int object has the natural size suggested by the
# architecture of the execution environemt.

So do you think 32 bits really is the natural size suggested by a 64
bit architecture?

>> C code which assumes a pointer to be of the same size as an int is
>> broken.  That assumption was invalid already in the 16-bit world,
>> where an int naturally was 16 bits while a pointer could be 16 or 32
>> bits, depending on the memory model.  In one and the same program, a
>> function pointer could even be of a different size than a data
>> pointer.
> 
> It's not broken -- it runs fine on the architecture for which it was
> written -- it just isn't portable.  This is the argument for Java.  If
> you believe that code of this nature is actually broken, then you will
> be pleased to discover that it is impossible to write broken code of
> this type in Java.

Naturally it's impossible to write code that's broken in this way in
any single-platform language - not just Java.
 
>> I know about these implementations -- but how well do these non-JVM
>> Java compilers run most Java programs originally written for JVM-Java?
>> They lack a number of classes in the Java class library, don't they?
>> Java is, by itself, such a small language that you cannot do much
>> interesting with it without using the Java class libraries.
> 
> You actually cannot do anything -- several fundamental types required
> by the VM are, in theory, part of the class libraries.  The idea is not
> to do without the VM or class libraries, but rather to skip the "JIT"
> part of compilation.
> 
>>> The big issue that existed with Microsofts implementation of Java, was
>>> that they extended the language to permit pointer manipulation and
>>> direct calls to native code segments, so that you can directly call the
>>> Win32 API. This enabled them to easily generate Java stubs for the
>>> entire Win32 API.
>> 
>> You can do that also in Sun's Java - just use JNI and some glue C code....
> 
> It's not quite as dramatic in JNI.  You can get and set types, and do
> some fancy things with arrays, but the VM can decide that data should be
> copied in and out rather than giving you direct access.  The .NET stuff
> is more aware of what the VM is doing, which can make it more efficient
> but also ties the C# VM to a specific data model.

You can reverse engineer a particular JVM, and then use the pointer
given to your C code by JNI, and then do about anything you want inside
the JVM with your C code.  Such a situation would be similar to the
..NET situation, where there is one single .NET-VM, written by Microsoft
to run on Windows.
 
>>> This compromises not only the portability of Java
>>> programs, but also the security model provided by the Java platform,
>>> which is dependent on programs not being able to access memory that
>>> belong to the VM, or any other program that's running in the same
>>> memory space.
>> 
>> How well is that security model maintained in GNU's Java implementation
>> which runs without any VM and generates native code?
> 
> Probably as secure as a VM-based implementation, which is itself just a
> bunch of native code.
> 
>> Here you compare two platforms.  I agree with what you say here, however
>> it does illuminate my point:  Java isn't platform independent, Java is
>> a platform.  And here you compare the Java platform with the Windows
>> platform.  That makes sense.  It would not have made sense to compare
>> the Windows platform with e.g. C or C++, because they are languages,
>> not platforms.
> 
> Getting to the pedantic/semantic part.  When people say "Java is portable",
> they assume that you have a Java VM running on your platform of choice.
> Programs running inside the Java VM are portable, but whether or not Java
> is available on your Apple II is a different issue.

Then I could as well way: "When people say 'Windows apps are all
portable'", they assume that you have a Windows emulator running on
your platform of choice.  Programs running inside the Windows emulator
are portable, but whether or not Windows is available on your Apple II
is a different issue".

In both cases it's the same kind of "portability".

Btw, C programs can be run on an Apple II.  As a matter of fact, my very
first acquaintance with the C language I made on an Apple II, using Leor
Zolman's BDS C compiler.

>> Btw, UNIX isn't "a platform". UNIX is a collection of several similar
>> platforms which still are different enough to make some programs
>> written for e.g. Linux source incompatible with e.g. Free-BSD, HP-UX or AIX.
> 
> Java is a collection of several similar platforms (Sun's, GNU classpath,
> several commercial versions, some open source versions) running similar
> goodies, but each has been limited or extended in some way.
> 
> If you think of a "POSIX + gcc" platform, it's fairly similar to Java.

.....except the security aspects... :-)

You could also say: "if you think MSVC + Windows platform, it's
fairly similar to Java".

-- 
----------------------------------------------------------------
Paul Schlyter,  Grev Turegatan 40,  SE-114 38 Stockholm,  SWEDEN
e-mail:  pausch at stockholm dot bostream dot se
WWW:     http://stjarnhimlen.se/
0
pausch
5/26/2006 6:44:03 PM
I have a ][ plus that I bought in 1990 or so. Obviously used :)
Last night I have noticed that the CPU is not the regular 6502, not even 
a 65C02 but a W65C802 - a 16 bit chip in 6502 pin compatible case.

So the question I have is this: is there any software to take advantage 
of it? I doubt it, 'cause I have never heared of such a mod before.
And while we are at it what software benefits from the extra 
instructions in the 65C02? Apart from the 2c firmware and such.

-Alex.
0
alexf (262)
5/26/2006 9:26:55 PM
65c02 had a few extra instructions...

You could make some loops shorter.

besides that, PRODOS requires 65c02
after a certain version...

Rich

0
aiiadict (1731)
5/26/2006 9:44:35 PM
Alex Freed wrote:
> I have a ][ plus that I bought in 1990 or so. Obviously used :)
> Last night I have noticed that the CPU is not the regular 6502, not even 
> a 65C02 but a W65C802 - a 16 bit chip in 6502 pin compatible case.
> 
> So the question I have is this: is there any software to take advantage 
> of it? I doubt it, 'cause I have never heared of such a mod before.
> And while we are at it what software benefits from the extra 
> instructions in the 65C02? Apart from the 2c firmware and such.

I recall a couple. HyperC has a patch which uses the 16 bit to speed up 
certain functions. I think later Merlin assemblers support this CPU too. 
There may be other assemblers as well. However, software in general 
treat it as a 6502/65c02.

IMHO, this should have been the next upgrade for 8 bit II's.

Cheers,
Mike T.
0
5/26/2006 10:20:53 PM
Alex Freed wrote:
> I have a ][ plus that I bought in 1990 or so. Obviously used :)
> Last night I have noticed that the CPU is not the regular 6502, not even
> a 65C02 but a W65C802 - a 16 bit chip in 6502 pin compatible case.

That is a fairly rare chip. I have one as well (in a IIe clone). I
bought the chip from someone in the USA.

> So the question I have is this: is there any software to take advantage
> of it? I doubt it, 'cause I have never heared of such a mod before.

I used it to allow me to run Merlin 16 on ProDOS 8 before I bought a
IIgs. This is the only software I ever found that could take advantage
of that 16 bit processor in an 8 bit system.

> And while we are at it what software benefits from the extra
> instructions in the 65C02? Apart from the 2c firmware and such.

ProDOS 8 v2.0.x requires the 65C02 or 65802 or 65816.

0
mcs6502 (519)
5/26/2006 11:35:26 PM
In article <e56rj1$7lo$1@merope.saaf.se>,
 pausch@saaf.se (Paul Schlyter) wrote:

> numbers for your number crunching stuff?  Forget about Java then....  or
> does your hardware have 1-complement signed integers?  Java requires
> integers to be 2-complement, i.e. you must then have some emulation layer
> on top of your native integer format - that's inefficient.

Seriously, has anyone used 1's complement arithmetic in the past 10-20 
years or so?  And why?
0
Bruce
5/27/2006 3:19:52 AM
In article <e56rj1$7lo$1@merope.saaf.se>,
 pausch@saaf.se (Paul Schlyter) wrote:

> In article <1148544621.115246.248890@y43g2000cwc.googlegroups.com>,
> mdj <mdj.mdj@gmail.com> wrote:
[...]
> > The key concepts that are missing here are pointers, and more specifically,
> > the ability to perform arbitrary arithmetic on pointer types.
> 
> FORTRAN, Pascal and Ada lacks this too.
[...]

This is certainly false for Ada:

http://www.adapower.com/rm95.php

In particular, the standard package Interfaces.C.Pointers overloads the 
"+" and "-" operators for just this purpose.

http://www.adapower.com/rm95/RM-B-3-2.html

It is arguably false for many widely used flavors of Pascal including 
Object Pascal and Turbo Pascal.

Even Fortran has a non-standard extension for this:

http://gcc.gnu.org/onlinedocs/gfortran/Cray-pointers.html

-- 
John Matthews
jmatthews at wright dot edu
www dot wright dot edu/~john.matthews/
0
John
5/27/2006 3:36:06 AM
Paul Schlyter wrote:

> Java is not unique in this respect - languages like FORTRAN, C, C++,
> Pascal and Ada are also void of any language construct that would bind
> it, or any program written in it, to a specific architecture.  To
> write non-portable programs in these languages you almost always have
> to use implementation specific extensions (with the exception of C and C++,
> where you can use pointes for a lot of architecture dependent stuff -- otoh
> if you read the standards of these languages carefully, the behaviour of
> such programs is described as "undefined").

I'm unfamiliar with FORTRAN, However all the other language you mention
make it possible to make use of the underlying architecture. The only
difference is that Pascal/Ada force you to be specific about your
intentions whereas C/C++ allows this to be done very simply.

> > The key concepts that are missing here are pointers, and more specifically,
> > the ability to perform arbitrary arithmetic on pointer types.
>
> FORTRAN, Pascal and Ada lacks this too.

Both Pascal and Ada allow arbitrary pointer arithmetic, granted not be
explicit language construct in the case of Pascal, but it's still
easily done, and was actually quite routinely done. I used this
facility myself many times on the Apple II when there was no provided
library routine to access a hardware feature.

> > Additionally, the language specification defines EXACTLY the size and
> > precision of each data type.
>
> ...which will limit Java to architectures having exactly these sizes and
> precisions of their data types.  Do you need 128-bit binary floating-point
> numbers for your number crunching stuff?  Forget about Java then....  or
> does your hardware have 1-complement signed integers?  Java requires
> integers to be 2-complement, i.e. you must then have some emulation layer
> on top of your native integer format - that's inefficient.

That correct, but that's the price of portability ;-)

> > C and C++ on the other hand, not only allow arbitrary pointer arithmetic,
> > but also only define in the standard, the minimum size requirements of each
> > data type.

Yes, and this is a cause of portability issues for programs written in
those languages.

> ....which will enable you to use the underlying hardware more efficiently.
> Do you want to write a program which runs on a 64-bit machine?, and use
> the increased size of the basic data type?  Forget about Java - that language
> has a 32-bit architecture more or less hardwired into it.  Just like UCSD
> Pascal (which has a concept similar to Java: portable binary code which is
> to be interpreted on the target machine) had a 16-bit architecture more or less
> hardwired into it.
>
> > It is impossible to write a Java program that's bound to a specific
> > machine architecture.
>
> ...actually, it's quite easy to do that:  just use some of the common Java
> class libraries in your program, then try to run it on some architecture
> except the java architecture, i.e. without a JVM ......

No. You're confusing the issues. Java is comprised of a language, an
API and a virtual machine. The API is written in Java, and is just a
portable as any other Java program.

> > With C/C++ it's easy, and common to do so. In fact, the ability of C/C++
> > to do such things is what makes it such a useful language for low level
> > programming, virtually replacing the need for assembly language, except
> > in cases of utilising the varied coprocessors that adorn modern CPU's.
>
> ....in Java, you must use JNI, and C, to do this.......  :-)

Which is the entire point; non-portable code stays in the non-portable
realm. There is actually plenty of example of code that was rewritten
in Java since it turned out to be more efficient that way, because the
necessary restrictions of JNI due to portability.

> > Ever tried porting some C code to a 64 bit platform?
>
> I've ported some 8-bit and 16-bit C code to 32 bit platforms, so I'm well
> acquainted with the problems which then may arise.  Porting from 32-bit
> to 64-bit is probably not much different.
>
> > Many C compilers implement int as a 32 bit quantity even on 64 bit
> > architectures,
>
> Those C compilers aren't follow ANSI C compliant, I would say.

Sure they are. The ANSI standard requires only that int is at least 16
bit, and signed. Addresses are whatever they are on the host
architecture.

> > which completely hoses an enormous amount of C code, which wrongly assumes
> > that int and int * are the same size, simply because for many years on most
> > implementations, it was.
>
> Check out:
>
> http://www.doc.ic.ac.uk/lab/secondyear/cstyle/node32.html#SECTION000260000000000000000
>
> in particular point 10, the last point.

Yes, but these are guidelines established to discipline C programmers
to write portable code! They are only necessary because the language
itself is not portable; it allows you to write a valid program that is
architecture dependant, and such guidelines are prevalent due to the
fact that people ignorant of them will write non-portable applications
without even realising it.

> > You could point out that this is terrible coding practice, and I'd
> > agree with you. It was however one of the most common optimisations you
> > could do in C, and was frequently done precisely because of the
> > performance advantage it had.
>
> I don't see the performance advantage here.  In what way would it
> degrade performance to keep int's separare from pointers?  At least
> the people doing this could have typedef'ed int to some name clearly
> indicating this int actually held a pointer.

Could have, didn't. That's the point.

> I know about these implementations -- but how well do these non-JVM
> Java compilers run most Java programs originally written for JVM-Java?
> They lack a number of classes in the Java class library, don't they?
> Java is, by itself, such a small language that you cannot do much
> interesting with it without using the Java class libraries.
>
> > Amusingly, there are a few higher level scripting languages out there
> > that are actually 'less portable' than java, because they provide
> > machine level access facilities that totally destroy the independence
> > of code written to use them.
>
> You can do that in Java too -- read up on JNI !!!!!

No, JNI forces architecture dependent code to be written in a language
other than Java and linked to it via very specific portably defined
C/C++ interface. You can't just link in any old thing, you have to wrap
it in the portable interface of JNI on the C/C++ side.

> >> The Java platform doesn't exist in hardware - it must be simulated
> >> in software.  "But that means Java is portable: I can run my JVM on
> >> several other platforms" -- true, but if you define "portability" in
> >> such a way, then all Windows software becomes equally portable: just
> >> start your favourite Windows emulator on either your Mac or your Linux
> >> machine, and run your Windows software on it....
> >
> > I'd be interested to hear a definition of 'portable' that doesn't apply
> > to Java, platform or language. I'd be prepared to conceed that perhaps
> > Linux could be considered "more portable" as it's a 'platform' that's
> > been ported to more architectures than perhaps any other in history.
> > The fact remains though, than even with Linux, one must be very
> > cautious not to write code in a machine dependant way while using it's
> > 'natural' languages.
> >
> > The big issue that existed with Microsofts implementation of Java, was
> > that they extended the language to permit pointer manipulation and
> > direct calls to native code segments, so that you can directly call the
> > Win32 API. This enabled them to easily generate Java stubs for the
> > entire Win32 API.
>
> You can do that also in Sun's Java - just use JNI and some glue C code....

It's not at all the same thing. Linking a code section from a
non-portable language via a portable interface is a radically different
approach than modifying a portable language to include non-portable
features. This is the basis of the Sun/Microsoft dispute.

> > This compromises not only the portability of Java
> > programs, but also the security model provided by the Java platform,
> > which is dependent on programs not being able to access memory that
> > belong to the VM, or any other program that's running in the same
> > memory space.
>
> How well is that security model maintained in GNU's Java implementation
> which runs without any VM and generates native code?

Just as well, of course. The language definition is the same, and it
still prevents you writing code that will access machine dependant
features.

> Yep -- Java was about to be standardized some years ago, but then Sun
> changed its mind and stopped that.  Even C# now has an (ECMA) standard.

Which is to be honest a pointless marketing exercise. The language
definition itself is useless without its API, as 99.9% of useful C#
programs rely on the .NET API, which is in itself not portable - it
relies heavily on Win32 to provide its functionality.

The Java API on the other hand, is mostly written in Java, and utilises
a very small number of host OS facilities, all of which exist on
virtually every platform. In fact, it relies on the portable subset of
other languages to define these facilities.

> Here you compare two platforms.  I agree with what you say here, however
> it does illuminate my point:  Java isn't platform independent, Java is
> a platform.  And here you compare the Java platform with the Windows
> platform.  That makes sense.  It would not have made sense to compare
> the Windows platform with e.g. C or C++, because they are languages,
> not platforms.

This is true. Java is a Language, an API specification, and a VM. The
VM + API constitutes a platform. Comparing the Windows platform to the
Java platform however isn't sensible - the Windows platform is
non-portable, the Java platform is designed to be portable.

> Now even you call Java a platform....

Because it is. A language, and a  platform. When you refer to Java you
have to be specific about whether you mean the Java language, or the
Java platform, generally the terms are used interchangably and it's
discernable from context what someone is referring to.

> Btw, UNIX isn't "a platform". UNIX is a collection of several similar
> platforms which still are different enough to make some programs
> written for e.g. Linux source incompatible with e.g. Free-BSD, HP-UX or AIX.

This is what the POSIX standard is for. Even Microsoft made a token
attempt at providing a POSIX interface to Windows NT. They pulled it in
the end. These days you can get this interface via Cygwin. There's a
large subset of common functionality across all of these systems which
constitute the UNIX platform. Like anything, if you rely on
vendor-specific extensions, you break portability.

I mean really, to create anything that allows sophisticated
applications to run across multiple platforms, you must specify a
'meta-platform' which hides the specifics of each specific platform.
This is exactly what Java does. Without this technique, you're forced
to write lowest common denominator code.

Considering C/C++ in this light would mean sticking with only the ANSI
standards, which wouldn't allow you to leverage any OS facility beyond
basic file I/O

Java certainly has its blemishes, but how else does one write a
sophisticated application, then pick it up, either binary or source,
and drop it on every major OS and architecture ?

Matt

0
mdj
5/27/2006 9:01:25 AM
In article <bruce#fanboy.net-7FEFE6.22195226052006@news.newsreader.com>,
Bruce Tomlin  <bruce#fanboy.net@127.0.0.1> wrote:

> In article <e56rj1$7lo$1@merope.saaf.se>,
>  pausch@saaf.se (Paul Schlyter) wrote:
> 
>> numbers for your number crunching stuff?  Forget about Java then....  or
>> does your hardware have 1-complement signed integers?  Java requires
>> integers to be 2-complement, i.e. you must then have some emulation layer
>> on top of your native integer format - that's inefficient.
> 
> Seriously, has anyone used 1's complement arithmetic in the past 10-20 
> years or so?  And why?

I used a CDC Cyber-720 twenty years ago: it has 60-bit word size,
non-IEEE floating-point format, and one-complement arithmetic - not
only for integer data but for floating-point data as well!  A few
years later that machine was put out of service though.


Btw one could also ask:

"Seriously, has anyone used the Apple II, or some other obsolete 8-bit
micro, in the past 10-20 years?  If so, why?"

....and the surprising (to some) answer is: yes!


There are emulators not just for the Apple II and other past popular
micros.  There are emulators for old mainframes as well - check out:

   https://gna.org/projects/backtolife/

-- 
----------------------------------------------------------------
Paul Schlyter,  Grev Turegatan 40,  SE-114 38 Stockholm,  SWEDEN
e-mail:  pausch at stockholm dot bostream dot se
WWW:     http://stjarnhimlen.se/
0
pausch
5/27/2006 10:12:33 AM
In article <nospam-467DFC.23375126052006@network-065-024-007-027.columbus.rr.com>,

> In article <e56rj1$7lo$1@merope.saaf.se>,
>  pausch@saaf.se (Paul Schlyter) wrote:
> 
>> In article <1148544621.115246.248890@y43g2000cwc.googlegroups.com>,
>> mdj <mdj.mdj@gmail.com> wrote:
> [...]
>>> The key concepts that are missing here are pointers, and more specifically,
>>> the ability to perform arbitrary arithmetic on pointer types.
>> 
>> FORTRAN, Pascal and Ada lacks this too.
> [...]
> 
> This is certainly false for Ada:
> 
> http://www.adapower.com/rm95.php
> 
> In particular, the standard package Interfaces.C.Pointers overloads the 
> "+" and "-" operators for just this purpose.
> 
> http://www.adapower.com/rm95/RM-B-3-2.html

OK, Ada has pointer arithmetic - but is it arbitrary?  Doesn't Ada impose
strict range checking for all its data structures, throwing exceptions
as soon as an attempt of out-of-range access is performed?  I though the
fundamental idea behind Ada was to provide provably secure software, and
then one cannot take pointer arithmetic as lightly as C and C++ both do.

 
> It is arguably false for many widely used flavors of Pascal including 
> Object Pascal and Turbo Pascal.
> 
> Even Fortran has a non-standard extension for this:
> 
> http://gcc.gnu.org/onlinedocs/gfortran/Cray-pointers.html

If we are going to include non-standard extensions of languages too,
then the Java camp should also include both J++ and C# .....

-- 
----------------------------------------------------------------
Paul Schlyter,  Grev Turegatan 40,  SE-114 38 Stockholm,  SWEDEN
e-mail:  pausch at stockholm dot bostream dot se
WWW:     http://stjarnhimlen.se/
0
pausch
5/27/2006 10:12:34 AM
In article <nospam-467DFC.23375126052006@network-065-024-007-027.columbus.rr.com>,

> In article <e56rj1$7lo$1@merope.saaf.se>,
>  pausch@saaf.se (Paul Schlyter) wrote:
> 
>> In article <1148544621.115246.248890@y43g2000cwc.googlegroups.com>,
>> mdj <mdj.mdj@gmail.com> wrote:
> [...]
>>> The key concepts that are missing here are pointers, and more specifically,
>>> the ability to perform arbitrary arithmetic on pointer types.
>> 
>> FORTRAN, Pascal and Ada lacks this too.
> [...]
> 
> This is certainly false for Ada:
> 
> http://www.adapower.com/rm95.php
> 
> In particular, the standard package Interfaces.C.Pointers overloads the 
> "+" and "-" operators for just this purpose.
> 
> http://www.adapower.com/rm95/RM-B-3-2.html

OK, Ada has pointer arithmetic - but is it arbitrary?  Doesn't Ada impose
strict range checking for all its data structures, throwing exceptions
as soon as an attempt of out-of-range access is performed?  I though the
fundamental idea behind Ada was to provide provably secure software, and
then one cannot take pointer arithmetic as lightly as C and C++ both do.

 
> It is arguably false for many widely used flavors of Pascal including 
> Object Pascal and Turbo Pascal.
> 
> Even Fortran has a non-standard extension for this:
> 
> http://gcc.gnu.org/onlinedocs/gfortran/Cray-pointers.html

If we are going to include non-standard extensions of languages too,
then the Java camp should also include both J++ and C# .....

-- 
----------------------------------------------------------------
Paul Schlyter,  Grev Turegatan 40,  SE-114 38 Stockholm,  SWEDEN
e-mail:  pausch at stockholm dot bostream dot se
WWW:     http://stjarnhimlen.se/
0
pausch
5/27/2006 10:12:34 AM
In article <e598co$12ur$1@merope.saaf.se>,
 pausch@saaf.se (Paul Schlyter) wrote:

> In article <bruce#fanboy.net-7FEFE6.22195226052006@news.newsreader.com>,
> Bruce Tomlin  <bruce#fanboy.net@127.0.0.1> wrote:
> 
> > In article <e56rj1$7lo$1@merope.saaf.se>,
> >  pausch@saaf.se (Paul Schlyter) wrote:
> > 
> >> numbers for your number crunching stuff?  Forget about Java then....  or
> >> does your hardware have 1-complement signed integers?  Java requires
> >> integers to be 2-complement, i.e. you must then have some emulation layer
> >> on top of your native integer format - that's inefficient.
> > 
> > Seriously, has anyone used 1's complement arithmetic in the past 10-20 
> > years or so?  And why?
> 
> I used a CDC Cyber-720 twenty years ago: it has 60-bit word size,
> non-IEEE floating-point format, and one-complement arithmetic - not
> only for integer data but for floating-point data as well!  A few
> years later that machine was put out of service though.

Exactly.  Put out of service.  That's why I gave a range, because I know 
how some places can be about their expensive old mainframes and micros.

And you didn't answer my other question of WHY?  What advantage does 1's 
complement math have that would make someone _want_ to use it now?

> Btw one could also ask:
> 
> "Seriously, has anyone used the Apple II, or some other obsolete 8-bit
> micro, in the past 10-20 years?  If so, why?"
> 
> ...and the surprising (to some) answer is: yes!

Apples and oranges.  I'm talking about a way of doing math, and you're 
trying to bring up a specific hardware platform.  Old platforms are 
going to be obsolete, period.  Old math isn't necessarily so.  "That 
calculus stuff is over 200 years old, nobody uses it any more."
0
Bruce
5/27/2006 11:54:07 AM
In article <1148720485.731835.6030@j55g2000cwa.googlegroups.com>,
mdj <mdj.mdj@gmail.com> wrote:

> Paul Schlyter wrote:
>
>> Java is not unique in this respect - languages like FORTRAN, C, C++,
>> Pascal and Ada are also void of any language construct that would bind
>> it, or any program written in it, to a specific architecture.  To
>> write non-portable programs in these languages you almost always have
>> to use implementation specific extensions (with the exception of C and C++,
>> where you can use pointes for a lot of architecture dependent stuff -- otoh
>> if you read the standards of these languages carefully, the behaviour of
>> such programs is described as "undefined").
>
> I'm unfamiliar with FORTRAN, However all the other language you mention
> make it possible to make use of the underlying architecture. The only
> difference is that Pascal/Ada force you to be specific about your
> intentions whereas C/C++ allows this to be done very simply.

In FORTRAN you could access any address available to the program by
declaring an array and then exceed the bounds of the array.  Negative
subscripts usually worked too.  Port I/O wasn't possible in that way
though, there you had to resort to subroutines in e.g. assembly language.

>>> The key concepts that are missing here are pointers, and more specifically,
>>> the ability to perform arbitrary arithmetic on pointer types.
>>
>> FORTRAN, Pascal and Ada lacks this too.
>
> Both Pascal and Ada allow arbitrary pointer arithmetic, granted not be
> explicit language construct in the case of Pascal, but it's still
> easily done, and was actually quite routinely done. I used this
> facility myself many times on the Apple II when there was no provided
> library routine to access a hardware feature.

You still couldn't do port I/O that way.  That didn't matter on the Apple II
of course, since the 6502 didn't have any hardware ports.

>>> Additionally, the language specification defines EXACTLY the size and
>>> precision of each data type.
>>
>> ...which will limit Java to architectures having exactly these sizes and
>> precisions of their data types.  Do you need 128-bit binary floating-point
>> numbers for your number crunching stuff?  Forget about Java then....  or
>> does your hardware have 1-complement signed integers?  Java requires
>> integers to be 2-complement, i.e. you must then have some emulation layer
>> on top of your native integer format - that's inefficient.
>
> That correct, but that's the price of portability ;-)

Not necessarily.  The idea of portability in C is to use the underlying
hardware as efficiently as possible: if the hardware uses 1-bit complement
then that C implementation uses 1-bit complement too .... etc etc.  If
written with portability in mind, C code can then be made to run as efficiently
as possible in very different architectures.

>>> C and C++ on the other hand, not only allow arbitrary pointer arithmetic,
>>> but also only define in the standard, the minimum size requirements of each
>>> data type.
>
> Yes, and this is a cause of portability issues for programs written in
> those languages.

....interesting portability problem:  "...hey, these 128-bit integers are
too big!  We're having problems storing the value 763 in it....."  :-)

>> ....which will enable you to use the underlying hardware more efficiently.
>> Do you want to write a program which runs on a 64-bit machine?, and use
>> the increased size of the basic data type?  Forget about Java - that language
>> has a 32-bit architecture more or less hardwired into it.  Just like UCSD
>> Pascal (which has a concept similar to Java: portable binary code which is
>> to be interpreted on the target machine) had a 16-bit architecture more or less
>> hardwired into it.
>>
>>> It is impossible to write a Java program that's bound to a specific
>>> machine architecture.
>>
>> ...actually, it's quite easy to do that:  just use some of the common Java
>> class libraries in your program, then try to run it on some architecture
>> except the java architecture, i.e. without a JVM ......
>
> No. You're confusing the issues. Java is comprised of a language, an
> API and a virtual machine. The API is written in Java,

The API is just glue code between the Java program and the VM.

> and is just a portable as any other Java program.

If so, then it's just as impossible to write a Windows program that's bound to
a specific machine architecture: just write a Windows emualator for any
target platform you want.

>>> With C/C++ it's easy, and common to do so. In fact, the ability of C/C++
>>> to do such things is what makes it such a useful language for low level
>>> programming, virtually replacing the need for assembly language, except
>>> in cases of utilising the varied coprocessors that adorn modern CPU's.
>>
>> ....in Java, you must use JNI, and C, to do this.......  :-)
>
> Which is the entire point; non-portable code stays in the non-portable
> realm. There is actually plenty of example of code that was rewritten
> in Java since it turned out to be more efficient that way, because the
> necessary restrictions of JNI due to portability.

I suppose that happened when JIT was introduced in Java: code called through
JNI was more efficient than "old Java", without JNI, but less efficient than
Java with JIT.  And the JNI interface is by itself an overhead.

>>> Ever tried porting some C code to a 64 bit platform?
>>
>> I've ported some 8-bit and 16-bit C code to 32 bit platforms, so I'm well
>> acquainted with the problems which then may arise.  Porting from 32-bit
>> to 64-bit is probably not much different.
>>
>>> Many C compilers implement int as a 32 bit quantity even on 64 bit
>>> architectures,
>>
>> Those C compilers aren't follow ANSI C compliant, I would say.
>
> Sure they are. The ANSI standard requires only that int is at least 16
> bit, and signed. Addresses are whatever they are on the host
> architecture.

Sorry, but ANSI C says more than that about the size of an int.
ANSI X3.159-1989, paragraph "3.1.2.5 Types", explicitly says:

# A "plain" int object has the natural size suggested by the
# architecture of the execution environemt.

Now, what do you think the "natural size" on a 64-bit architecture is?
32 bits?   <g>

>>> which completely hoses an enormous amount of C code, which wrongly assumes
>>> that int and int * are the same size, simply because for many years on most
>>> implementations, it was.
>>
>> Check out:
>>
>> http://www.doc.ic.ac.uk/lab/secondyear/cstyle/node32.html#SECTION000260000000000000000
>>
>> in particular point 10, the last point.
>
> Yes, but these are guidelines established to discipline C programmers
> to write portable code! They are only necessary because the language
> itself is not portable; it allows you to write a valid program that is
> architecture dependant, and such guidelines are prevalent due to the
> fact that people ignorant of them will write non-portable applications
> without even realising it.

C follows the idea "Trust the programmer" -- apparently, a lot of programmers
weren't trustworthy.  Therefore "strait-jacket languages" like Pascal and Java
were needed....


>>> You could point out that this is terrible coding practice, and I'd
>>> agree with you. It was however one of the most common optimisations you
>>> could do in C, and was frequently done precisely because of the
>>> performance advantage it had.
>>
>> I don't see the performance advantage here.  In what way would it
>> degrade performance to keep int's separare from pointers?  At least
>> the people doing this could have typedef'ed int to some name clearly
>> indicating this int actually held a pointer.
>
> Could have, didn't. That's the point.

Another victory for strait-jacket languages... :-)

>> I know about these implementations -- but how well do these non-JVM
>> Java compilers run most Java programs originally written for JVM-Java?
>> They lack a number of classes in the Java class library, don't they?
>> Java is, by itself, such a small language that you cannot do much
>> interesting with it without using the Java class libraries.
>>
>>> Amusingly, there are a few higher level scripting languages out there
>>> that are actually 'less portable' than java, because they provide
>>> machine level access facilities that totally destroy the independence
>>> of code written to use them.
>>
>> You can do that in Java too -- read up on JNI !!!!!
>
> No, JNI forces architecture dependent code to be written in a language
> other than Java and linked to it via very specific portably defined
> C/C++ interface. You can't just link in any old thing, you have to wrap
> it in the portable interface of JNI on the C/C++ side.

I know the stuff called through JNI must be written in C (using C++ here
would be messier).  Yet, JNI is a hole in Java which also poses a
danger.

>>> The big issue that existed with Microsofts implementation of Java, was
>>> that they extended the language to permit pointer manipulation and
>>> direct calls to native code segments, so that you can directly call the
>>> Win32 API. This enabled them to easily generate Java stubs for the
>>> entire Win32 API.
>>
>> You can do that also in Sun's Java - just use JNI and some glue C code....
>
> It's not at all the same thing. Linking a code section from a
> non-portable language via a portable interface is a radically different
> approach than modifying a portable language to include non-portable
> features. This is the basis of the Sun/Microsoft dispute.

The method differs, true, but the end result is the same: versatility,
insecurity, and non-portability.


>>> This compromises not only the portability of Java
>>> programs, but also the security model provided by the Java platform,
>>> which is dependent on programs not being able to access memory that
>>> belong to the VM, or any other program that's running in the same
>>> memory space.
>>
>> How well is that security model maintained in GNU's Java implementation
>> which runs without any VM and generates native code?
>
> Just as well, of course. The language definition is the same, and it
> still prevents you writing code that will access machine dependant
> features.
>
>> Yep -- Java was about to be standardized some years ago, but then Sun
>> changed its mind and stopped that.  Even C# now has an (ECMA) standard.
>
> Which is to be honest a pointless marketing exercise. The language
> definition itself is useless without its API, as 99.9% of useful C#
> programs rely on the .NET API, which is in itself not portable - it
> relies heavily on Win32 to provide its functionality.

But Win32 is just as portable as the Java API - there are Win32 emulators
running on other platforms.

> The Java API on the other hand, is mostly written in Java, and utilises
> a very small number of host OS facilities, all of which exist on
> virtually every platform. In fact, it relies on the portable subset of
> other languages to define these facilities.
>
>> Here you compare two platforms.  I agree with what you say here, however
>> it does illuminate my point:  Java isn't platform independent, Java is
>> a platform.  And here you compare the Java platform with the Windows
>> platform.  That makes sense.  It would not have made sense to compare
>> the Windows platform with e.g. C or C++, because they are languages,
>> not platforms.
>
> This is true. Java is a Language, an API specification, and a VM. The
> VM + API constitutes a platform. Comparing the Windows platform to the
> Java platform however isn't sensible - the Windows platform is
> non-portable, the Java platform is designed to be portable.

Then how come there are Windows emulators running on other platforms?

>> Now even you call Java a platform....
>
> Because it is. A language, and a platform. When you refer to Java you
> have to be specific about whether you mean the Java language, or the
> Java platform, generally the terms are used interchangably and it's
> discernable from context what someone is referring to.

When you say just "Java" I think you usually mean both.  Remove the
platform and you can't run your Java program.  Remove the language,
and you'll have to program in bytecode directly, which would be
possible, although awkward.

>> Btw, UNIX isn't "a platform". UNIX is a collection of several similar
>> platforms which still are different enough to make some programs
>> written for e.g. Linux source incompatible with e.g. Free-BSD, HP-UX or AIX.
>
> This is what the POSIX standard is for. Even Microsoft made a token
> attempt at providing a POSIX interface to Windows NT. They pulled it in
> the end. These days you can get this interface via Cygwin. There's a
> large subset of common functionality across all of these systems which
> constitute the UNIX platform.

.....the POSIX platform ... right?

> Like anything, if you rely on vendor-specific extensions, you break
> portability.
>
> I mean really, to create anything that allows sophisticated
> applications to run across multiple platforms, you must specify a
> 'meta-platform' which hides the specifics of each specific platform.
> This is exactly what Java does. Without this technique, you're forced
> to write lowest common denominator code.
>
> Considering C/C++ in this light would mean sticking with only the ANSI
> standards, which wouldn't allow you to leverage any OS facility beyond
> basic file I/O
>
> Java certainly has its blemishes, but how else does one write a
> sophisticated application, then pick it up, either binary or source,
> and drop it on every major OS and architecture ?

UCSD Pascal perhaps?  :-)    Although now obsolete, that system had
precisely the same objective.  But UCSD Pascal was too early -- the slow
hardware of that time made emulating a pseudo-machine unacceptably slow.
And there also was no widespread Internet through which applications
could be distributed.

> Matt

-- 
----------------------------------------------------------------
Paul Schlyter,  Grev Turegatan 40,  SE-114 38 Stockholm,  SWEDEN
e-mail:  pausch at stockholm dot bostream dot se
WWW:     http://stjarnhimlen.se/
0
pausch
5/27/2006 4:12:59 PM
In article <bruce#fanboy.net-53E793.06540727052006@news.newsreader.com>,
Bruce Tomlin  <bruce#fanboy.net@127.0.0.1> wrote:

> In article <e598co$12ur$1@merope.saaf.se>,
>  pausch@saaf.se (Paul Schlyter) wrote:
> 
>> In article <bruce#fanboy.net-7FEFE6.22195226052006@news.newsreader.com>,
>> Bruce Tomlin  <bruce#fanboy.net@127.0.0.1> wrote:
>> 
>>> In article <e56rj1$7lo$1@merope.saaf.se>,
>>>  pausch@saaf.se (Paul Schlyter) wrote:
>>> 
>>>> numbers for your number crunching stuff?  Forget about Java then....  or
>>>> does your hardware have 1-complement signed integers?  Java requires
>>>> integers to be 2-complement, i.e. you must then have some emulation layer
>>>> on top of your native integer format - that's inefficient.
>>> 
>>> Seriously, has anyone used 1's complement arithmetic in the past 10-20 
>>> years or so?  And why?
>> 
>> I used a CDC Cyber-720 twenty years ago: it has 60-bit word size,
>> non-IEEE floating-point format, and one-complement arithmetic - not
>> only for integer data but for floating-point data as well!  A few
>> years later that machine was put out of service though.
> 
> Exactly.  Put out of service.  That's why I gave a range, because I know 
> how some places can be about their expensive old mainframes and micros.
> 
> And you didn't answer my other question of WHY?

Because I was hired to do it..... but then I quit that job and instead became
a consultant in the microcomputer business.  And since then I've never seen
(OK, I've seen it, but not worked with it) hardware with either 1-complement
arithmetic or byte size different from 8 bits.

> What advantage does 1's complement math have that would make someone _want_
> to use it now?

One advantage is that negation is simpler: just flip all bits.  But that's
not reason enough of course.  However, another reason could be that negating
a 1-complement number can never ever cause an overflow.  Negating a
signed-magnitude number cannot cause an overflow either (one flips just
the sign bit).

However, negating a 2-complement number can cause an overflow.  Consider a
16-bit 2-complement integer with the value -32768.  Negating that yields
+32768, however the largest possible 16-bit 2-complement integer is just
+32767.

In C, overflows are silent, so negating the smallest possible negative
value will just yield the value itself.  C++ inherited this property of C,
and so did Java - this Java program compiles even without any warning:
---------------------------------------------
class test
{
    static public void main( String args[] )
    {
        int i = -2147483648, j = -i;
        System.out.println( i + " " + j );
    }
}
---------------------------------------------

and produces this output:

-2147483648 -2147483648

which is clearly erroneous.


This wouldn't happen in 1-complement arithmetic instead there

        int i = -2147483648

would overflow directly (assuming 32-bit arithmetic)


>> Btw one could also ask:
>> 
>> "Seriously, has anyone used the Apple II, or some other obsolete 8-bit
>> micro, in the past 10-20 years?  If so, why?"
>> 
>> ...and the surprising (to some) answer is: yes!
> 
> Apples and oranges.  I'm talking about a way of doing math, and you're 
> trying to bring up a specific hardware platform.  Old platforms are 
> going to be obsolete, period.  Old math isn't necessarily so.  "That 
> calculus stuff is over 200 years old, nobody uses it any more."

Binary number representation isn't mathematics, it's numerics....  :-)

-- 
----------------------------------------------------------------
Paul Schlyter,  Grev Turegatan 40,  SE-114 38 Stockholm,  SWEDEN
e-mail:  pausch at stockholm dot bostream dot se
WWW:     http://stjarnhimlen.se/
0
pausch
5/27/2006 4:12:59 PM
It seems appropriate to point out that, given Turing equivalence of
all computers (with enough storage and time), "portability" is always
assured in principle, though it may require widely varying degrees of
effort.

Practically, "portable" means "easily ported" and "non-portable" means
"difficult to port".

-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."
0
Michael
5/27/2006 7:30:31 PM
John Selck wrote:
> Am 18.05.2006, 16:14 Uhr, schrieb Paul Schlyter <pausch@saaf.se>:
> 
>> Could you point at one single case where use of undocumented opcodes did
>> significantly speed up an application on the 6502 platform?
> 
> 
> Bresenham interpolation.
> 
> Without illegal opcodes:
> 
> STA $12
> TXA
> STA $FE00,Y
> TAX
> LDA $12
> SBC $10
> BCS .skip
> ADC $11
> INX
> ..skip
> 
> With illegal opcodes:
> 
> SHX $FE00,Y
> SBC $10
> BCS .skip
> ADC $11
> INX
> ..skip
> 
> Best case: 21 vs 11 clock cycles (almost 2x speed with illegal)
> Worst case: 25 vs 15 clock cycles (still 1.67x speed)

I note that the TAX in the first case is unnecessary, trimming the
best case advantage to 19 vs 11 cycles (1.7x) and the worst case
advantage to 23 vs 15 cycles (1.5x).

-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."
0
Michael
5/27/2006 7:36:26 PM
222222In article <e598gn$134q$1@merope.saaf.se>,
 pausch@saaf.se (Paul Schlyter) wrote:

> In article 
> <nospam-467DFC.23375126052006@network-065-024-007-027.columbus.rr.com>,
> 
> > In article <e56rj1$7lo$1@merope.saaf.se>,
> >  pausch@saaf.se (Paul Schlyter) wrote:
> > 
> >> In article <1148544621.115246.248890@y43g2000cwc.googlegroups.com>,
> >> mdj <mdj.mdj@gmail.com> wrote:
> > [...]
> >>> The key concepts that are missing here are pointers, and more 
> >>> specifically,
> >>> the ability to perform arbitrary arithmetic on pointer types.
> >> 
> >> FORTRAN, Pascal and Ada lacks this too.
> > [...]
> > 
> > This is certainly false for Ada:
> > 
> > http://www.adapower.com/rm95.php
> > 
> > In particular, the standard package Interfaces.C.Pointers overloads the 
> > "+" and "-" operators for just this purpose.
> > 
> > http://www.adapower.com/rm95/RM-B-3-2.html
> 
> OK, Ada has pointer arithmetic - but is it arbitrary?

Well, it's arbitrary up to the limit of erroneous: you can't access 
memory that's forbidden by the OS:-)

> Doesn't Ada impose strict range checking for all its data structures, 
> throwing exceptions as soon as an attempt of out-of-range access is 
> performed?

Certainly, constraint, overflow and elaboration checks can be turned on 
and off selectively as requirements dictate.

> I though the fundamental idea behind Ada was to provide 
> provably secure software, and then one cannot take pointer arithmetic 
> as lightly as C and C++ both do.

Indeed, the capability is provided more to interface with existing code 
than to represent exemplary style. In the normal course of programming, 
one uses the operations and attributes of the referenced type (e.g. 
array and records) rather than pointer arithmetic. In fact, Ada does 
away with the syntactic distinction between the pointer and the thing 
pointed to (e.g. p and p^, in Pascal). Java takes this even further, 
allowing no access whatever to the underlying object reference as a 
pointer.

> > It is arguably false for many widely used flavors of Pascal including 
> > Object Pascal and Turbo Pascal.
> > 
> > Even Fortran has a non-standard extension for this:
> > 
> > http://gcc.gnu.org/onlinedocs/gfortran/Cray-pointers.html
> 
> If we are going to include non-standard extensions of languages too,
> then the Java camp should also include both J++ and C# .....

Touch´┐Ż! :-)

-- 
John Matthews
jmatthews at wright dot edu
www dot wright dot edu/~john.matthews/
0
John
5/28/2006 6:07:01 AM
In article <Ms2dnbdHwN56NeXZnZ2dneKdnZydnZ2d@comcast.com>,
Michael J. Mahon <mjmahon@aol.com> wrote:

> It seems appropriate to point out that, given Turing equivalence of
> all computers (with enough storage and time), "portability" is always
> assured in principle, though it may require widely varying degrees of
> effort.
> 
> Practically, "portable" means "easily ported" and "non-portable" means
> "difficult to port".

In particular, "portable" doesn't require zero effort.  A program can
be portable even though it requires recompilation on the new platform,
and perhans also a few configuration settings.
 
> -michael
> 
> Parallel computing for 8-bit Apple II's!
> Home page:  http://members.aol.com/MJMahon/

Parallell Apple II's - interesting - but don't you thin one would
get more performance from a modern computer than from a few Apple II's
working in parallell?  :-)

-- 
----------------------------------------------------------------
Paul Schlyter,  Grev Turegatan 40,  SE-114 38 Stockholm,  SWEDEN
e-mail:  pausch at stockholm dot bostream dot se
WWW:     http://stjarnhimlen.se/
0
pausch
5/28/2006 11:42:57 AM
In article <nospam-7B7751.02054028052006@network-065-024-007-028.columbus.rr.com>,

> 222222In article <e598gn$134q$1@merope.saaf.se>,
>  pausch@saaf.se (Paul Schlyter) wrote:
> 
>> In article 
>> <nospam-467DFC.23375126052006@network-065-024-007-027.columbus.rr.com>,
>> 
>>> In article <e56rj1$7lo$1@merope.saaf.se>,
>>>  pausch@saaf.se (Paul Schlyter) wrote:
>>> 
>>>> In article <1148544621.115246.248890@y43g2000cwc.googlegroups.com>,
>>>> mdj <mdj.mdj@gmail.com> wrote:
>>> [...]
>>>>> The key concepts that are missing here are pointers, and more 
>>>>> specifically,
>>>>> the ability to perform arbitrary arithmetic on pointer types.
>>>> 
>>>> FORTRAN, Pascal and Ada lacks this too.
>>> [...]
>>> 
>>> This is certainly false for Ada:
>>> 
>>> http://www.adapower.com/rm95.php
>>> 
>>> In particular, the standard package Interfaces.C.Pointers overloads the 
>>> "+" and "-" operators for just this purpose.
>>> 
>>> http://www.adapower.com/rm95/RM-B-3-2.html
>> 
>> OK, Ada has pointer arithmetic - but is it arbitrary?
> 
> Well, it's arbitrary up to the limit of erroneous:  you can't access
> memory that's forbidden by the OS:-)

Ouch .... so much for the "security" of Ada......

>> Doesn't Ada impose strict range checking for all its data structures, 
>> throwing exceptions as soon as an attempt of out-of-range access is 
>> performed?
> 
> Certainly, constraint, overflow and elaboration checks can be turned on 
> and off selectively as requirements dictate.
> 
>> I though the fundamental idea behind Ada was to provide 
>> provably secure software, and then one cannot take pointer arithmetic 
>> as lightly as C and C++ both do.
> 
> Indeed, the capability is provided more to interface with existing code 
> than to represent exemplary style. In the normal course of programming, 
> one uses the operations and attributes of the referenced type (e.g. 
> array and records) rather than pointer arithmetic. In fact, Ada does 
> away with the syntactic distinction between the pointer and the thing 
> pointed to (e.g. p and p^, in Pascal). Java takes this even further, 
> allowing no access whatever to the underlying object reference as a 
> pointer.

ANSI C did that too, partially, by doing away with the difference between
functions and function pointers.  That's why this C program works:

#include <stdio.h>

int main()
{
    (***************************printf)("Hello, world\n");
    return 0;
}

 
>>> It is arguably false for many widely used flavors of Pascal including 
>>> Object Pascal and Turbo Pascal.
>>> 
>>> Even Fortran has a non-standard extension for this:
>>> 
>>> http://gcc.gnu.org/onlinedocs/gfortran/Cray-pointers.html
>> 
>> If we are going to include non-standard extensions of languages too,
>> then the Java camp should also include both J++ and C# .....
> 
> Touche! :-)

-- 
----------------------------------------------------------------
Paul Schlyter,  Grev Turegatan 40,  SE-114 38 Stockholm,  SWEDEN
e-mail:  pausch at stockholm dot bostream dot se
WWW:     http://stjarnhimlen.se/
0
pausch
5/28/2006 11:42:58 AM
In article <e5c1e4$24tu$1@merope.saaf.se>,
 pausch@saaf.se (Paul Schlyter) wrote:

> In article 
> <nospam-7B7751.02054028052006@network-065-024-007-028.columbus.rr.com>,
> 
> > 222222In article <e598gn$134q$1@merope.saaf.se>,
> >  pausch@saaf.se (Paul Schlyter) wrote:
> > 
> >> In article 
> >> <nospam-467DFC.23375126052006@network-065-024-007-027.columbus.rr.com>,
> >> 
> >>> In article <e56rj1$7lo$1@merope.saaf.se>,
> >>>  pausch@saaf.se (Paul Schlyter) wrote:
> >>> 
> >>>> In article <1148544621.115246.248890@y43g2000cwc.googlegroups.com>,
> >>>> mdj <mdj.mdj@gmail.com> wrote:
> >>> [...]
> >>>>> The key concepts that are missing here are pointers, and more 
> >>>>> specifically,
> >>>>> the ability to perform arbitrary arithmetic on pointer types.
> >>>> 
> >>>> FORTRAN, Pascal and Ada lacks this too.
> >>> [...]
> >>> 
> >>> This is certainly false for Ada:
> >>> 
> >>> http://www.adapower.com/rm95.php
> >>> 
> >>> In particular, the standard package Interfaces.C.Pointers overloads the 
> >>> "+" and "-" operators for just this purpose.
> >>> 
> >>> http://www.adapower.com/rm95/RM-B-3-2.html
> >> 
> >> OK, Ada has pointer arithmetic - but is it arbitrary?
> > 
> > Well, it's arbitrary up to the limit of erroneous:  you can't access
> > memory that's forbidden by the OS:-)
> 
> Ouch .... so much for the "security" of Ada......

I don't see how this follows. One of the goals of Ada is to find more 
errors at compile-time, leaving fewer for run-time. It is certainly 
possible to write an erroneous program in Ada, but one must do so 
explicitly. It's much harder to do by accident.

[...]

-- 
John Matthews
jmatthews at wright dot edu
www dot wright dot edu/~john.matthews/
0
John
5/28/2006 5:51:21 PM
Paul Schlyter wrote:
> In article <Ms2dnbdHwN56NeXZnZ2dneKdnZydnZ2d@comcast.com>,
> Michael J. Mahon <mjmahon@aol.com> wrote:

>>Parallel computing for 8-bit Apple II's!
>>Home page:  http://members.aol.com/MJMahon/
> 
> 
> Parallel Apple II's - interesting - but don't you think one would
> get more performance from a modern computer than from a few Apple II's
> working in parallel?  :-)

Certainly!  In fact, with an 8MHz Zip Chip in my primary //e, I can
generally get a result as fast or faster than eight 1MHz machines.  ;-)

But eight machines do provide 512KB of memory along with the eight
processors, and lots of interesting asynchrony.

Of course, the purpose was to create a platform for experimenting
with parallel processing and message-passing--and to serve as a
torture test of NadNet protocols, which it does admirably.

I'm pretty happy with creating a relatively fast (115 kbits/sec)
peer-to-peer network with just 2KB of software, game ports, and
some wire and two transistors per node.  ;-)

-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."
0
Michael
5/28/2006 7:22:34 PM
Paul Schlyter wrote:

> In FORTRAN you could access any address available to the program by
> declaring an array and then exceed the bounds of the array.  Negative
> subscripts usually worked too.  Port I/O wasn't possible in that way
> though, there you had to resort to subroutines in e.g. assembly language.

Cute. In Pascal it was as simple as declaring a variant record of both
Integer and pointer to Integer types, which easily got you peek and
poke. Note this ony works on architectures where Int and Int^ are the
same size, but in the cases that they aren't you can substitute another
type. It allows you to mimic peek and poke. I used this technique
routinely in Apple Pascal for hardware access when speed wasn't an
issue.

Ada actually provides an ADDRESS type, which is specified by the
standard to be implementation dependant. Every type in the language
provides an address attribute that you can access, assign to variables
of type ADDRESS, etc. This gives you equivalent functionality to C's
(void *), albiet with a greater degree of compile time type safety.

Owing to  the lack of commercial success of Ada, most people tend to
believe that languages that provide strict type systems are necessarily
less 'efficient' than C/C++. This is actually completely untrue.
Strictly speaking, the more information a compiler has about the
constraints of data types, the more optimisations you can perform.
Indeed, the lack of typing in C/C++ makes many optimisations
impossible, as the program appears to be non-deterministic to the
optimiser, when in reality the actual data range used is fixed, and
small enough to qualify for a number of clever optimisations.

Of course, this also means that the search space for possible
optimisations gets larger, so compilers get slower, and take many more
years to mature. C remains the most frequently implemented compiled
language not because of it's efficiency, but because the modest size of
the language makes it easy to implement, and the optimisations that are
possible on C code are well known.

> Not necessarily.  The idea of portability in C is to use the underlying
> hardware as efficiently as possible: if the hardware uses 1-bit complement
> then that C implementation uses 1-bit complement too .... etc etc.  If
> written with portability in mind, C code can then be made to run as efficiently
> as possible in very different architectures.

But Paul, using hardware as efficiently as possible and portability are
obviously mutually exclusive concepts :-)

Implementing Java on an architecture that uses 1's complement doesn't
necessarily cause performance issues either. In fact, the
representation of the number is irrelevant until it's either accessed
using bitwise operations, which can be catered for very simply by the
VM by converting the type back and forward as necessary, or when the
number is serialised. In the serialisation case, the byte order is
specified by the specification to guarantee *portability*.

For the most part, bitwise manipulation in C is done to efficiently
utililise memory, be it passing flags to a function as an int, when
it's really going to be treated as an array of booleans, or to provide
space efficient boolean arrays.

In Java, these techniques are redundant; you have a boolean type. The
JIT subsystem can optimise this however it sees fit.

It's actually becoming apparent that Java code can, and often does,
outperform compiled C/C++. The implementation abstraction means that
the JIT or HotSpot compiler can easily exploit the target architectures
particular quirks. A C/C++ program can only exploit the architecture is
written to exploit, and ones that happen to be very similar. Efficient?
yes. Portable? no.

> ...interesting portability problem:  "...hey, these 128-bit integers are
> too big!  We're having problems storing the value 763 in it....."  :-)

It is a problem, as has been stated before in this thread. And think
about when you're back porting. Perhaps you'd like to use a bunch of C
code on an 8 or 16 bit microcontroller? Chances are a bunch of things
will need to be changed because of unforseen portability issues. Or
perhaps in the name of efficiency you'll use smaller data types in some
areas. Such is the nature of C.

It's far safer, IMHO to consider C an assembly language replacement
than a portable high-level language.

> > No. You're confusing the issues. Java is comprised of a language, an
> > API and a virtual machine. The API is written in Java,
>
> The API is just glue code between the Java program and the VM.

That only applies to the tiny subset of the API that performs I/O! What
about the rest of the API? The vast majority of the API is implemented
in pure Java. It's a hell of a lot more than just glue code to the VM

> > and is just a portable as any other Java program.
>
> If so, then it's just as impossible to write a Windows program that's bound to
> a specific machine architecture: just write a Windows emualator for any
> target platform you want.

History has shown this isn't true. Any effective emulator for Windows
is actually an emulation of the x86 architecture, which can then run
Windows itself.

The only third party attempt at reimplementing Windows that has had any
success at all is the WINE project, and that too is bound to the x86
architecture. It is also, woefully incomplete, despite being started as
a project back when Win16 was the dominant API.

So Windows emulation relies on implementing a Windows compatible
machine emulator.  Not exactly an efficient solution.

Microsoft themselves know this. Why else would they have moved to an
extremely Java like system with .NET ?

> I suppose that happened when JIT was introduced in Java: code called through
> JNI was more efficient than "old Java", without JNI, but less efficient than
> Java with JIT.  And the JNI interface is by itself an overhead.

It became far more pronounced after the introduction of JIT, yes. These
days, it's usually more efficient to implement in Java than use JNI, as
there is obviously performance overhead in the JNI interface due to
it's portability restrictions.

> >>> Ever tried porting some C code to a 64 bit platform?
> >>
> >> I've ported some 8-bit and 16-bit C code to 32 bit platforms, so I'm well
> >> acquainted with the problems which then may arise.  Porting from 32-bit
> >> to 64-bit is probably not much different.
> >>
> >>> Many C compilers implement int as a 32 bit quantity even on 64 bit
> >>> architectures,
> >>
> >> Those C compilers aren't follow ANSI C compliant, I would say.
> >
> > Sure they are. The ANSI standard requires only that int is at least 16
> > bit, and signed. Addresses are whatever they are on the host
> > architecture.
>
> Sorry, but ANSI C says more than that about the size of an int.
> ANSI X3.159-1989, paragraph "3.1.2.5 Types", explicitly says:
>
> # A "plain" int object has the natural size suggested by the
> # architecture of the execution environemt.
>
> Now, what do you think the "natural size" on a 64-bit architecture is?
> 32 bits?   <g>

Actually, yes! Prior to the introduction of 64 bit machines, there was
not one single implementation of C that declared int to be 64 bit. No
existing code relies on it being that big, and it wastes a ridiculous
amount of memory to declare it as such.

Generally speaking, a C implementation will opt for int as 32 bits,
unless the machine architecture (and this does happen) restricts the
alignment of 32 bit quantities in such a way that breaks the C
standards. Some RISC architectures restrict load/store operations to
addresses that are a multiple of its addressing size, which places
severe restrictions on the sizing that can be chosen for C data types.

The proponents of RISC systems back in the 90's severely underestimated
the volume of non-portable C code out in the wild, if you ask me. In
fact, this issue may have been a big contributor to the lack of success
of these systems. The PPC crowd found out very quickly that they needed
to implement most of the hardware hacks the intel guys did, as it just
wasn't possible to implement efficient compilers for their
architectures, at least not in a reasonable amout of time.

Bytecode to machine code translators on the other hand....

> C follows the idea "Trust the programmer" -- apparently, a lot of programmers
> weren't trustworthy.  Therefore "strait-jacket languages" like Pascal and Java
> were needed....

It's not just a matter of trust. And besides, lousy/lazy programmers do
exist, and will continue to.

Comparing Java to Pascal is a little harsh. Pascal was primarily
intended as a teaching language, and it's type system is sufficiently
constrained as to cause a lot of needless limitations on the
programmer. For example, it's almost impossible to write generic code
in Pascal. Java has none of these limitations. It provides an excellent
tradeoff between functionality loss and type safety compared to
languages that predate it.

> Another victory for strait-jacket languages... :-)

Here's a question for you: Besides directly accessing hardware
features, what program is difficult to write in Java, versus C/C++?

> I know the stuff called through JNI must be written in C (using C++ here
> would be messier).  Yet, JNI is a hole in Java which also poses a
> danger.

It's actually possible to implement the VM in such a way that any
danger imposed by JNI cannot compromise the security model, or even
crash the application. Typically this isn't done for performance
reasons, but there are implementations that provide this level of
safety.

> The method differs, true, but the end result is the same: versatility,
> insecurity, and non-portability.

Not true. The end result, as history has shown, is very different. The
Microsoft approach allows a great deal of 'laziness' on the part of
those porting existing code to the new environment, and allows the
number of portability and security issues to multiply just as easily as
they did in the C/C++ world.

> >>> This compromises not only the portability of Java
> >>> programs, but also the security model provided by the Java platform,
> >>> which is dependent on programs not being able to access memory that
> >>> belong to the VM, or any other program that's running in the same
> >>> memory space.
> >>
> >> How well is that security model maintained in GNU's Java implementation
> >> which runs without any VM and generates native code?
> >
> > Just as well, of course. The language definition is the same, and it
> > still prevents you writing code that will access machine dependant
> > features.
> >
> >> Yep -- Java was about to be standardized some years ago, but then Sun
> >> changed its mind and stopped that.  Even C# now has an (ECMA) standard.
> >
> > Which is to be honest a pointless marketing exercise. The language
> > definition itself is useless without its API, as 99.9% of useful C#
> > programs rely on the .NET API, which is in itself not portable - it
> > relies heavily on Win32 to provide its functionality.
>
> But Win32 is just as portable as the Java API - there are Win32 emulators
> running on other platforms.

This is more precisely put as Intel architecture emulators running on
other architectures. The Win32 platform remains tied to x86. Have a
look at Windows 64 bit edition on the IA-64 and see how it handles
backwards compatibility. It's so inefficient that you just do not do
it, you use real x86 boxes instead.

This is going to remain the case with .NET applications as well,
despite their supposed 'portability' due to the way legacy code can be
called. For some time, .NET applications on Win64 had to run via the
Win32 emulator, which is already terribly slow. This applies for any
application that uses the .NET API, since it merely thunks calls
through to Win32.

The Java approach is different. Reimplement the API in Java. Make it as
portable as anything else written in the language. The result? Java is
implemented on every platform it's viable to run it on.

> Then how come there are Windows emulators running on other platforms?

Which ones? See above. Any successful implementation of Windows
emulation is actually an x86 PC emulator running actual Windows.

> When you say just "Java" I think you usually mean both.  Remove the
> platform and you can't run your Java program.  Remove the language,
> and you'll have to program in bytecode directly, which would be
> possible, although awkward.

It's probably more accurate to refer to Java as a "meta-platform" as
even though it provides all the functionality of a "platform" it in
itself (generally) requires a host platform to operate. It's certainly
possible to implement the VM as an operating system itself, but the
goal is not to create new concrete platforms, but to provide a unified
"meta-platform" that other existing platforms can host. Java succeeds
in this goal very well.

> UCSD Pascal perhaps?  :-)    Although now obsolete, that system had
> precisely the same objective.  But UCSD Pascal was too early -- the slow
> hardware of that time made emulating a pseudo-machine unacceptably slow.
> And there also was no widespread Internet through which applications
> could be distributed.

All of those limitations have now gone, and history speaks for itself,
I think.

It's certainly a contentious issue, and theres supporters on either
side of the fence. Academically speaking, there's no such thing as true
portability. As long as there are multiple platforms there will be
applications that aren't portable.

It's pointless though to consider the argument in academic terms, only
in practical terms. Java meets its goals of portability. .NET has yet
to meet those goals, and frankly, I doubt it ever will. Microsoft
simply have no interest in making it easy to run Windows applications
on a non-Microsoft platform. You can argue that their system is
inherently portable, but it remains impractical to port Windows
applications.

I actually find it pretty amusing to watch. Microsoft continually rely
on the installed base to maintain their market, but in binding new
technologies to the installed base, they sacrifice their ability to
take advantage of new architectures. I have a feeling that as time goes
by, this strategy is going to prove very costly, as every other
'platform' out there just doesn't have the same limitations. GNU/Linux
has portability advantages because almost all the source is open. Java
has it because of it's portable meta-platform. Apple have transitioned
almost seamlessly from PPC to x86.

It's like watching a time-bomb count down, if you ask me ;-)

0
mdj
5/29/2006 3:21:25 AM
pausch@saaf.se (Paul Schlyter) writes:

>Parallell Apple II's - interesting - but don't you thin one would
>get more performance from a modern computer than from a few Apple II's
>working in parallell?  :-)

As they say, it's not that the dog walked well, but that the dog ...
;)

Besides, it's a clever idea. :)

--
      Cameron Kaiser * ckaiser@floodgap.com * posting with a Commodore 128
                personal page: http://www.armory.com/%7Espectre/
  ** Computer Workshops: games, productivity software and more for C64/128! **
                  ** http://www.armory.com/%7Espectre/cwi/ **
0
Cameron
5/29/2006 5:23:01 AM
In article <nospam-A1B4BA.13530528052006@network-065-024-007-028.columbus.rr.com>,

> In article <e5c1e4$24tu$1@merope.saaf.se>,
>  pausch@saaf.se (Paul Schlyter) wrote:
> 
>> In article 
>> <nospam-7B7751.02054028052006@network-065-024-007-028.columbus.rr.com>,
>> 
>>> 222222In article <e598gn$134q$1@merope.saaf.se>,
>>>  pausch@saaf.se (Paul Schlyter) wrote:
>>> 
>>>> In article 
>>>> <nospam-467DFC.23375126052006@network-065-024-007-027.columbus.rr.com>,
>>>> 
>>>>> In article <e56rj1$7lo$1@merope.saaf.se>,
>>>>>  pausch@saaf.se (Paul Schlyter) wrote:
>>>>> 
>>>>>> In article <1148544621.115246.248890@y43g2000cwc.googlegroups.com>,
>>>>>> mdj <mdj.mdj@gmail.com> wrote:
>>>>> [...]
>>>>>>> The key concepts that are missing here are pointers, and more 
>>>>>>> specifically,
>>>>>>> the ability to perform arbitrary arithmetic on pointer types.
>>>>>> 
>>>>>> FORTRAN, Pascal and Ada lacks this too.
>>>>> [...]
>>>>> 
>>>>> This is certainly false for Ada:
>>>>> 
>>>>> http://www.adapower.com/rm95.php
>>>>> 
>>>>> In particular, the standard package Interfaces.C.Pointers overloads the 
>>>>> "+" and "-" operators for just this purpose.
>>>>> 
>>>>> http://www.adapower.com/rm95/RM-B-3-2.html
>>>> 
>>>> OK, Ada has pointer arithmetic - but is it arbitrary?
>>> 
>>> Well, it's arbitrary up to the limit of erroneous:  you can't access
>>> memory that's forbidden by the OS:-)
>> 
>> Ouch .... so much for the "security" of Ada......
> 
> I don't see how this follows. One of the goals of Ada is to find more 
> errors at compile-time, leaving fewer for run-time. It is certainly 
> possible to write an erroneous program in Ada, but one must do so 
> explicitly. It's much harder to do by accident.

It's easy to exceed the bounds of an array by accident and overwrite other
data structures in the program with garbage.  Apparently it's no more difficult
in Ada than in FORTRAN or C ......

-- 
----------------------------------------------------------------
Paul Schlyter,  Grev Turegatan 40,  SE-114 38 Stockholm,  SWEDEN
e-mail:  pausch at stockholm dot bostream dot se
WWW:     http://stjarnhimlen.se/
0
pausch
5/29/2006 6:43:18 AM
In article <d5mdnWXfs_XjZeTZRVn-tg@comcast.com>,
Michael J. Mahon <mjmahon@aol.com> wrote:

> Paul Schlyter wrote:
>> In article <Ms2dnbdHwN56NeXZnZ2dneKdnZydnZ2d@comcast.com>,
>> Michael J. Mahon <mjmahon@aol.com> wrote:
> 
>>>Parallel computing for 8-bit Apple II's!
>>>Home page:  http://members.aol.com/MJMahon/
>> 
>> 
>> Parallel Apple II's - interesting - but don't you think one would
>> get more performance from a modern computer than from a few Apple II's
>> working in parallel?  :-)
> 
> Certainly!  In fact, with an 8MHz Zip Chip in my primary //e, I can
> generally get a result as fast or faster than eight 1MHz machines.  ;-)
> 
> But eight machines do provide 512KB of memory along with the eight
> processors, and lots of interesting asynchrony.
> 
> Of course, the purpose was to create a platform for experimenting
> with parallel processing and message-passing--and to serve as a
> torture test of NadNet protocols, which it does admirably.
> 
> I'm pretty happy with creating a relatively fast (115 kbits/sec)
> peer-to-peer network with just 2KB of software, game ports, and
> some wire and two transistors per node.  ;-)
> 
> -michael
> 
> Parallel computing for 8-bit Apple II's!
> Home page:  http://members.aol.com/MJMahon/

It sounds fun.....

-- 
----------------------------------------------------------------
Paul Schlyter,  Grev Turegatan 40,  SE-114 38 Stockholm,  SWEDEN
e-mail:  pausch at stockholm dot bostream dot se
WWW:     http://stjarnhimlen.se/
0
pausch
5/29/2006 6:43:18 AM
John B. Matthews wrote:

> It is arguably false for many widely used flavors of Pascal including
> Object Pascal and Turbo Pascal.

It's completely false, even for "standard" versions of Pascal: The
language provides for pointer types and variant records (unions) so
it's easy to write a valid program that stores both a numeric type
(typically Integer) and a pointer in the same memory location.

Once you have that, you can break all the rules you like, and be a
perfectly valid Pascal program :-)

Matt

0
mdj
5/29/2006 6:46:37 AM
Paul Schlyter wrote:

> It's easy to exceed the bounds of an array by accident and overwrite other
> data structures in the program with garbage.  Apparently it's no more difficult
> in Ada than in FORTRAN or C ......

Ada provides bounds checking on array indices, and in addition provides
an "in" construct which can be used to iterate over an array without
specifying the number of iterations in the loop construct as you
typically would in C

To fall over the edge of an array in Ada, you'd need to do this quite
deliberately. It would require determining the address of either the
first or last element, and deliberately modifying the pointer to
overstep the array bounds.

In short, this never happens "by accident" in Ada, it must happen by
design. This pretty much means that in practice, it never happens.

Matt

0
mdj
5/29/2006 8:07:53 AM
In article <1148890072.982487.177830@j33g2000cwa.googlegroups.com>,
mdj <mdj.mdj@gmail.com> wrote:
>Paul Schlyter wrote:
>
>> It's easy to exceed the bounds of an array by accident and overwrite other
>> data structures in the program with garbage.  Apparently it's no more difficult
>> in Ada than in FORTRAN or C ......
>
>Ada provides bounds checking on array indices, and in addition provides
>an "in" construct which can be used to iterate over an array without
>specifying the number of iterations in the loop construct as you
>typically would in C
>
>To fall over the edge of an array in Ada, you'd need to do this quite
>deliberately. It would require determining the address of either the
>first or last element, and deliberately modifying the pointer to
>overstep the array bounds.
>
>In short, this never happens "by accident" in Ada, it must happen by
>design. This pretty much means that in practice, it never happens.
>
>Matt

So this bounds checking can not be turned off in Ada, for efficiency ?




-- 
----------------------------------------------------------------
Paul Schlyter,  Grev Turegatan 40,  SE-114 38 Stockholm,  SWEDEN
e-mail:  pausch at stockholm dot bostream dot se
WWW:     http://stjarnhimlen.se/
0
pausch
5/29/2006 10:12:39 AM
Paul Schlyter wrote:

> So this bounds checking can not be turned off in Ada, for efficiency ?

It's compiler dependent - but the Ada compilers I've used allow pretty
much all runtime checking to be disabled. This is reasonable - after a
degree of testing I guess... I've personally never written anything in
Ada that ran slowly enough to bother with it.

Matt

0
mdj
5/30/2006 1:18:24 AM
mdj wrote:
> Paul Schlyter wrote:
> 
> 
>>So this bounds checking can not be turned off in Ada, for efficiency ?
> 
> 
> It's compiler dependent - but the Ada compilers I've used allow pretty
> much all runtime checking to be disabled. This is reasonable - after a
> degree of testing I guess... I've personally never written anything in
> Ada that ran slowly enough to bother with it.

Turning off error/assertion checking after development and test and
before distributing software for use is like wearing life vests during
training, but taking them off before going to sea (to paraphrase
Dijkstra).

-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."
0
Michael
5/30/2006 10:52:26 PM
Cameron Kaiser wrote:
> pausch@saaf.se (Paul Schlyter) writes:
> 
> 
>>Parallell Apple II's - interesting - but don't you thin one would
>>get more performance from a modern computer than from a few Apple II's
>>working in parallell?  :-)
> 
> 
> As they say, it's not that the dog walked well, but that the dog ...
> ;)
> 
> Besides, it's a clever idea. :)

Thanks, Cameron.

And it is *really* a parallel system, meaning that almost any issue
that can come up on any other parallel system also manifests itself
with an AppleCrate or NadaNet setup.  Synchronization, queuing, race
conditions--it's all there for experimentation!

-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."
0
Michael
5/31/2006 12:27:58 AM
Michael J. Mahon wrote:
> mdj wrote:
> > Paul Schlyter wrote:
> >
> >
> >>So this bounds checking can not be turned off in Ada, for efficiency ?
> >
> >
> > It's compiler dependent - but the Ada compilers I've used allow pretty
> > much all runtime checking to be disabled. This is reasonable - after a
> > degree of testing I guess... I've personally never written anything in
> > Ada that ran slowly enough to bother with it.
>
> Turning off error/assertion checking after development and test and
> before distributing software for use is like wearing life vests during
> training, but taking them off before going to sea (to paraphrase
> Dijkstra).

Absolutely... Unless you really need the extra few cycles of speed it's
more sensible to leave it on. Some people though, would prefer that
their customer see an application crash than show a helpful error
message indicating that a programmer attempted to divide something by
zero ;-)

Even in this case, you could just compile it out per module as
required.

I've never understood why after all these years and all the fancy stuff
that's implemented in a CPU why they never grew the fairly obvious
feature of throwing an interrupt on overflow. It would mean such errors
could be trapped with zero overhead in the no error case.

0
mdj
5/31/2006 1:02:45 AM
mdj wrote:
> Paul Schlyter wrote:

<snip>

>>If so, then it's just as impossible to write a Windows program that's bound to
>>a specific machine architecture: just write a Windows emualator for any
>>target platform you want.
> 
> 
> History has shown this isn't true. Any effective emulator for Windows
> is actually an emulation of the x86 architecture, which can then run
> Windows itself.
> 
> The only third party attempt at reimplementing Windows that has had any
> success at all is the WINE project, and that too is bound to the x86
> architecture. It is also, woefully incomplete, despite being started as
> a project back when Win16 was the dominant API.
> 
> So Windows emulation relies on implementing a Windows compatible
> machine emulator.  Not exactly an efficient solution.
> 
> Microsoft themselves know this. Why else would they have moved to an
> extremely Java like system with .NET ?

Actually, there are (were, in the case of Alpha?) native Windows NT
ports to both Alpha and IA-64.  Neither of these machines was used
"like an x86"--they are good, high performance ports.

<snip>

>>But Win32 is just as portable as the Java API - there are Win32 emulators
>>running on other platforms.
>  
> This is more precisely put as Intel architecture emulators running on
> other architectures. The Win32 platform remains tied to x86. Have a
> look at Windows 64 bit edition on the IA-64 and see how it handles
> backwards compatibility. It's so inefficient that you just do not do
> it, you use real x86 boxes instead.

If anything, this is an argument against your case.

The IA-64 architecture contains a hardware x86 emulator that is a
performance disaster (relative to object code compilation).  Any
use of this emulator is bound to be a performance problem.

The fact that x86 compatibility performs poorly is an argument for
how different IA-64, and the IA-64 Windows port, is from the native
x86 version.

Native IA-64 code flies on Windows for IA-64.

> This is going to remain the case with .NET applications as well,
> despite their supposed 'portability' due to the way legacy code can be
> called. For some time, .NET applications on Win64 had to run via the
> Win32 emulator, which is already terribly slow. This applies for any
> application that uses the .NET API, since it merely thunks calls
> through to Win32.

That's just a matter of prioritizing which parts of the system get
ported sooner and which later.  Understandably, Microsoft designers
decided that Java code was not performance critical.  ;-)

> The Java approach is different. Reimplement the API in Java. Make it as
> portable as anything else written in the language. The result? Java is
> implemented on every platform it's viable to run it on.
> 
> 
>>Then how come there are Windows emulators running on other platforms?
> 
> 
> Which ones? See above. Any successful implementation of Windows
> emulation is actually an x86 PC emulator running actual Windows.

The ones I mentioned--see above.  ;-)

I assure you that the Alpha port and the IA-64 port of Windows are
*not* written to x86 standards and limitations.

I note, however, that in any "portable" program, tradeoffs are made
that affect native performance on any *particular* machine.

I think you underestimate how effective the lower levels of NT are,
particularly the HAL, at insulating higher levels of the OS from
peculiarities of the metal.

Modern OSs--and NT is one of the most modern--have adopted techniques
for achieving relative portability with only modest effects on native
performance.

<snip>

> It's certainly a contentious issue, and theres supporters on either
> side of the fence. Academically speaking, there's no such thing as true
> portability. As long as there are multiple platforms there will be
> applications that aren't portable.

And the number of economically important "different" platforms is
decreasing to a very small number, largely as a result of market
forces triggered by a huge object code base (which the market thinks
of as non-portable).

Some would call it a vicious cycle, some a virtuous cycle, which
eliminates all but one contender for the binary interface.  But there
is no disputing events.

Practically speaking, most portability problems are a result of either
resource constraints or data representation differences.

Moore's "Law" has all but vanquished resource limitations for all but
the most demanding (and therefore niche) applications.

And, perhaps because of designers' clarity, or perhaps because of their
laziness, we have settled almost universally on a set of data repre-
sentations that are common across architectures:  IEEE floating point,
twos-complement integers in power-of-two byte sizes, and 8-bit ASCII.
Big alphabets are still a (national) problem, and pointers are still
often confused with other data types, but, by and large, the data
wars are over.  Even the completely arbitrary endianness problem is
all but vanquished, with big endian machines switch-hitting and little
endian machines enjoying their popularity.

In this day and age, you really have to be creative (or malevolent)
to come up with a legitimate portability barrier.  ;-)

> It's pointless though to consider the argument in academic terms, only
> in practical terms. Java meets its goals of portability. .NET has yet
> to meet those goals, and frankly, I doubt it ever will. Microsoft
> simply have no interest in making it easy to run Windows applications
> on a non-Microsoft platform. You can argue that their system is
> inherently portable, but it remains impractical to port Windows
> applications.

Your last point is perhaps the most significant--the clear motivation
to *obstruct* portability "away" from your platform.  This is the issue
that perenially prevents any real Unix standard.  Only the losers in
the marketshare game *really* want portability--winners never do.  ;-)

(Come to think of it, maybe Linux can eventually "mop up" in the market
and then we'll have a *real* _de facto_ Unix standard.  ;-)

-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."
0
Michael
5/31/2006 1:07:57 AM
On Tue, 30 May 2006, Michael J. Mahon wrote:

> (Come to think of it, maybe Linux can eventually "mop up" in the market
> and then we'll have a *real* _de facto_ Unix standard.  ;-)

Except POSIX/SUS3 is the "de jure" Unix standard.  Though I'd love to see 
a decent *x that fully conforms and is free (no, Solaris doesn't cut the 
mustard).

-uso.
0
Lyrical
5/31/2006 2:40:39 AM
Michael J. Mahon wrote:

> Actually, there are (were, in the case of Alpha?) native Windows NT
> ports to both Alpha and IA-64.  Neither of these machines was used
> "like an x86"--they are good, high performance ports.

While this is essentially true, neither platform was successful in
running the existing codebase, as both the x86 hardware emulator in
IA-64 and the DigitalFX32! software emulator had severe performance
limitations.

Of course, there's no reason the Win32 API can't be redefined as it's
moved to other architectures, but history has shown that doing this
with Win32 didn't produce good results. Vendors didn't exactly line up
to port applications to run natively on Alpha, and aren't doing so now
on IA64.

About the only valid reason I've seen for using Windows on IA64 is to
allow access to SQL Server in 64 bit mode. It tooks years after the
availability of Windows 64 bit edition for SQL Server 64 to be
released, and even now isn't very widely deployed, which is odd as the
benefits are enormous. I guess people are wary of IA64

> > This is more precisely put as Intel architecture emulators running on
> > other architectures. The Win32 platform remains tied to x86. Have a
> > look at Windows 64 bit edition on the IA-64 and see how it handles
> > backwards compatibility. It's so inefficient that you just do not do
> > it, you use real x86 boxes instead.
>
> If anything, this is an argument against your case.

How so? I agree that the operating system itelf can be moved to other
architectures, but the portability limitation still applies to the body
of software the OS depends on to provide the platform. I think you'll
find that the API the way it's defined means that it becomes quite
closely tied to whatever architecture it's ported to.

I think it's reasonable to include success in the measurements. As it
stands, there has been no successful attempts to move Windows to
another architecture. The only one that looks like it will succeed is
x86-64. The reasons for this should be obvious.

Even this port, a relatively straightforward one, took a long time to
emerge. Takes even longer for the device drivers to appear, and even
then, it's successful primarily because it can efficiently execute x86
code in a 64 bit environment.

> The IA-64 architecture contains a hardware x86 emulator that is a
> performance disaster (relative to object code compilation).  Any
> use of this emulator is bound to be a performance problem.

It's terrible yes. Probably not much worse than DEC's software emulator
was though. These days, you could probably do a better job in software,
but who's doing it? Surely Intel have a vested interested in making
this a reality, but they've failed to achieve it.

> The fact that x86 compatibility performs poorly is an argument for
> how different IA-64, and the IA-64 Windows port, is from the native
> x86 version.

Indeed. I think that fact that the IA64 port is different from the
'native' x86 version is my point. It should be as easy as recompiling
applications. It's far, far, from that easy.

> Native IA-64 code flies on Windows for IA-64.

Sure it does, although I doubt it runs any faster than native x86 code
on x86, and probably slower, unless you have a use case where more than
4GB of memory can be used by a single application, which at the moment
is basically limited to databases. This is beside the point though.

> > This is going to remain the case with .NET applications as well,
> > despite their supposed 'portability' due to the way legacy code can be
> > called. For some time, .NET applications on Win64 had to run via the
> > Win32 emulator, which is already terribly slow. This applies for any
> > application that uses the .NET API, since it merely thunks calls
> > through to Win32.
>
> That's just a matter of prioritizing which parts of the system get
> ported sooner and which later.  Understandably, Microsoft designers
> decided that Java code was not performance critical.  ;-)

You seem to need to use the term 'port' a lot. This is precisely my
point about Windows being tied to x86. The platform is significantly
large enough to require prioritisation, which means lots of existing
things won't work, won't even recompile on the new 'port'.

> > Which ones? See above. Any successful implementation of Windows
> > emulation is actually an x86 PC emulator running actual Windows.
>
> The ones I mentioned--see above.  ;-)

> I assure you that the Alpha port and the IA-64 port of Windows are
> *not* written to x86 standards and limitations.

I agree, but those ports are written to Alpha and IA64 limitations
instead. Not that it's necessarily a very bad thing, but in the current
environment, it seems to be.

> I note, however, that in any "portable" program, tradeoffs are made
> that affect native performance on any *particular* machine.
>
> I think you underestimate how effective the lower levels of NT are,
> particularly the HAL, at insulating higher levels of the OS from
> peculiarities of the metal.

In theory, yes. Practice on the other hand...

> Modern OSs--and NT is one of the most modern--have adopted techniques
> for achieving relative portability with only modest effects on native
> performance.

A *lot* of modifications have been made to NT since it was released. I
agree the original version was actually reasonably portable. Over time
though, many compromises have been made to the original abstraction
models, most of them in the name of efficiency. Of course, the
increased efficiency comes at a cost of greater coupling to the
hardware architecture, from the perspective of applications that
utilise it. As the underly architecture has evolved, enhancing NT to
take advantage of it has taken a market driven approach rather than
engineering centric to the detriment of the platform from a portability
perspective.

> > It's certainly a contentious issue, and theres supporters on either
> > side of the fence. Academically speaking, there's no such thing as true
> > portability. As long as there are multiple platforms there will be
> > applications that aren't portable.
>
> And the number of economically important "different" platforms is
> decreasing to a very small number, largely as a result of market
> forces triggered by a huge object code base (which the market thinks
> of as non-portable).
>
> Some would call it a vicious cycle, some a virtuous cycle, which
> eliminates all but one contender for the binary interface.  But there
> is no disputing events.
>
> Practically speaking, most portability problems are a result of either
> resource constraints or data representation differences.

I agree. Data representation differences are at the core of portability
issues, particularly for C/C++ applications which represent the largest
body of software out there.

> Moore's "Law" has all but vanquished resource limitations for all but
> the most demanding (and therefore niche) applications.

Also true.

> And, perhaps because of designers' clarity, or perhaps because of their
> laziness, we have settled almost universally on a set of data repre-
> sentations that are common across architectures:  IEEE floating point,
> twos-complement integers in power-of-two byte sizes, and 8-bit ASCII.
> Big alphabets are still a (national) problem, and pointers are still
> often confused with other data types, but, by and large, the data
> wars are over.  Even the completely arbitrary endianness problem is
> all but vanquished, with big endian machines switch-hitting and little
> endian machines enjoying their popularity.
>
> In this day and age, you really have to be creative (or malevolent)
> to come up with a legitimate portability barrier.  ;-)

Not really. Write a large desktop application for the proprietary API
of any platform, be it MacOS, Windows, and you've got yourself a pretty
thick portability barrier.

If you write your application in a portable language/platform such as
Java (which is really the only successful one) you eliminate this
problem.

Many people adopt an economic approach and declare the markets
available within the Macintosh and UNIX communities to be too small to
be worth worrying about. This is certainly a valid business decision on
the desktop, but certainly is not in the server room, which is where
alternative platforms are enjoying their biggest resurgence. Ironically
this is being fueled primarily because of environmental issues: server
rooms aren't big enough to host the number of boxes needed when using
Windows server based products. Most server solutions *demand* from a
support perspective that they have the box all to themselves, so you
can maintain the patch levels that have been tested for that
application.

> > It's pointless though to consider the argument in academic terms, only
> > in practical terms. Java meets its goals of portability. .NET has yet
> > to meet those goals, and frankly, I doubt it ever will. Microsoft
> > simply have no interest in making it easy to run Windows applications
> > on a non-Microsoft platform. You can argue that their system is
> > inherently portable, but it remains impractical to port Windows
> > applications.
>
> Your last point is perhaps the most significant--the clear motivation
> to *obstruct* portability "away" from your platform.  This is the issue
> that perenially prevents any real Unix standard.  Only the losers in
> the marketshare game *really* want portability--winners never do.  ;-)

It prevents any real standard, period, Unix or Windows. Of course, it
will never become a problem for Microsoft while the x86 architecture is
one of the price/performance leaders, which it will no doubt continue
to be. However, good old Moore's Law means we're embedding OS's all
over the shop, creating numerous new market opportunities. The lack of
portability in the Windows world becomes an achilles heel for vendors
using that platform, and they lose that market to competitors. While I
have no issue with 'winners' owning markets in theory, the real world
limitations this exposes are very detrimental. Don't agree? Check the
release date for Internet Explorer 6.0, check its conformance to w3c
standards, etc.

It's certainly true that Microsoft will maintain the obstruction, and
will maintain the obstruction of .NET becoming a portable platform.

This is in essence my argument, and really, all technical issues aside,
Microsoft don't want portable Windows applications. I find it
frustrating that people argue "oh, it's just as portable, in theory"
when in this the difference between theory and practice is a LOT bigger
in practice than it is in theory. Anyone who attempts to bypass these
portability constraints will most likely be sued or bought out of
existence, so it just will not happen.

Why people continue to put up with this I just don't understand. I
guess they just don't care. Personally, I'd love to have many of the
innovations that would have occured in a more balanced playing field,
but then when faced with the choices of more market control verses a
technically clean solution, I opt for technically clean every time,
perhaps to my own financial detriment.

> (Come to think of it, maybe Linux can eventually "mop up" in the market
> and then we'll have a *real* _de facto_ Unix standard.  ;-)

This has been happening for years, and is really only a few steps away
from being complete. Sun is the only vendor left who is really pushing
their version of UNIX in favour of Linux, everyone else has decided to
fold their own unique advantages back into the Linux kernel. At this
point it becomes the big bad guy Linux versus the other Open Source
alternatives ;-)

For the moment at least, Solaris provides several important technical
advantages that Linux doesn't have, so it'll be around for a while yet.
Personally though, I wish Sun would just 'give up' so that the _de
facto_ standard can truly emerge.

Once that happens, there'll be an open, owned by nobody platform that
runs on every hardware architecture in existence. Certainly there are
interesting times ahead.

Matt

0
mdj
5/31/2006 5:46:36 AM
You can try this EnergyKey
http://www30.webSamba.com/SmartStudio
This may be help you.
Now I always use EnergyKey, it helps me so much in my work.

0
jack2004fb
5/31/2006 6:21:14 AM
mdj wrote:
> Michael J. Mahon wrote:
> 
>>mdj wrote:
>>
>>>Paul Schlyter wrote:
>>>
>>>
>>>
>>>>So this bounds checking can not be turned off in Ada, for efficiency ?
>>>
>>>
>>>It's compiler dependent - but the Ada compilers I've used allow pretty
>>>much all runtime checking to be disabled. This is reasonable - after a
>>>degree of testing I guess... I've personally never written anything in
>>>Ada that ran slowly enough to bother with it.
>>
>>Turning off error/assertion checking after development and test and
>>before distributing software for use is like wearing life vests during
>>training, but taking them off before going to sea (to paraphrase
>>Dijkstra).
> 
> 
> Absolutely... Unless you really need the extra few cycles of speed it's
> more sensible to leave it on. Some people though, would prefer that
> their customer see an application crash than show a helpful error
> message indicating that a programmer attempted to divide something by
> zero ;-)
> 
> Even in this case, you could just compile it out per module as
> required.
> 
> I've never understood why after all these years and all the fancy stuff
> that's implemented in a CPU why they never grew the fairly obvious
> feature of throwing an interrupt on overflow. It would mean such errors
> could be trapped with zero overhead in the no error case.

A number of machines implemented "sticky" overflow, in which the
overflow indicator, if set, would stay set until reset.  This allows
a single test at the end of each procedure, for example, but also
loses the precise point of the interrupt.

One problem with your proposal for an overflow interrupt is that in
many quite ordinary computations, an overflow normally occurs.  This
would require either enabling and disabling the interrupt with some
frequency or defining special forms of arithmetic ops that ignore
any interrupt.

-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."
0
Michael
5/31/2006 6:28:49 AM
Lyrical Nanoha wrote:
> On Tue, 30 May 2006, Michael J. Mahon wrote:
> 
>> (Come to think of it, maybe Linux can eventually "mop up" in the market
>> and then we'll have a *real* _de facto_ Unix standard.  ;-)
> 
> 
> Except POSIX/SUS3 is the "de jure" Unix standard.  Though I'd love to 
> see a decent *x that fully conforms and is free (no, Solaris doesn't cut 
> the mustard).

Yes, but what could be agreed on in Posix always left out some of
the best stuff...

-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."
0
Michael
5/31/2006 6:31:02 AM
In article <1148872885.123157.309890@u72g2000cwu.googlegroups.com>,
mdj <mdj.mdj@gmail.com> wrote:

> Paul Schlyter wrote:
> 
>> In FORTRAN you could access any address available to the program by
>> declaring an array and then exceed the bounds of the array.  Negative
>> subscripts usually worked too.  Port I/O wasn't possible in that way
>> though, there you had to resort to subroutines in e.g. assembly language.
> 
> Cute. In Pascal it was as simple as declaring a variant record of both
> Integer and pointer to Integer types, which easily got you peek and
> poke. Note this ony works on architectures where Int and Int^ are the
> same size, but in the cases that they aren't you can substitute another
> type. It allows you to mimic peek and poke. I used this technique
> routinely in Apple Pascal for hardware access when speed wasn't an
> issue.
> 
> Ada actually provides an ADDRESS type, which is specified by the
> standard to be implementation dependant. Every type in the language
> provides an address attribute that you can access, assign to variables
> of type ADDRESS, etc. This gives you equivalent functionality to C's
> (void *), albiet with a greater degree of compile time type safety.
> 
> Owing to the lack of commercial success of Ada, most people tend to
> believe that languages that provide strict type systems are necessarily
> less 'efficient' than C/C++. This is actually completely untrue.
> Strictly speaking, the more information a compiler has about the
> constraints of data types, the more optimisations you can perform.
> Indeed, the lack of typing in C/C++ makes many optimisations
> impossible, as the program appears to be non-deterministic to the
> optimiser, when in reality the actual data range used is fixed, and
> small enough to qualify for a number of clever optimisations.

Once, many years ago, I attended some lectures on Ada optimization.
The lecturer there said that, ideally, any program which has no input
but only output should be optimized to a "print constant string" statement.
I.e. such programs should actually be executed at compile time!
Of course, that constant string might be very long.  But it is an
interesting idea that the program:

#include <stdio.h>
#include <math.h>

int main()
{
    int i;
    printf( "   x     sqrt(x)\n\n" );
    for( i=0; i<100; i++ )
        printf( "%4d %10.4f\n", i, sqrt(i) );
    return 0;
}

in the ideal case should be optimized to:

#include <stdio.h>

int main()
{
    printf( "   x     sqrt(x)\n"
            "\n"
            "   0     0.0000\n"
            "   1     1.0000\n"
            "   2     1.4142\n"
            "   3     1.7321\n"
            "   4     2.0000\n"
            "   5     2.2361\n"
            "   6     2.4495\n"
            "   7     2.6458\n"
            "   8     2.8284\n"
            "   9     3.0000\n"
            "  10     3.1623\n"
            "  11     3.3166\n"
            "  12     3.4641\n"
            "  13     3.6056\n"
            "  14     3.7417\n"
            "  15     3.8730\n"
            "  16     4.0000\n"
            "  17     4.1231\n"
            "  18     4.2426\n"
            "  19     4.3589\n"
            "  20     4.4721\n"
            "  21     4.5826\n"
            "  22     4.6904\n"
            "  23     4.7958\n"
            "  24     4.8990\n"
            "  25     5.0000\n"
            "  26     5.0990\n"
            "  27     5.1962\n"
            "  28     5.2915\n"
            "  29     5.3852\n"
            "  30     5.4772\n"
            "  31     5.5678\n"
            "  32     5.6569\n"
            "  33     5.7446\n"
            "  34     5.8310\n"
            "  35     5.9161\n"
            "  36     6.0000\n"
            "  37     6.0828\n"
            "  38     6.1644\n"
            "  39     6.2450\n"
            "  40     6.3246\n"
            "  41     6.4031\n"
            "  42     6.4807\n"
            "  43     6.5574\n"
            "  44     6.6332\n"
            "  45     6.7082\n"
            "  46     6.7823\n"
            "  47     6.8557\n"
            "  48     6.9282\n"
            "  49     7.0000\n"
            "  50     7.0711\n"
            "  51     7.1414\n"
            "  52     7.2111\n"
            "  53     7.2801\n"
            "  54     7.3485\n"
            "  55     7.4162\n"
            "  56     7.4833\n"
            "  57     7.5498\n"
            "  58     7.6158\n"
            "  59     7.6811\n"
            "  60     7.7460\n"
            "  61     7.8102\n"
            "  62     7.8740\n"
            "  63     7.9373\n"
            "  64     8.0000\n"
            "  65     8.0623\n"
            "  66     8.1240\n"
            "  67     8.1854\n"
            "  68     8.2462\n"
            "  69     8.3066\n"
            "  70     8.3666\n"
            "  71     8.4261\n"
            "  72     8.4853\n"
            "  73     8.5440\n"
            "  74     8.6023\n"
            "  75     8.6603\n"
            "  76     8.7178\n"
            "  77     8.7750\n"
            "  78     8.8318\n"
            "  79     8.8882\n"
            "  80     8.9443\n"
            "  81     9.0000\n"
            "  82     9.0554\n"
            "  83     9.1104\n"
            "  84     9.1652\n"
            "  85     9.2195\n"
            "  86     9.2736\n"
            "  87     9.3274\n"
            "  88     9.3808\n"
            "  89     9.4340\n"
            "  90     9.4868\n"
            "  91     9.5394\n"
            "  92     9.5917\n"
            "  93     9.6437\n"
            "  94     9.6954\n"
            "  95     9.7468\n"
            "  96     9.7980\n"
            "  97     9.8489\n"
            "  98     9.8995\n"
            "  99     9.9499\n"  );
    return 0;
}

> Of course, this also means that the search space for possible
> optimisations gets larger, so compilers get slower, and take many more
> years to mature. C remains the most frequently implemented compiled
> language not because of it's efficiency, but because the modest size of
> the language makes it easy to implement, and the optimisations that are
> possible on C code are well known.


>> Not necessarily.  The idea of portability in C is to use the underlying
>> hardware as efficiently as possible: if the hardware uses 1-bit complement
>> then that C implementation uses 1-bit complement too .... etc etc.  If
>> written with portability in mind, C code can then be made to run as efficiently
>> as possible in very different architectures.
> 
> But Paul, using hardware as efficiently as possible and portability are
> obviously mutually exclusive concepts :-)
> 
> Implementing Java on an architecture that uses 1's complement doesn't
> necessarily cause performance issues either. In fact, the
> representation of the number is irrelevant until it's either accessed
> using bitwise operations, which can be catered for very simply by the
> VM by converting the type back and forward as necessary, or when the
> number is serialised. In the serialisation case, the byte order is
> specified by the specification to guarantee *portability*.
> 
> For the most part, bitwise manipulation in C is done to efficiently
> utililise memory, be it passing flags to a function as an int, when
> it's really going to be treated as an array of booleans, or to provide
> space efficient boolean arrays.

There's even a special data type for that in C: the bit field.  It's
not an array though -- it's merely a way to give specific bits of an int
a name of its own, and let the compiler take care of the needed shifting
and masking.

> In Java, these techniques are redundant; you have a boolean type. The
> JIT subsystem can optimise this however it sees fit.
> 
> It's actually becoming apparent that Java code can, and often does,
> outperform compiled C/C++. The implementation abstraction means that
> the JIT or HotSpot compiler can easily exploit the target architectures
> particular quirks. A C/C++ program can only exploit the architecture is
> written to exploit, and ones that happen to be very similar. Efficient?
> yes. Portable? no.
> 
>> ...interesting portability problem:  "...hey, these 128-bit integers are
>> too big!  We're having problems storing the value 763 in it....."  :-)
> 
> It is a problem, as has been stated before in this thread. And think
> about when you're back porting. Perhaps you'd like to use a bunch of C
> code on an 8 or 16 bit microcontroller? Chances are a bunch of things
> will need to be changed because of unforseen portability issues. Or
> perhaps in the name of efficiency you'll use smaller data types in some
> areas. Such is the nature of C.
> 
> It's far safer, IMHO to consider C an assembly language replacement
> than a portable high-level language.

C is frequently referred to as "portable assembler".  C is also the
target language for the output from compilers of other languages,
such as Eiffel, and also early C++ compilers.

>>> No. You're confusing the issues. Java is comprised of a language, an
>>> API and a virtual machine. The API is written in Java,
>>
>> The API is just glue code between the Java program and the VM.
> 
> That only applies to the tiny subset of the API that performs I/O! What
> about the rest of the API? The vast majority of the API is implemented
> in pure Java. It's a hell of a lot more than just glue code to the VM

I don't consider that an API, but a library!  An API should provide access
to something else but itself.  Such as external hardware, or some other
software module.

Almost all languages has a library of functions or classes.  The "high
level assembler" language C is no exception.  Consider for instance
the qsort() function in the Standard C library -- is that function an
API?  Or is it a library function?

>>> and is just a portable as any other Java program.
>>
>> If so, then it's just as impossible to write a Windows program that's bound to
>> a specific machine architecture: just write a Windows emualator for any
>> target platform you want.
> 
> History has shown this isn't true. Any effective emulator for Windows
> is actually an emulation of the x86 architecture, which can then run
> Windows itself.

Emulating the x86 architecture isn't enough.  The Mac has now switched to
the x86 CPU, yet you cannot boot Windows on any x86 equipped Mac.  You
must emulate the surrounding hardware environment as well.
 
> The only third party attempt at reimplementing Windows that has had any
> success at all is the WINE project, and that too is bound to the x86
> architecture. It is also, woefully incomplete, despite being started as
> a project back when Win16 was the dominant API.
> 
> So Windows emulation relies on implementing a Windows compatible
> machine emulator.  Not exactly an efficient solution.
> 
> Microsoft themselves know this. Why else would they have moved to an
> extremely Java like system with .NET ?
> 
>> I suppose that happened when JIT was introduced in Java: code called through
>> JNI was more efficient than "old Java", without JNI, but less efficient than
>> Java with JIT.  And the JNI interface is by itself an overhead.
> 
> It became far more pronounced after the introduction of JIT, yes. These
> days, it's usually more efficient to implement in Java than use JNI, as
> there is obviously performance overhead in the JNI interface due to
> it's portability restrictions.
> 
>>>>> Ever tried porting some C code to a 64 bit platform?
>>>>
>>>> I've ported some 8-bit and 16-bit C code to 32 bit platforms, so I'm well
>>>> acquainted with the problems which then may arise.  Porting from 32-bit
>>>> to 64-bit is probably not much different.
>>>>
>>>>> Many C compilers implement int as a 32 bit quantity even on 64 bit
>>>>> architectures,
>>>>
>>>> Those C compilers aren't follow ANSI C compliant, I would say.
>>>
>>> Sure they are. The ANSI standard requires only that int is at least 16
>>> bit, and signed. Addresses are whatever they are on the host
>>> architecture.
>>
>> Sorry, but ANSI C says more than that about the size of an int.
>> ANSI X3.159-1989, paragraph "3.1.2.5 Types", explicitly says:
>>
>> # A "plain" int object has the natural size suggested by the
>> # architecture of the execution environemt.
>>
>> Now, what do you think the "natural size" on a 64-bit architecture is?
>> 32 bits?   <g>
> 
> Actually, yes! Prior to the introduction of 64 bit machines, there was
> not one single implementation of C that declared int to be 64 bit. No
> existing code relies on it being that big, and it wastes a ridiculous
> amount of memory to declare it as such.
> 
> Generally speaking, a C implementation will opt for int as 32 bits,
> unless the machine architecture (and this does happen) restricts the
> alignment of 32 bit quantities in such a way that breaks the C
> standards. Some RISC architectures restrict load/store operations to
> addresses that are a multiple of its addressing size, which places
> severe restrictions on the sizing that can be chosen for C data types.
> 
> The proponents of RISC systems back in the 90's severely underestimated
> the volume of non-portable C code out in the wild, if you ask me. In
> fact, this issue may have been a big contributor to the lack of success
> of these systems. The PPC crowd found out very quickly that they needed
> to implement most of the hardware hacks the intel guys did, as it just
> wasn't possible to implement efficient compilers for their
> architectures, at least not in a reasonable amout of time.
> 
> Bytecode to machine code translators on the other hand....
> 
>> C follows the idea "Trust the programmer" -- apparently, a lot of programmers
>> weren't trustworthy.  Therefore "strait-jacket languages" like Pascal and Java
>> were needed....
> 
> It's not just a matter of trust. And besides, lousy/lazy programmers do
> exist, and will continue to.
> 
> Comparing Java to Pascal is a little harsh. Pascal was primarily
> intended as a teaching language,

....just like the original intention of Basic -- and both these languages are
still used to write actual applications, even though Basic nowadays usually
is called "Visual Basic" and Pascal usually is called "Delphi".

> and it's type system is sufficiently
> constrained as to cause a lot of needless limitations on the
> programmer. For example, it's almost impossible to write generic code
> in Pascal. Java has none of these limitations. It provides an excellent
> tradeoff between functionality loss and type safety compared to
> languages that predate it.

....but why does java lack unsinged integer data types?  And regarding safety:
Java integers still overflow silently, just like C integers do.
 
>> Another victory for strait-jacket languages... :-)
> 
> Here's a question for you: Besides directly accessing hardware
> features, what program is difficult to write in Java, versus C/C++?

Manipulating binary data is a bit awkward due to the lack of unsigned
byte and integer types in Java.

Complex arithmetic: Java lacks a Complex data type, and also lacks the
capability of operator overloading.  Here, FORTRAN, C++ or C99 are the
preferred languages.  Vector arithmetic: ditto - here C++ or Fortran-9x
are the preferred languages.  Bignum arithmetic: Ditto - C++ preferred.
Any other form of arithmetic where the built-in data types are
insufficient.

>> I know the stuff called through JNI must be written in C (using C++ here
>> would be messier).  Yet, JNI is a hole in Java which also poses a
>> danger.
> 
> It's actually possible to implement the VM in such a way that any
> danger imposed by JNI cannot compromise the security model, or even
> crash the application. Typically this isn't done for performance
> reasons, but there are implementations that provide this level of
> safety.

That would require the VM to run in a memory space different from the
memory space of the called C code.  Switching memory spaces when calling
C code is definitely a performance bottleneck.
 
>> The method differs, true, but the end result is the same: versatility,
>> insecurity, and non-portability.
> 
> Not true. The end result, as history has shown, is very different. The
> Microsoft approach allows a great deal of 'laziness' on the part of
> those porting existing code to the new environment, and allows the
> number of portability and security issues to multiply just as easily as
> they did in the C/C++ world.
> 
>>>>> This compromises not only the portability of Java
>>>>> programs, but also the security model provided by the Java platform,
>>>>> which is dependent on programs not being able to access memory that
>>>>> belong to the VM, or any other program that's running in the same
>>>>> memory space.
>>>>
>>>> How well is that security model maintained in GNU's Java implementation
>>>> which runs without any VM and generates native code?
>>>
>>> Just as well, of course. The language definition is the same, and it
>>> still prevents you writing code that will access machine dependant
>>> features.
>>>
>>>> Yep -- Java was about to be standardized some years ago, but then Sun
>>>> changed its mind and stopped that.  Even C# now has an (ECMA) standard.
>>>
>>> Which is to be honest a pointless marketing exercise. The language
>>> definition itself is useless without its API, as 99.9% of useful C#
>>> programs rely on the .NET API, which is in itself not portable - it
>>> relies heavily on Win32 to provide its functionality.
>>
>> But Win32 is just as portable as the Java API - there are Win32 emulators
>> running on other platforms.
> 
> This is more precisely put as Intel architecture emulators running on
> other architectures. The Win32 platform remains tied to x86. Have a
> look at Windows 64 bit edition on the IA-64 and see how it handles
> backwards compatibility. It's so inefficient that you just do not do
> it, you use real x86 boxes instead.
> 
> This is going to remain the case with .NET applications as well,
> despite their supposed 'portability' due to the way legacy code can be
> called. For some time, .NET applications on Win64 had to run via the
> Win32 emulator, which is already terribly slow. This applies for any
> application that uses the .NET API, since it merely thunks calls
> through to Win32.
> 
> The Java approach is different. Reimplement the API in Java. Make it as
> portable as anything else written in the language. The result? Java is
> implemented on every platform it's viable to run it on.
> 
>> Then how come there are Windows emulators running on other platforms?
> 
> Which ones? See above. Any successful implementation of Windows
> emulation is actually an x86 PC emulator running actual Windows.
> 
>> When you say just "Java" I think you usually mean both.  Remove the
>> platform and you can't run your Java program.  Remove the language,
>> and you'll have to program in bytecode directly, which would be
>> possible, although awkward.
> 
> It's probably more accurate to refer to Java as a "meta-platform" as
> even though it provides all the functionality of a "platform" it in
> itself (generally) requires a host platform to operate. It's certainly
> possible to implement the VM as an operating system itself, but the
> goal is not to create new concrete platforms, but to provide a unified
> "meta-platform" that other existing platforms can host. Java succeeds
> in this goal very well.
> 
>> UCSD Pascal perhaps?  :-)    Although now obsolete, that system had
>> precisely the same objective.  But UCSD Pascal was too early -- the slow
>> hardware of that time made emulating a pseudo-machine unacceptably slow.
>> And there also was no widespread Internet through which applications
>> could be distributed.
> 
> All of those limitations have now gone, and history speaks for itself,
> I think.
> 
> It's certainly a contentious issue, and theres supporters on either
> side of the fence. Academically speaking, there's no such thing as true
> portability. As long as there are multiple platforms there will be
> applications that aren't portable.
> 
> It's pointless though to consider the argument in academic terms, only
> in practical terms. Java meets its goals of portability. .NET has yet
> to meet those goals, and frankly, I doubt it ever will. Microsoft
> simply have no interest in making it easy to run Windows applications
> on a non-Microsoft platform. You can argue that their system is
> inherently portable, but it remains impractical to port Windows
> applications.
> 
> I actually find it pretty amusing to watch. Microsoft continually rely
> on the installed base to maintain their market, but in binding new
> technologies to the installed base, they sacrifice their ability to
> take advantage of new architectures. I have a feeling that as time goes
> by, this strategy is going to prove very costly, as every other
> 'platform' out there just doesn't have the same limitations. GNU/Linux
> has portability advantages because almost all the source is open. Java
> has it because of it's portable meta-platform. Apple have transitioned
> almost seamlessly from PPC to x86.
> 
> It's like watching a time-bomb count down, if you ask me ;-)

It may not be a time bomb, but rather stagnation.

We can compare with another technology: television.  Consider the US
NTSC ("Never The Same Color") TV system which has been in use for over
50 years now.  The color problem of this system has since long been
fixed, and the fix was implemented in the European TV systems which
went color about a decade after the US.  But the US TV system cannot
be upgraded because of the huge amounts of TV sets out there that one
would need to maintain backwards compatibility to.  Only now, when
switching to digital TV, it will be upgraded -- but it'll be there for
at least another decade or so, for backwards compatibility.



-- 
----------------------------------------------------------------
Paul Schlyter,  Grev Turegatan 40,  SE-114 38 Stockholm,  SWEDEN
e-mail:  pausch at stockholm dot bostream dot se
WWW:     http://stjarnhimlen.se/
0
pausch
5/31/2006 7:42:47 AM
mdj wrote:
> Write a large desktop application for the proprietary API
> of any platform, be it MacOS, Windows, and you've got yourself a pretty
> thick portability barrier.
>
> If you write your application in a portable language/platform such as
> Java (which is really the only successful one) you eliminate this
> problem.

I would argue that the modern web browser (i.e. HTML/Javascript/AJAX
etc) is effectively the only other major 'portable' platform. Somewhat
ironically, Microsoft pioneered AJAX technology, but probably backed
off in horror once they realised that WebOutlook didn't really need to
have a MS backend.

> This has been happening for years, and is really only a few steps away
> from being complete. Sun is the only vendor left who is really pushing
> their version of UNIX in favour of Linux, everyone else has decided to
> fold their own unique advantages back into the Linux kernel. At this
> point it becomes the big bad guy Linux versus the other Open Source
> alternatives ;-)

With Sun (Java) and the open source community inching ever closer, it
could be hoped that this day is not far off.

Still, .NET can't be ruled out, as Microsoft have bought some of the
finest minds that money can buy (Jim Blinn, sob sob) and are pushing
hard to gain ground in high-growth markets like mobile/embedded, the
video game industry, home consumer/media managemen/formats etc.

They've twisted Java into something not-half-bad. Just not portable
outside it's own ecosystem. Which is very bad.

Cheers,
Nick.

0
sicklittlemonkey
5/31/2006 8:06:12 AM
In article <gLOdnYcddOPrceHZnZ2dnUVZ_uqdnZ2d@comcast.com>,
Michael J. Mahon <mjmahon@aol.com> wrote:

> And the number of economically important "different" platforms is
> decreasing to a very small number, largely as a result of market
> forces triggered by a huge object code base (which the market thinks
> of as non-portable).

Will it shrink all the way down to one such platform?


> And, perhaps because of designers' clarity, or perhaps because of their
> laziness, we have settled almost universally on a set of data repre-
> sentations that are common across architectures:  IEEE floating point,
> twos-complement integers in power-of-two byte sizes, and 8-bit ASCII.

FYI: there is no such thing as "8-bit ASCII".  ASCII is a 7-bit code.

If you want to use 8-bit character codes you'll have a lot to choose
among.  Nowadays some flavor of ISO-8859 is the most common: in the
US and in western Europe ISO-8859-1 (aka ISO-Latin-1 -- yes there are
other versions of ISO-Latin than ISO-Latin-1) is usually used.

> Big alphabets are still a (national) problem,

The alphabets need not be bigger than ours to be a problem.  The Greek
alphabet is smaller than the Latin alphabet, but you'll have to use
ISO-8859-7 to get access to Greek letters.  The Cyrillic alphabet
is only slightly larger than ours, but to get access to that alphabet
you'll need to use ISO-8859-5.

Even some countries whose languages use the Latin alphabet still can't
use ISO-8859-1 because it lacks a few characters in their alphanet.
In Turkey one must use ISO-8859-3 and in Iceland ISO-8859-4.

There's a way out of this mess with different varieties of "8-bit
ASCII" though: Unicode.  Yes, it's coming and it's getting more and
more noticeable.  Windows-NT used UCS-2 for its internal
representation of e.g filenames, and in Windows-2000 a switch was made
to UTF-16 (both are 16-bit character codes, but while UCS-2 can only
hold the first 64K of the Unicode alphabet, UTF-16 can hold the entire
Unicode alphabet).  Java uses either UCS-2 or UTF-16 (don't know
which, maybe it doesn't matter except for display purposes) internally
in strings.  In situations where a 16-bit character code is
impractical, UTF-8 is the obvious choice.  Linux already supports
that in at least some distributions, and by choosing an UTF-8 locale,
one can have console output in Greek or Cyrillic characters.

Java is interesting here btw - a Java compiler already accepts
source code in Unicode - a proper BOM (Byte Order Mark) at the
beginning of the file will tell the Java compiler which flavor
of Unicode it is (UTF-8, UTF-16, UCS-4).

People who were used to programming langauges like FORTRAN and
Pascal, which were case insensitive, intially got a bit confused
by e.g. C code like this:

    int a = 12;
    int A = 45;

Doing the equivalent in Pascal would cause a "variable already
defined" error.  But in C this works because C is case sensitive,
and here a and A are two different variables.


In Java you can have even more fun that this - consider:

    int A = 12;
    int A = 45;
    int A = 82;
    int A = 113;
    int A = 176;
    int A = 217;

(this should really have been written in UTF-8 to be correct,
but displaying it would make it look like this anyway)

The same variable A defined six times?  That cannot work ....  yes it
can!

The first A is the capital Latin A - character code 0x41
The second A is the capital Cyrillic A - character code 0x391
The third A is the capital Greek Alfa - character code 0x410
The fourth A is the capital Cherokee A - character code 0x13AA
The fifth A is the capital Canadian Aboriginal A - character code 0x15C5
The sixth A is the Math Symbol capital A - character code 0x1D5A0
(the last case works only if Java uses UTF-16 rather than UCS-2)

Finally, we might have:

    int C = (A+A)*A - (A+A)*A;

and from a source listing it'll be impossible to figure out the value
of C (hint: it's not zero....) .... unless we take a hex dump of the
source code so we can see which identifiers really are used!


In Java, (almost) the entire Unicode alphabet can be used as names
for identifiers -- so expect some really "interesting" Java software
in, say, 10 years....




> It's pointless though to consider the argument in academic terms, only
> in practical terms. Java meets its goals of portability. .NET has yet
> to meet those goals, and frankly, I doubt it ever will. Microsoft
> simply have no interest in making it easy to run Windows applications
> on a non-Microsoft platform. You can argue that their system is
> inherently portable, but it remains impractical to port Windows
> applications.

When the number of economically important "different" platforms
has decreased to one (M$-Window$), then .NET will finally have become
"universally portable" .... :-)

Will this horror future scenario ever happen?  Well, we're getting there:
Macs are nowadays Intel based, and in the future there will probably be
Windows versions which can boot on the Mac.  Today's sypercomputers are
usually clusters based on Intel machines.  But what about Linux?  Linux
will be there, of course, but since Linux is free it's not "economically
important".... :-)

-- 
----------------------------------------------------------------
Paul Schlyter,  Grev Turegatan 40,  SE-114 38 Stockholm,  SWEDEN
e-mail:  pausch at stockholm dot bostream dot se
WWW:     http://stjarnhimlen.se/
0
pausch
5/31/2006 8:12:56 AM
sicklittlemonkey wrote:

> I would argue that the modern web browser (i.e. HTML/Javascript/AJAX
> etc) is effectively the only other major 'portable' platform. Somewhat
> ironically, Microsoft pioneered AJAX technology, but probably backed
> off in horror once they realised that WebOutlook didn't really need to
> have a MS backend.

Agreed. Interestingly almost all web development occurs in portable
languages, with the exception of .NET and yet to be ported ASP
solutions. I'd imagine it's more or less impossible at this stage for
Microsoft to control this market. They just cannot compete on
price/performance, tco, etc.

The browser itself however is far from a standardised environment, and
adding rich functionality requires catering for multiple platforms. Of
course, if IE just disappeared off the face of the earth this would get
much easier :-)

> With Sun (Java) and the open source community inching ever closer, it
> could be hoped that this day is not far off.

Won't be long... I have a feeling that the biggest gap close will be
during the XP -> Vista transition, in the desktop sense. In the server
sense, the gap just keeps getting wider. I see more and more systems
moving onto Open Source servers every day. Biggest drivers? Cost of
maintenence.

> Still, .NET can't be ruled out, as Microsoft have bought some of the
> finest minds that money can buy (Jim Blinn, sob sob) and are pushing
> hard to gain ground in high-growth markets like mobile/embedded, the
> video game industry, home consumer/media managemen/formats etc.

It's true, but I'm not sure technical superiority will win out in an
environment where not being portable is a requirement. Choice of
deployment platform is becoming such a critical decision point.

On the desktop, of course it will win out. Windows is king of the
desktop. Gonna stay that way for quite a while.

> They've twisted Java into something not-half-bad. Just not portable
> outside it's own ecosystem. Which is very bad.

I still maintain that the "unmanaged code" facility is a major issue
for .NET from a security and stability perspective. It's a crap design
decision, and it's proven very costly already.

Matt

0
mdj
5/31/2006 10:45:04 AM
pausch@saaf.se (Paul Schlyter) writes:

>Once, many years ago, I attended some lectures on Ada optimization.
>The lecturer there said that, ideally, any program which has no input
>but only output should be optimized to a "print constant string" statement.
>I.e. such programs should actually be executed at compile time!
>Of course, that constant string might be very long.

Heaven help the compiler if there is an infinite loop involved ...

--
      Cameron Kaiser * ckaiser@floodgap.com * posting with a Commodore 128
                personal page: http://www.armory.com/%7Espectre/
  ** Computer Workshops: games, productivity software and more for C64/128! **
                  ** http://www.armory.com/%7Espectre/cwi/ **
0
Cameron
5/31/2006 1:50:22 PM
Paul Schlyter wrote:

> <large optimisation example snipped>

:-) Of course this is valid in theory. In practice you might find that
the looped version is actually faster, since it fits inside a L1 Cache
line... Theoretical speed and actual speed aren't the same thing on
modern processors.

> There's even a special data type for that in C: the bit field.  It's
> not an array though -- it's merely a way to give specific bits of an int
> a name of its own, and let the compiler take care of the needed shifting
> and masking.

Indeed. Bit fields however have implementation specific warnings all
over them. You can usually get better portability avoiding them.

> C is frequently referred to as "portable assembler".  C is also the
> target language for the output from compilers of other languages,
> such as Eiffel, and also early C++ compilers.

It's useful for bootstrapping a compiler on a new platform, yes.

> I don't consider that an API, but a library!  An API should provide access
> to something else but itself.  Such as external hardware, or some other
> software module.

Fair enough. I consider the terms API and "standard library"
synonymous, as I'm sure most developers do .... And I am referring to
the standard library in this case, ie. the functionality you can rely
on to be in every Java implementation. Of course, what you can't rely
on, you can bring with you...

> Almost all languages has a library of functions or classes.  The "high
> level assembler" language C is no exception.  Consider for instance
> the qsort() function in the Standard C library -- is that function an
> API?  Or is it a library function?

Please... The ANSI C library is hardly the basis of a portable
platform.

> Emulating the x86 architecture isn't enough.  The Mac has now switched to
> the x86 CPU, yet you cannot boot Windows on any x86 equipped Mac.  You
> must emulate the surrounding hardware environment as well.

Actually, you can boot Windows on any x86 equipped Mac, with Apple's
blessing. The other way around on the other hand....

> ...just like the original intention of Basic -- and both these languages are
> still used to write actual applications, even though Basic nowadays usually
> is called "Visual Basic" and Pascal usually is called "Delphi".

Both VB and Delphi are far enough removed from the languages they're
derived from to be considered different languages, IMO

> ...but why does java lack unsinged integer data types?  And regarding safety:
> Java integers still overflow silently, just like C integers do.

That's true. Overflows don't cause portability problems though, just
bugs. You can get around unsigned types easily enough by using the next
larger type, but I agree it's an oversight, and an ugly one. It does
however dramatically simplify the expression compiler/optimiser

> Manipulating binary data is a bit awkward due to the lack of unsigned
> byte and integer types in Java.

See above. I've never found it particularly annoying, no more so than I
used to back in BASIC on the Apple II peeking negative locations :-)

> Complex arithmetic: Java lacks a Complex data type, and also lacks the
> capability of operator overloading.  Here, FORTRAN, C++ or C99 are the
> preferred languages.  Vector arithmetic: ditto - here C++ or Fortran-9x
> are the preferred languages.  Bignum arithmetic: Ditto - C++ preferred.
> Any other form of arithmetic where the built-in data types are
> insufficient.

I think we've strayed from the point a bit. Yes, Java is missing a
number of features that are available in other languages. To be honest,
I don't miss operator overloading all that much, but it'd be nice if it
was there...

> > It's actually possible to implement the VM in such a way that any
> > danger imposed by JNI cannot compromise the security model, or even
> > crash the application. Typically this isn't done for performance
> > reasons, but there are implementations that provide this level of
> > safety.
>
> That would require the VM to run in a memory space different from the
> memory space of the called C code.  Switching memory spaces when calling
> C code is definitely a performance bottleneck.

That's right, which is why it isn't done unless you're security
paranoid, or have a very good reason.

> We can compare with another technology: television.  Consider the US
> NTSC ("Never The Same Color") TV system which has been in use for over
> 50 years now.  The color problem of this system has since long been
> fixed, and the fix was implemented in the European TV systems which
> went color about a decade after the US.  But the US TV system cannot
> be upgraded because of the huge amounts of TV sets out there that one
> would need to maintain backwards compatibility to.  Only now, when
> switching to digital TV, it will be upgraded -- but it'll be there for
> at least another decade or so, for backwards compatibility.

The analogy holds to some extent, but lifecycles are much shorter in
the computing world. The question is, will the issues of the old
'standard' be fixed when moving to the new. I reckon with Microsofts
approach they won't, as they've carried the issues forward with them,
making their next generation signal a bit like NTSC at several times
the bandwidth, but still off colour ;-)

Matt

0
mdj
5/31/2006 2:41:06 PM
In article <1149086466.883167.33940@y43g2000cwc.googlegroups.com>,
mdj <mdj.mdj@gmail.com> wrote:

> Paul Schlyter wrote:

.......................

>> I don't consider that an API, but a library!  An API should provide access
>> to something else but itself.  Such as external hardware, or some other
>> software module.
>
> Fair enough. I consider the terms API and "standard library"
> synonymous, as I'm sure most developers do ....

I don't -- an API does not need to be standard, while a "standard
library" certainly cannot ignore standards!  Of course an API can be
implemented as a library, but it doesn't have to.  A header file (in C
or C++) could also serve as an API.

> And I am referring to the standard library in this case, ie. the functionality
> you can rely on to be in every Java implementation.

Unfortunately the Java standard library has varied between versions - even
if we only consider Sun's Java implementations.  So you can forget that
about "every Java implementation"....

> Of course, what you can't rely on, you can bring with you...
>
>> Almost all languages has a library of functions or classes.  The "high
>> level assembler" language C is no exception.  Consider for instance
>> the qsort() function in the Standard C library -- is that function an
>> API?  Or is it a library function?
>
> Please... The ANSI C library is hardly the basis of a portable platform.

The qsort() function is *quite* portable ---- as are most other ANSI C
library functions which do not access external hardware or OS services.

>> Emulating the x86 architecture isn't enough.  The Mac has now switched to
>> the x86 CPU, yet you cannot boot Windows on any x86 equipped Mac.  You
>> must emulate the surrounding hardware environment as well.
>
> Actually, you can boot Windows on any x86 equipped Mac, with Apple's
> blessing.

Natively?  Or on top of some emulation layer?

> The other way around on the other hand....

That's because Apple didn't make its OS-X86 conform to standard x86
computers... <g>

>> ...just like the original intention of Basic -- and both these languages are
>> still used to write actual applications, even though Basic nowadays usually
>> is called "Visual Basic" and Pascal usually is called "Delphi".
>
> Both VB and Delphi are far enough removed from the languages they're
> derived from to be considered different languages, IMO

.....well I can agree about that.

>> ...but why does java lack unsinged integer data types?  And regarding safety:
>> Java integers still overflow silently, just like C integers do.
>
> That's true. Overflows don't cause portability problems though, just
> bugs. You can get around unsigned types easily enough by using the next
> larger type,

That's not enough:

    byte b = (byte) 0xA0;
    int i  = b;

Here i will still be a negative number.  So you must do:

    int i = b & 0xFF;

to get what you want.

However, Java *does* have an unsigned data type: the char data type which
is a 16-bit unsigned type.  But doing:

    byte b = (byte) 0xA0;
    char c = (char) b;

would leave c with a positive value, sure, but the value would be 0xFFA0.
So we still have to do:

    char c = (char)(b & 0xFF);

to get what we want.  And Java don't even have macros to hide such stuff....

> but I agree it's an oversight, and an ugly one. It does
> however dramatically simplify the expression compiler/optimiser
>
>> Manipulating binary data is a bit awkward due to the lack of unsigned
>> byte and integer types in Java.
>
> See above. I've never found it particularly annoying, no more so than I
> used to back in BASIC on the Apple II peeking negative locations :-)

Actually, you were forced to do that only in Integer Basic.  In Applesoft
Basic you had a choice: you could use either negative or positive numbers.
So in Applesoft, "CALL -151" could also be written as "CALL 65385".

Constants in hex would have been nice though.  You got that with Apple CP/M,
where in MBasic you could write  "CALL &HFF69" --- but of course the Apple
Monitor couldn't be called just like that from the Z80....

-- 
----------------------------------------------------------------
Paul Schlyter,  Grev Turegatan 40,  SE-114 38 Stockholm,  SWEDEN
e-mail:  pausch at stockholm dot bostream dot se
WWW:     http://stjarnhimlen.se/
0
pausch
5/31/2006 4:13:50 PM
Paul Schlyter wrote:

> I don't -- an API does not need to be standard, while a "standard
> library" certainly cannot ignore standards!  Of course an API can be
> implemented as a library, but it doesn't have to.  A header file (in C
> or C++) could also serve as an API.

Generally speaking the libraries that ship with platforms are
considered a part of their API. True enough I suppose that an API
doesn't necessarily end up a library, if you use a strict definition of
library. As we all know though, these are pretty lose terms.

> > And I am referring to the standard library in this case, ie. the functionality
> > you can rely on to be in every Java implementation.
>
> Unfortunately the Java standard library has varied between versions - even
> if we only consider Sun's Java implementations.  So you can forget that
> about "every Java implementation"....

!!! There's nothing unfortunate about it improving with age :) There
were a few examples of backwards compatibility being broken in the
early editions, but these issues are well and truly behind us.
Obviously if you write code that depends on new features, you break
compatibility old editions.

> The qsort() function is *quite* portable ---- as are most other ANSI C
> library functions which do not access external hardware or OS services.

Indeed C programs that do no I/O are more portable that those that do,
but they're also completely useless :-) And it's still easy to write
platform dependent C programs that do no I/O

> > Actually, you can boot Windows on any x86 equipped Mac, with Apple's
> > blessing.
>
> Natively?  Or on top of some emulation layer?

http://www.apple.com/macosx/bootcamp/

> > The other way around on the other hand....
>
> That's because Apple didn't make its OS-X86 conform to standard x86
> computers... <g>

Actually, x86 Macs are standard x86 computers... MacOS X relies on the
newer EFI firmware specification. After promising that Windows Vista
would support EFI, Microsoft have reversed that decision, and
accordingly most of the big vendors are not supporting EFI in new
chassis. Another 5 years or so in the dark ages :-(

> That's not enough:
>
>     byte b = (byte) 0xA0;
>     int i  = b;
>
> Here i will still be a negative number.  So you must do:

The type promotions rules are the same as for C/C++. They're a lot more
useful that way that the other way around. When you're doing bitwise
operations, the actual numeric value doesn't matter that much, and you
can always use hex notation for constants to avoid the issue.

I've actually implemented a C compatible expression parser. Leaving out
the unsigned types dramatically simplifies things.

> to get what we want.  And Java don't even have macros to hide such stuff....

You use methods instead. The compiler will inline the method for you.
The same rule applies to C++, where use of the preprocessor is
generally frowned upon. It's there for backwards compatibility.
 
Matt

0
mdj
6/1/2006 9:06:13 AM
In article <1149152773.404039.252780@i40g2000cwc.googlegroups.com>,
mdj <mdj.mdj@gmail.com> wrote:

> Paul Schlyter wrote:
> 
>> I don't -- an API does not need to be standard, while a "standard
>> library" certainly cannot ignore standards!  Of course an API can be
>> implemented as a library, but it doesn't have to.  A header file (in C
>> or C++) could also serve as an API.
> 
> Generally speaking the libraries that ship with platforms are
> considered a part of their API. True enough I suppose that an API
> doesn't necessarily end up a library, if you use a strict definition of
> library. As we all know though, these are pretty lose terms.
> 
>>> And I am referring to the standard library in this case, ie. the functionality
>>> you can rely on to be in every Java implementation.
>>
>> Unfortunately the Java standard library has varied between versions - even
>> if we only consider Sun's Java implementations.  So you can forget that
>> about "every Java implementation"....
> 
> !!! There's nothing unfortunate about it improving with age :) There
> were a few examples of backwards compatibility being broken in the
> early editions, but these issues are well and truly behind us.
> Obviously if you write code that depends on new features, you break
> compatibility old editions.

..... I'm more annoyed with old code whith ceases to work with new JVM versions...

Actually, I keep a copy of Nescape 4.7 in working condition (with its
own, quite old, JVM), mostly to be able to browse web sites with
applets which no longer run properly on modern web browsers.
 
>> The qsort() function is *quite* portable ---- as are most other ANSI C
>> library functions which do not access external hardware or OS services.
> 
> Indeed C programs that do no I/O are more portable that those that do,
> but they're also completely useless :-)

I was talking about portable code, not necessarily about complete applications.
Code doing no I/O can still be useful, as a library called by your own program.

> And it's still easy to write platform dependent C programs that do no I/O

....of course ...such as:

int main()
{
    if ( sizeof(int) == sizeof(int *) )
        for(;;)
            ;

    return 0;
}

:-)

Btw in C you cannot write a program which do no output whatsoever.  Even the
minimal C program:

int main()
{
    return 42;
}

outputs a return code to the OS, which can be tested in shell scripts/etc.
And if you remove the return statement, the required output will be garbage.

 
>>> Actually, you can boot Windows on any x86 equipped Mac, with Apple's
>>> blessing.
>>
>> Natively?  Or on top of some emulation layer?
> 
> http://www.apple.com/macosx/bootcamp/
> 
>>> The other way around on the other hand....
>>
>> That's because Apple didn't make its OS-X86 conform to standard x86
>> computers... <g>
> 
> Actually, x86 Macs are standard x86 computers... MacOS X relies on the
> newer EFI firmware specification. After promising that Windows Vista
> would support EFI, Microsoft have reversed that decision, and
> accordingly most of the big vendors are not supporting EFI in new
> chassis. Another 5 years or so in the dark ages :-(

One good thing about standards is that there are so many to choose among... :-/
 
>> That's not enough:
>>
>>     byte b = (byte) 0xA0;
>>     int i  = b;
>>
>> Here i will still be a negative number.  So you must do:
> 
> The type promotions rules are the same as for C/C++. They're a lot more
> useful that way that the other way around. When you're doing bitwise
> operations, the actual numeric value doesn't matter that much, and you
> can always use hex notation for constants to avoid the issue.

....but if I want to output the value to some terminal or file, I'd
like the output to be A0 rather than FFFFFFA0 .... :-)
 
> I've actually implemented a C compatible expression parser. Leaving out
> the unsigned types dramatically simplifies things.

I believe you!  Leaving out most operators too will make the parser even
simpler.... :-)

>> to get what we want.  And Java don't even have macros to hide such stuff....
> 
> You use methods instead.

....or constants!  In C++ a 'const' declared int (or float, or....) is
really a constant and not merely a write protected variable.  So you can
do things like:

   const int arraysize = 1234;
   int array[arraysize];

Doing this is illegal in C - there you *must* use a macro (or a literal
integer constant).

> The compiler will inline the method for you.
> The same rule applies to C++, where use of the preprocessor is
> generally frowned upon. It's there for backwards compatibility.

Even in C++, the preprocessor is useful for conditional compilation.  You
can't do that with methods.....   The #pragma directove (an idea borrowed
from Ada) can be quite handy too.

And C/C++ macros contain the # (stringize) operator, which converts a
symbolic name to a string containing that name.  You can't do that with
methods either....
  
> Matt

-- 
----------------------------------------------------------------
Paul Schlyter,  Grev Turegatan 40,  SE-114 38 Stockholm,  SWEDEN
e-mail:  pausch at stockholm dot bostream dot se
WWW:     http://stjarnhimlen.se/
0
pausch
6/1/2006 4:13:26 PM
Paul Schlyter wrote:

<snip>

>    The #pragma directove (an idea borrowed
> from Ada) can be quite handy too.

Actually, I believe that _pragma_ was borrowed from Algol 68,
which must be the most influential least implemented language.  ;-)

-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."
0
Michael
6/1/2006 6:24:02 PM
Paul Schlyter wrote:

> > !!! There's nothing unfortunate about it improving with age :) There
> > were a few examples of backwards compatibility being broken in the
> > early editions, but these issues are well and truly behind us.
> > Obviously if you write code that depends on new features, you break
> > compatibility old editions.
>
> .... I'm more annoyed with old code whith ceases to work with new JVM versions...
>
> Actually, I keep a copy of Nescape 4.7 in working condition (with its
> own, quite old, JVM), mostly to be able to browse web sites with
> applets which no longer run properly on modern web browsers.

There was a very deliberate fractioning introduced between Java 1.1 and
1.2 (which marks the beginning of the Java 2 plaftorm)

The primary reason for this was to divorce 1.2 onwards from the
compatibility issues introduced by Microsofts J++ virtual machine - it
became a serious problem that a web browser running standard Java 1.1
couldn't run many applets out there, as those applets relied on Win32
API calls via the Microsoft extensions. This, coupled with the fact
that it was extremely difficult to switch the VM in Internet Explorer
caused Sun to draw a compatbility line between the two versions, and
implement a different applet plugin mechansim so both could co-exist.

Still, this didn't solve the whole problem, as many standard 1.1
Applets wouldn't run on Microsofts VM, which unfortunately shipped
standard with Windows, making Java look a lot worse than it actually
was.

> >> The qsort() function is *quite* portable ---- as are most other ANSI C
> >> library functions which do not access external hardware or OS services.
> >
> > Indeed C programs that do no I/O are more portable that those that do,
> > but they're also completely useless :-)
>
> I was talking about portable code, not necessarily about complete applications.
> Code doing no I/O can still be useful, as a library called by your own program.

Indeed. The language level portability issues remain, however, but yes
when developing libraries it is sometimes possible to avoid platform
specific API's. More often, you need to handle multiple cases when
developing portable C libraries.

> Btw in C you cannot write a program which do no output whatsoever.  Even the
> minimal C program:
>
> int main()
> {
>     return 42;
> }
>
> outputs a return code to the OS, which can be tested in shell scripts/etc.
> And if you remove the return statement, the required output will be garbage.

Hmm, I wasn't aware the standard actually required that an
implementation honour the return code, or program arguments for that
matter. Perhaps an implementation is required to provide a harness for
code conforming to the API. Admittedly though it's useless on systems
that don't implement such codes, but then platforms that don't do that
are pretty much now all obsolete.

In any case, we're talking about a value left on the stack at end of
program execution, which in my book doesn't constitute I/O

> One good thing about standards is that there are so many to choose among... :-/

And so many non-comforming implementations of those standards :-)

> ...but if I want to output the value to some terminal or file, I'd
> like the output to be A0 rather than FFFFFFA0 .... :-)

Of course, but formatted output is the responsibility of the API. Java
provides both C style (admittedly recently) and it's own 'OO' style I/O
facilities which can both accomplish that task very easily. If you're
relying on the default behavior to output things the way you want it,
then you're asking for trouble.

Ironically, a lot of features have been added in recent editions to
appease C programmers who wanted to do things the 'old' way. Most
notably was the addition of variable argument lists, which allows the
implementation of System.out.printf() :-)

> > I've actually implemented a C compatible expression parser. Leaving out
> > the unsigned types dramatically simplifies things.
>
> I believe you!  Leaving out most operators too will make the parser even
> simpler.... :-)

:-) The operators are relatively easy. dealing with implicit conversion
between data types is much more frustrating, and a source of
inefficiency, as there's always more than one way to handle the
conversions, with one being more efficient than the other...

> ...or constants!  In C++ a 'const' declared int (or float, or....) is
> really a constant and not merely a write protected variable.  So you can
> do things like:
>
>    const int arraysize = 1234;
>    int array[arraysize];
>
> Doing this is illegal in C - there you *must* use a macro (or a literal
> integer constant).

Works fine in Java, though.

> > The compiler will inline the method for you.
> > The same rule applies to C++, where use of the preprocessor is
> > generally frowned upon. It's there for backwards compatibility.
>
> Even in C++, the preprocessor is useful for conditional compilation.  You
> can't do that with methods.....   The #pragma directove (an idea borrowed
> from Ada) can be quite handy too.

It's still frowned upon, in favour of using a constant plus
if/else/switch constructs to do conditional compilation. One big
advantage of this approach is that if you compile with debug turned on,
the optimiser won't remove the conditional code, which makes source
level debugging simpler.

Such preprocessor techniques are unnecessary in modern languages. One
frustrating side effect of using it in C++ is that it still has global
namespace.

> And C/C++ macros contain the # (stringize) operator, which converts a
> symbolic name to a string containing that name.  You can't do that with
> methods either....

Facilities like this one are commonplace in languages that don't retain
type information at runtime. In Java, the .getName() class method
provides the same behavior, but better since it's evaluated at runtime
rather than compile time.

But then, many people want to treat Java as if it's C++ minus features,
rather than the very different language that it is.

Matt

0
mdj
6/2/2006 1:39:56 AM
In article <NtqdnZgXoZJereLZnZ2dnUVZ_vadnZ2d@comcast.com>,
Michael J. Mahon <mjmahon@aol.com> wrote:

> Paul Schlyter wrote:
> 
> <snip>
> 
>>    The #pragma directove (an idea borrowed
>> from Ada) can be quite handy too.
> 
> Actually, I believe that _pragma_ was borrowed from Algol 68,
> which must be the most influential least implemented language.  ;-)

.....yep, the "latin" among programming languages: now dead but still
having a lot of influence on other, non-dead, languages.
 
> -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."

-- 
----------------------------------------------------------------
Paul Schlyter,  Grev Turegatan 40,  SE-114 38 Stockholm,  SWEDEN
e-mail:  pausch at stockholm dot bostream dot se
WWW:     http://stjarnhimlen.se/
0
pausch
6/2/2006 1:13:15 PM
In article <1149212396.254683.197660@g10g2000cwb.googlegroups.com>,
mdj <mdj.mdj@gmail.com> wrote:

> Paul Schlyter wrote:
>
>>> !!! There's nothing unfortunate about it improving with age :) There
>>> were a few examples of backwards compatibility being broken in the
>>> early editions, but these issues are well and truly behind us.
>>> Obviously if you write code that depends on new features, you break
>>> compatibility old editions.
>>
>> .... I'm more annoyed with old code whith ceases to work with new JVM versions...
>>
>> Actually, I keep a copy of Nescape 4.7 in working condition (with its
>> own, quite old, JVM), mostly to be able to browse web sites with
>> applets which no longer run properly on modern web browsers.
>
> There was a very deliberate fractioning introduced between Java 1.1 and
> 1.2 (which marks the beginning of the Java 2 plaftorm)
>
> The primary reason for this was to divorce 1.2 onwards from the
> compatibility issues introduced by Microsofts J++ virtual machine - it
> became a serious problem that a web browser running standard Java 1.1
> couldn't run many applets out there, as those applets relied on Win32
> API calls via the Microsoft extensions. This, coupled with the fact
> that it was extremely difficult to switch the VM in Internet Explorer
> caused Sun to draw a compatbility line between the two versions, and
> implement a different applet plugin mechansim so both could co-exist.
>
> Still, this didn't solve the whole problem, as many standard 1.1
> Applets wouldn't run on Microsofts VM, which unfortunately shipped
> standard with Windows, making Java look a lot worse than it actually
> was.

Which explains why Sun later prohibited Microsoft to implement its own JVM.
That's when Microsoft switched to C#.

>>>> The qsort() function is *quite* portable ---- as are most other ANSI C
>>>> library functions which do not access external hardware or OS services.
>>>
>>> Indeed C programs that do no I/O are more portable that those that do,
>>> but they're also completely useless :-)
>>
>> I was talking about portable code, not necessarily about complete applications.
>> Code doing no I/O can still be useful, as a library called by your own program.
>
> Indeed. The language level portability issues remain, however, but yes
> when developing libraries it is sometimes possible to avoid platform
> specific API's. More often, you need to handle multiple cases when
> developing portable C libraries.

Yep -- portable C code usually has a lot of #if's and #ifdef's .....

>> Btw in C you cannot write a program which do no output whatsoever.  Even the
>> minimal C program:
>>
>> int main()
>> {
>>     return 42;
>> }
>>
>> outputs a return code to the OS, which can be tested in shell scripts/etc.
>> And if you remove the return statement, the required output will be garbage.
>
> Hmm, I wasn't aware the standard actually required that an
> implementation honour the return code,

The standard requires main() to return an int.  Sometimes one sees:

    void main()
    ........

which violates the standard.


> or program arguments for that matter.

Program arguments need not be handled.  There are two acceptable versions
of the main() function:


int main(void)       in C++ one can also write:  int main()

int main( int argc, char *argv[] )



> Perhaps an implementation is required to provide a harness for
> code conforming to the API. Admittedly though it's useless on systems
> that don't implement such codes, but then platforms that don't do that
> are pretty much now all obsolete.
>
> In any case, we're talking about a value left on the stack at end of
> program execution, which in my book doesn't constitute I/O

Whether the return value from main() is left on the stack, in some CPU
register, or at some other location, is implementation specific.
However, the startup code (which is part of every C runtime library)
is expected to take care of the return value from main(), and to
return it to the host OS according to the API of that OS.  And this
usually involves more than just leaving a value on the stack.

>> One good thing about standards is that there are so many to choose among... :-/
>
> And so many non-comforming implementations of those standards :-)

.....yep.... :-/

>> ...but if I want to output the value to some terminal or file, I'd
>> like the output to be A0 rather than FFFFFFA0 .... :-)
>
> Of course, but formatted output is the responsibility of the API. Java
> provides both C style (admittedly recently) and it's own 'OO' style I/O
> facilities which can both accomplish that task very easily. If you're
> relying on the default behavior to output things the way you want it,
> then you're asking for trouble.
>
> Ironically, a lot of features have been added in recent editions to
> appease C programmers who wanted to do things the 'old' way. Most
> notably was the addition of variable argument lists, which allows the
> implementation of System.out.printf() :-)

That's nice!  But it's also a hole in the fairly strict type checking
in Java.

>>> I've actually implemented a C compatible expression parser. Leaving out
>>> the unsigned types dramatically simplifies things.
>>
>> I believe you!  Leaving out most operators too will make the parser even
>> simpler.... :-)
>
> :-) The operators are relatively easy. dealing with implicit conversion
> between data types is much more frustrating, and a source of
> inefficiency, as there's always more than one way to handle the
> conversions, with one being more efficient than the other...

....well then the choice is easy: do it the most efficient way... :-)

Of course there's some work in ensureing that they way you chose really
was the most efficient.

>> ...or constants!  In C++ a 'const' declared int (or float, or....) is
>> really a constant and not merely a write protected variable.  So you can
>> do things like:
>>
>>    const int arraysize = 1234;
>>    int array[arraysize];
>>
>> Doing this is illegal in C - there you *must* use a macro (or a literal
>> integer constant).
>
> Works fine in Java, though.

True.

>>> The compiler will inline the method for you.
>>> The same rule applies to C++, where use of the preprocessor is
>>> generally frowned upon. It's there for backwards compatibility.
>>
>> Even in C++, the preprocessor is useful for conditional compilation.  You
>> can't do that with methods.....   The #pragma directove (an idea borrowed
>> from Ada) can be quite handy too.
>
> It's still frowned upon, in favour of using a constant plus
> if/else/switch constructs to do conditional compilation.

That causes a problem: a source line which shouldn't be used in some
particular environment can also be a syntax error in such an environment.
Consider for instance:

#if SIZE16BITS
    int i = 8000;
else  /* assume 32 bits or more */
    int i = 4000000;
#endif

If rewritten as:
    int i;
    if (SIZE16BITS)
        i = 8000;
    else  /* assume 32 bits or more */
        i = 4000000;

the "i = 4000000" will cause an integer constant overflow on 16-bit systems,
even though that line is never supposed to be executed there.  You'd
have to do tricks like:

    int i;
    if (SIZE16BITS)
        i = 8000;
    else  /* assume 32 bits or more */
        i = 4000000L;

to make it compile also on 16-bit systems.

> One big advantage of this approach is that if you compile with debug
> turned on, the optimiser won't remove the conditional code, which makes
> source level debugging simpler.

A decent source level debugger should of course also keep track of
sourse lines having conditional compilation code.

> Such preprocessor techniques are unnecessary in modern languages. One
> frustrating side effect of using it in C++ is that it still has global
> namespace.

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.....

>> And C/C++ macros contain the # (stringize) operator, which converts a
>> symbolic name to a string containing that name.  You can't do that with
>> methods either....
>
> Facilities like this one are commonplace in languages that don't retain
> type information at runtime. In Java, the .getName() class method
> provides the same behavior, but better since it's evaluated at runtime
> rather than compile time.

Is there a .setName() method too?  If there is, one might be able to
do quite interesting things with it.... :-)

> But then, many people want to treat Java as if it's C++ minus features,
> rather than the very different language that it is.

These peope are wrong of course.  Java resembles C++ only
superficially, mostly by having similar syntax.  But the semantics
under that syntax is quite different, and more resembles
"strait-jacket languages" like Pascal --- of course with a lot of
features not available in Pascal.  I usually think of Java as "the
UCSD Pascal of our times": it has portable object code which must be
run on a virtual machine.  However, it is object oriented, it is net
aware, and it is 32-bit rather than 16-bit.  And Java is also a
subsystem, not a whole OS like UCSD Pascal was.

> Matt

-- 
----------------------------------------------------------------
Paul Schlyter,  Grev Turegatan 40,  SE-114 38 Stockholm,  SWEDEN
e-mail:  pausch at stockholm dot bostream dot se
WWW:     http://stjarnhimlen.se/
0
pausch
6/2/2006 1:13:15 PM
Michael J. Mahon wrote:

> Actually, I believe that _pragma_ was borrowed from Algol 68,
> which must be the most influential least implemented language.  ;-)

As they say, Algol was a great improvement on its successors. ;-)

-- 
Linards Ticmanis
0
Linards
6/2/2006 7:44:46 PM
Linards Ticmanis wrote:
> Michael J. Mahon wrote:
> 
>> Actually, I believe that _pragma_ was borrowed from Algol 68,
>> which must be the most influential least implemented language.  ;-)
> 
> 
> As they say, Algol was a great improvement on its successors. ;-)

Algol 60 introduced many great ideas, like block structure and
BNF syntax description.

Algol 68, with its meta-syntactic definition, served to clarify
a number of issues in language design, but ultimately confused
its non-theorist "market".  I really liked the palindromic block
delimiters though ("do"-"od", "if"-"fi", etc.), and I used them
for a system implementation language ("proc"-"corp", "case"-"esac",
"struc"-"curts", etc.).

Many years later, I think that the "offside rule" for delimiting
blocks simply by indentation is a very nice approach.  Why on
earth should white space, the most significant characteristic of
text to the human eye, be ignored by most programming languages?

So the following would be properly "bracketed" by the offside
rule:

if condition1
    or condition2
then foo
      blah
      blah
else bar
      blah
nextstatement
....


-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."
0
Michael
6/3/2006 4:53:25 AM
On Fri, 2 Jun 2006, Michael J. Mahon wrote:

> Linards Ticmanis wrote:
>> Michael J. Mahon wrote:
>> 
>>> Actually, I believe that _pragma_ was borrowed from Algol 68,
>>> which must be the most influential least implemented language.  ;-)
>> 
>> 
>> As they say, Algol was a great improvement on its successors. ;-)
>
> Algol 60 introduced many great ideas, like block structure and
> BNF syntax description.
>
> Algol 68, with its meta-syntactic definition, served to clarify
> a number of issues in language design, but ultimately confused
> its non-theorist "market".  I really liked the palindromic block
> delimiters though ("do"-"od", "if"-"fi", etc.), and I used them
> for a system implementation language ("proc"-"corp", "case"-"esac",
> "struc"-"curts", etc.).

You have if/fi and case/esac in the Bourne shell too. :)  Looks weird 
though.

> Many years later, I think that the "offside rule" for delimiting
> blocks simply by indentation is a very nice approach.  Why on
> earth should white space, the most significant characteristic of
> text to the human eye, be ignored by most programming languages?

You'd like Python.

-uso.
0
Lyrical
6/3/2006 5:03:28 AM
Den Fri, 02 Jun 2006 21:53:25 -0700 skrev Michael J. Mahon:
>
> Many years later, I think that the "offside rule" for delimiting
> blocks simply by indentation is a very nice approach.  Why on
> earth should white space, the most significant characteristic of
> text to the human eye, be ignored by most programming languages?

For the same reason that comments, the most human readable text found
in a program, are ignored by the programming language. Whitespace is
an important part of making the program more readable.

A programming language that prevents me to use white space to make
code readable (because that would change what the code does) is just
as bad as one that prevents me from writing a comment where needed
(Actually, Visual Basic .NET does that in certain places. Yuck).

/Kent
-- 
Hard work may pay off in the long run, but laziness pays off right now.
0
Kent
6/3/2006 11:38:07 AM
Den 31 May 2006 07:41:06 -0700 skrev mdj:
> Paul Schlyter wrote:
>
>
>> I don't consider that an API, but a library!  An API should provide access
>> to something else but itself.  Such as external hardware, or some other
>> software module.
>
> Fair enough. I consider the terms API and "standard library"
> synonymous, as I'm sure most developers do ....

Just like certain Java-programmers who consider Interface and Class
synonymous... (That's what the I in API means - Interface).

There is the interface and the implementation. The two halves of
a working library.

/Kent
-- 
Hard work may pay off in the long run, but laziness pays off right now.
0
Kent
6/3/2006 11:42:20 AM
In article <4481759c$0$15787$14726298@news.sunsite.dk>,
Kent Friis  <nospam@nospam.invalid> wrote:
>Den 31 May 2006 07:41:06 -0700 skrev mdj:
>> Paul Schlyter wrote:
>>
>>
>>> I don't consider that an API, but a library!  An API should provide access
>>> to something else but itself.  Such as external hardware, or some other
>>> software module.
>>
>> Fair enough. I consider the terms API and "standard library"
>> synonymous, as I'm sure most developers do ....
>
>Just like certain Java-programmers who consider Interface and Class
>synonymous... (That's what the I in API means - Interface).
>
>There is the interface and the implementation. The two halves of
>a working library.

I fully agree with that!  The API is the specification, not the
implementation.  There might be some parts of the library which
can be called by outside code but wasn't intended to be called in
that way - they're not part of the API, even though they're part of
the library!




-- 
----------------------------------------------------------------
Paul Schlyter,  Grev Turegatan 40,  SE-114 38 Stockholm,  SWEDEN
e-mail:  pausch at stockholm dot bostream dot se
WWW:     http://stjarnhimlen.se/
0
pausch
6/3/2006 12:42:55 PM
In article <44809520$0$11067$9b4e6d93@newsread4.arcor-online.net>,
Linards Ticmanis  <ticmanis@gmx.de> wrote:

> Michael J. Mahon wrote:
> 
>> Actually, I believe that _pragma_ was borrowed from Algol 68,
>> which must be the most influential least implemented language.  ;-)
> 
> As they say, Algol was a great improvement on its successors. ;-)

Algo was a great programming language -- as long as your program
didn't have to du any input or any output.  Not having to actually
implement your program was also a clear advantage, considering the
scarcity of Algol compilers.... therefore, Algol was for a long time
used in textbooks as examples of implementing various algorithms.

-- 
----------------------------------------------------------------
Paul Schlyter,  Grev Turegatan 40,  SE-114 38 Stockholm,  SWEDEN
e-mail:  pausch at stockholm dot bostream dot se
WWW:     http://stjarnhimlen.se/
0
pausch
6/3/2006 12:42:55 PM
In article <Pine.LNX.4.64.0606030103360.32465@dosius.ath.cx>,
Lyrical Nanoha  <lyricalnanoha@dosius.ath.cx> wrote:

> On Fri, 2 Jun 2006, Michael J. Mahon wrote:
> 
>> Linards Ticmanis wrote:
>>> Michael J. Mahon wrote:
>>> 
>>>> Actually, I believe that _pragma_ was borrowed from Algol 68,
>>>> which must be the most influential least implemented language.  ;-)
>>> 
>>> 
>>> As they say, Algol was a great improvement on its successors. ;-)
>>
>> Algol 60 introduced many great ideas, like block structure and
>> BNF syntax description.
>>
>> Algol 68, with its meta-syntactic definition, served to clarify
>> a number of issues in language design, but ultimately confused
>> its non-theorist "market".  I really liked the palindromic block
>> delimiters though ("do"-"od", "if"-"fi", etc.), and I used them
>> for a system implementation language ("proc"-"corp", "case"-"esac",
>> "struc"-"curts", etc.).
> 
> You have if/fi and case/esac in the Bourne shell too. :)  Looks weird 
> though.

It didn't look wired rather than weird?  :-)

 
>> Many years later, I think that the "offside rule" for delimiting
>> blocks simply by indentation is a very nice approach.  Why on
>> earth should white space, the most significant characteristic of
>> text to the human eye, be ignored by most programming languages?
> 
> You'd like Python.
> 
> -uso.
-- 
----------------------------------------------------------------
Paul Schlyter,  Grev Turegatan 40,  SE-114 38 Stockholm,  SWEDEN
e-mail:  pausch at stockholm dot bostream dot se
WWW:     http://stjarnhimlen.se/
0
pausch
6/3/2006 12:42:56 PM
In article <z6qdnXs_mfZaiBzZRVn-ig@comcast.com>,
Michael J. Mahon <mjmahon@aol.com> wrote:

> Many years later, I think that the "offside rule" for delimiting
> blocks simply by indentation is a very nice approach.  Why on
> earth should white space, the most significant characteristic of
> text to the human eye, be ignored by most programming languages?
> 
> So the following would be properly "bracketed" by the offside
> rule:
> 
> if condition1
>     or condition2
> then foo
>       blah
>       blah
> else bar
>       blah
> nextstatement
> ...

Chek out the Python language!  It does just that.

-- 
----------------------------------------------------------------
Paul Schlyter,  Grev Turegatan 40,  SE-114 38 Stockholm,  SWEDEN
e-mail:  pausch at stockholm dot bostream dot se
WWW:     http://stjarnhimlen.se/
0
pausch
6/3/2006 12:42:56 PM
In article <4481749f$0$15787$14726298@news.sunsite.dk>,
Kent Friis  <nospam@nospam.invalid> wrote:

> Den Fri, 02 Jun 2006 21:53:25 -0700 skrev Michael J. Mahon:
>
>> Many years later, I think that the "offside rule" for delimiting
>> blocks simply by indentation is a very nice approach.  Why on
>> earth should white space, the most significant characteristic of
>> text to the human eye, be ignored by most programming languages?
> 
> For the same reason that comments, the most human readable text found
> in a program, are ignored by the programming language. Whitespace is
> an important part of making the program more readable.
> 
> A programming language that prevents me to use white space to make
> code readable (because that would change what the code does) is just
> as bad as one that prevents me from writing a comment where needed
> (Actually, Visual Basic .NET does that in certain places. Yuck).

Check out Python - there indentation delimits if blocks.  And I cannot
se any reason why:

   if condition
   statement1
   statement2
   else
   statement3
   statement4
   rest_of_program

is more readable than:

   if condition
      statement1
      statement2
   else
      statement3
      statement4
   rest_of_program

:-)
-- 
----------------------------------------------------------------
Paul Schlyter,  Grev Turegatan 40,  SE-114 38 Stockholm,  SWEDEN
e-mail:  pausch at stockholm dot bostream dot se
WWW:     http://stjarnhimlen.se/
0
pausch
6/3/2006 12:42:56 PM
["Followup-To:" header set to comp.sys.cbm.]
Den Sat, 03 Jun 2006 12:42:56 GMT skrev Paul Schlyter:
> In article <4481749f$0$15787$14726298@news.sunsite.dk>,
> Kent Friis  <nospam@nospam.invalid> wrote:
>
>> Den Fri, 02 Jun 2006 21:53:25 -0700 skrev Michael J. Mahon:
>>
>>> Many years later, I think that the "offside rule" for delimiting
>>> blocks simply by indentation is a very nice approach.  Why on
>>> earth should white space, the most significant characteristic of
>>> text to the human eye, be ignored by most programming languages?
>> 
>> For the same reason that comments, the most human readable text found
>> in a program, are ignored by the programming language. Whitespace is
>> an important part of making the program more readable.
>> 
>> A programming language that prevents me to use white space to make
>> code readable (because that would change what the code does) is just
>> as bad as one that prevents me from writing a comment where needed
>> (Actually, Visual Basic .NET does that in certain places. Yuck).
>
> Check out Python - there indentation delimits if blocks.  And I cannot
> se any reason why:
>
>    if condition
>    statement1
>    statement2
>    else
>    statement3
>    statement4
>    rest_of_program
>
> is more readable than:
>
>    if condition
>       statement1
>       statement2
>    else
>       statement3
>       statement4
>    rest_of_program
>
> :-)

For the same reason that /* aadkfjghaldfjghsdklfgjhasdklguaadfkghj */
is better than being unable to write a comment: Both are stupid examples
of using a thing meant for making things easier for the exact opposite
cause.

Now try to imagine that someone wants to indent code to actually make
it *more readable*, just like someone writing comments to actually
explain what's going on. Then you might see the point.

/Kent
-- 
Hard work may pay off in the long run, but laziness pays off right now.
0
Kent
6/3/2006 4:12:06 PM
Paul Schlyter wrote:

> > Still, this didn't solve the whole problem, as many standard 1.1
> > Applets wouldn't run on Microsofts VM, which unfortunately shipped
> > standard with Windows, making Java look a lot worse than it actually
> > was.
>
> Which explains why Sun later prohibited Microsoft to implement its own JVM.
> That's when Microsoft switched to C#.

Yes. Things have been a lot better since then.

> That's nice!  But it's also a hole in the fairly strict type checking
> in Java.

How so?

> ...well then the choice is easy: do it the most efficient way... :-)
>
> Of course there's some work in ensureing that they way you chose really
> was the most efficient.

There's yet to be any evidence that it's less efficient, and perhaps
some to indicate it's more so.

Anyway when faced with choice these days I go with the most
maintainable way. CPU power is cheap and plentiful.

> > It's still frowned upon, in favour of using a constant plus
> > if/else/switch constructs to do conditional compilation.
>
> That causes a problem: a source line which shouldn't be used in some
> particular environment can also be a syntax error in such an environment.

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.

> 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? 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.

Of course, most good programmers utilise some form of poor-mans
namespacing by prefixing their preprocessor names with something that's
likely to be unique. This illustrates the point that the feature would
be useful.

> Is there a .setName() method too?  If there is, one might be able to
> do quite interesting things with it.... :-)

Heh. Some OO languages implement a 'Pose' facility to allow you to do
this. It's possible to get the same effect in Java, but constructors
make it difficult. Don't get me started on constructors ;-)

> > But then, many people want to treat Java as if it's C++ minus features,
> > rather than the very different language that it is.
>
> These peope are wrong of course.  Java resembles C++ only
> superficially, mostly by having similar syntax.  But the semantics
> under that syntax is quite different, and more resembles
> "strait-jacket languages" like Pascal --- of course with a lot of
> features not available in Pascal.  I usually think of Java as "the
> UCSD Pascal of our times": it has portable object code which must be
> run on a virtual machine.  However, it is object oriented, it is net
> aware, and it is 32-bit rather than 16-bit.  And Java is also a
> subsystem, not a whole OS like UCSD Pascal was.

Straightjacket is a little harsh :-) If we're comparing Java to C++,
it's really C++ that's the straightjacket language, by forcing you to
make all binding decisions at compile time.

Semantically speaking Java is a lot more like Smalltalk than C++. It's
a nice bridge between the dynamic world and the static world.

To me it's more like this: C++ is C, but with stricter type checking,
and object oriented like extensions, staying within the realm of a
static language with no runtime system or typing.

Java is C++ like in syntax, but is underneath a 'real' OO language,
allowing dynamic binding, loading, etc, within a C++ like typing
system. It's actually far more flexible than it first appears, but you
have to think like an OO programmer.

The only time the typing system annoys me is when I want to do
something REALLY OO, with some fairly heavy reflection. The lack of
syntactic sugar in the reflection API is at times most tedious, and
results in code being very hard to read where it should be simple and
concise.

To this day, I don't miss the implicit conversion between integer and
boolean type that C/C++ programs use. This is the only area where
Java's type checking is stricter. Other differences are feature
removals as mentioned previously

Matt

0
mdj
6/4/2006 12:45:13 AM

> Just like certain Java-programmers who consider Interface and Class
> synonymous... (That's what the I in API means - Interface).

:-) I've not met anyone who misses that distinction yet. Although  one
must be careful when using the word Interface within Java as it can be
easily misconstrued - a libraries interface need not use interfaces.

0
mdj
6/4/2006 12:54:19 AM
Paul Schlyter wrote:

> I fully agree with that!  The API is the specification, not the
> implementation.  There might be some parts of the library which
> can be called by outside code but wasn't intended to be called in
> that way - they're not part of the API, even though they're part of
> the library!

Of course, if you use features of a library that aren't part of it's
documented interface you'll eventually be cursed by almost everybody.

Hey, we're almost back on topic, considering this was supposed to be
about 'undocumented opcodes' :-) Of course, my feelings on using
undocumented library calls is much the same as my feelings on
undocumented opcodes. They are very similar problems.

Matt

0
mdj
6/4/2006 1:04:30 AM
Michael J. Mahon wrote:

> Many years later, I think that the "offside rule" for delimiting
> blocks simply by indentation is a very nice approach.  Why on
> earth should white space, the most significant characteristic of
> text to the human eye, be ignored by most programming languages?

Once you bed down the definition of white space, you've committed the
language to a certain aesthetic form quite unnecessarily. People have
been arguing for *years* over such aestheic issues in most programming
languages without any clear consensus. Perhaps one day we'll reach one,
but beauty being in the eye of the beholder I somewhat doubt it :-)

An interesting language in this regard is Ruby, who's syntax is such
that BOTH whitespace or statement delimiters may be used, depending on
what is felt most appropriate to the developer.

Actually the first language I've used seriously where carriage returns
are considered statement terminators and I've not immediately disliked
the language. In fact, Ruby allows some beautifully concise code. The
language is so flexible in fact, that you can override almost any facet
of it, in effect making it very simple to construct domain-specific
languages, or sublanguages, to better suit the problem domain. Lots of
fun.

Matt

0
mdj
6/4/2006 1:13:27 AM
Kent Friis wrote:
> Den Fri, 02 Jun 2006 21:53:25 -0700 skrev Michael J. Mahon:
> 
>>Many years later, I think that the "offside rule" for delimiting
>>blocks simply by indentation is a very nice approach.  Why on
>>earth should white space, the most significant characteristic of
>>text to the human eye, be ignored by most programming languages?
> 
> 
> For the same reason that comments, the most human readable text found
> in a program, are ignored by the programming language. Whitespace is
> an important part of making the program more readable.
> 
> A programming language that prevents me to use white space to make
> code readable (because that would change what the code does) is just
> as bad as one that prevents me from writing a comment where needed
> (Actually, Visual Basic .NET does that in certain places. Yuck).

If you think about it, the same things that make it more readable
to a human can make it more "parsable" by a computer--and you'll
be much less likely to have a piece of code look different from
what it means.

Comments are still fine, and can also be delimited by the off-side
rule in many cases (though that isn't necessary).  A comment should
never repeat the meaning of a statement at the level of the language,
but should, generally, give the meaning of a statement or group of
statements at a higher level of abstraction.

-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."
0
Michael
6/4/2006 8:31:57 AM
Paul Schlyter wrote:
> In article <4481749f$0$15787$14726298@news.sunsite.dk>,
> Kent Friis  <nospam@nospam.invalid> wrote:
> 
> 
>>Den Fri, 02 Jun 2006 21:53:25 -0700 skrev Michael J. Mahon:
>>
>>
>>>Many years later, I think that the "offside rule" for delimiting
>>>blocks simply by indentation is a very nice approach.  Why on
>>>earth should white space, the most significant characteristic of
>>>text to the human eye, be ignored by most programming languages?
>>
>>For the same reason that comments, the most human readable text found
>>in a program, are ignored by the programming language. Whitespace is
>>an important part of making the program more readable.
>>
>>A programming language that prevents me to use white space to make
>>code readable (because that would change what the code does) is just
>>as bad as one that prevents me from writing a comment where needed
>>(Actually, Visual Basic .NET does that in certain places. Yuck).
> 
> 
> Check out Python - there indentation delimits if blocks.  And I cannot
> se any reason why:
> 
>    if condition
>    statement1
>    statement2
>    else
>    statement3
>    statement4
>    rest_of_program
> 
> is more readable than:
> 
>    if condition
>       statement1
>       statement2
>    else
>       statement3
>       statement4
>    rest_of_program
> 
> :-)

Actually, the first statement includes the <rest_of_program> in the
else clause, since there is no delimiter.  That difference is made clear
in the second (off-side delimited) expression.

I'm glad to hear that it has been adopted in a popular language.  ;-)

-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."
0
Michael
6/4/2006 8:35:53 AM
Kent Friis wrote:
> ["Followup-To:" header set to comp.sys.cbm.]
> Den Sat, 03 Jun 2006 12:42:56 GMT skrev Paul Schlyter:
> 
>>In article <4481749f$0$15787$14726298@news.sunsite.dk>,
>>Kent Friis  <nospam@nospam.invalid> wrote:
>>
>>
>>>Den Fri, 02 Jun 2006 21:53:25 -0700 skrev Michael J. Mahon:
>>>
>>>
>>>>Many years later, I think that the "offside rule" for delimiting
>>>>blocks simply by indentation is a very nice approach.  Why on
>>>>earth should white space, the most significant characteristic of
>>>>text to the human eye, be ignored by most programming languages?
>>>
>>>For the same reason that comments, the most human readable text found
>>>in a program, are ignored by the programming language. Whitespace is
>>>an important part of making the program more readable.
>>>
>>>A programming language that prevents me to use white space to make
>>>code readable (because that would change what the code does) is just
>>>as bad as one that prevents me from writing a comment where needed
>>>(Actually, Visual Basic .NET does that in certain places. Yuck).
>>
>>Check out Python - there indentation delimits if blocks.  And I cannot
>>se any reason why:
>>
>>   if condition
>>   statement1
>>   statement2
>>   else
>>   statement3
>>   statement4
>>   rest_of_program
>>
>>is more readable than:
>>
>>   if condition
>>      statement1
>>      statement2
>>   else
>>      statement3
>>      statement4
>>   rest_of_program
>>
>>:-)
> 
> 
> For the same reason that /* aadkfjghaldfjghsdklfgjhasdklguaadfkghj */
> is better than being unable to write a comment: Both are stupid examples
> of using a thing meant for making things easier for the exact opposite
> cause.
> 
> Now try to imagine that someone wants to indent code to actually make
> it *more readable*, just like someone writing comments to actually
> explain what's going on. Then you might see the point.

Again, I see no problem.  The "user indented" code should parse
fine, as long as the statements don't come left of the brackets.

BTW, I also think that 50 lines is a good upper limit for a
procedure, with the only exception being a CASE statement.
(And note that newline and formfeed are fine whitespace characters
and will be interpreted as such wherever spaces could occur.)

-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."
0
Michael
6/4/2006 8:39:59 AM
mdj wrote:
> Michael J. Mahon wrote:
> 
> 
>>Many years later, I think that the "offside rule" for delimiting
>>blocks simply by indentation is a very nice approach.  Why on
>>earth should white space, the most significant characteristic of
>>text to the human eye, be ignored by most programming languages?
> 
> 
> Once you bed down the definition of white space, you've committed the
> language to a certain aesthetic form quite unnecessarily. People have
> been arguing for *years* over such aestheic issues in most programming
> languages without any clear consensus. Perhaps one day we'll reach one,
> but beauty being in the eye of the beholder I somewhat doubt it :-)

It isn't about beauty--it's about clarity.  And there are *huge*
payoffs in adopting a standard format for programs--as, indeed,
most serious projects do.

Not everyone likes to spell words the same way, either, but we
don't care what they think--the convention is king.

With proper rules, a program's beauty when expressed in a language
is *precisely* its evident function.

BTW, programmers shouldn't choose names they "like", either.  Naming
should all be within a simple, rigid framework, so that the semantics
of any name are expressed by the identifier.

The lack of widespread adoption of such a convention is a measure of
the immaturity of programming as a discipline.

> An interesting language in this regard is Ruby, who's syntax is such
> that BOTH whitespace or statement delimiters may be used, depending on
> what is felt most appropriate to the developer.

Most "offside" languages also permit explicit brackets.  They are
especially handy in rendering short lists horizontally, like argument
lists or short conditionals.

> Actually the first language I've used seriously where carriage returns
> are considered statement terminators and I've not immediately disliked
> the language. In fact, Ruby allows some beautifully concise code. The
> language is so flexible in fact, that you can override almost any facet
> of it, in effect making it very simple to construct domain-specific
> languages, or sublanguages, to better suit the problem domain. Lots of
> fun.

Sounds interesting--I'll take a look at Ruby.

-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."
0
Michael
6/4/2006 8:54:53 AM
Paul Schlyter wrote:
> In article <44809520$0$11067$9b4e6d93@newsread4.arcor-online.net>,
> Linards Ticmanis  <ticmanis@gmx.de> wrote:
> 
> 
>>Michael J. Mahon wrote:
>>
>>
>>>Actually, I believe that _pragma_ was borrowed from Algol 68,
>>>which must be the most influential least implemented language.  ;-)
>>
>>As they say, Algol was a great improvement on its successors. ;-)
> 
> 
> Algo was a great programming language -- as long as your program
> didn't have to du any input or any output.  Not having to actually
> implement your program was also a clear advantage, considering the
> scarcity of Algol compilers.... therefore, Algol was for a long time
> used in textbooks as examples of implementing various algorithms.

There was a great (I/O extended) one-and-a-half pass Algol 58 compiler
on the last commercial vacuum tube machine, the Burroughs 220.  It was
a compile-and-go system designed for teaching, but it was both a fast
and an efficient compiler for the time.  It was written entirely in
assembly language, and was the first example of a _virtuoso_ program
I ever saw--and marvelled at.  ;-)

-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."
0
Michael
6/4/2006 8:58:45 AM
mdj wrote:
> Paul Schlyter wrote:

<snip>

>>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? 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.
> 
> Of course, most good programmers utilise some form of poor-mans
> namespacing by prefixing their preprocessor names with something that's
> likely to be unique. This illustrates the point that the feature would
> be useful.

In the "olden days", assemblers frequently had HEAD "x" pseudo ops that
would treat all identifiers encountered from then on as if they had an
"x" prefixed to them, until the next HEAD operation.

This didn't produce any visible change in the labels, but it did serve
to create "local" scopes if the HEAD characters were well chosen.

-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."
0
Michael
6/4/2006 9:03:49 AM
On Sun, 4 Jun 2006, Michael J. Mahon wrote:

<snips here and there>

> It isn't about beauty--it's about clarity.  And there are *huge*
> payoffs in adopting a standard format for programs--as, indeed,
> most serious projects do.

I have a format of my own, which I adopted out of necessity - couldn't 
read my own code when it was all smashed against the left margin!

> Not everyone likes to spell words the same way, either, but we
> don't care what they think--the convention is king.

Of course there is no single convention for C; I use braces on separate 
lines with an indent of 1 space within the braces, and my function headers 
are one line - and there is a minimum of whitespace against the last 
margin but it's fairly readable.

> BTW, programmers shouldn't choose names they "like", either.  Naming
> should all be within a simple, rigid framework, so that the semantics
> of any name are expressed by the identifier.

I use several metasyntactic names for throwaway variables (foo, bar, 
grill; travel, travel2, travel3; i, j, k; x, y, z), but usually it's 
something like "nolin" (number of lines), "curlin" (current line), etc. - 
an abbreviation, since I don't like to type any more than I have to.

-uso.
0
Lyrical
6/4/2006 9:18:45 AM
Lyrical Nanoha wrote:
> On Sun, 4 Jun 2006, Michael J. Mahon wrote:
> 
> <snips here and there>
> 
>> It isn't about beauty--it's about clarity.  And there are *huge*
>> payoffs in adopting a standard format for programs--as, indeed,
>> most serious projects do.
> 
> 
> I have a format of my own, which I adopted out of necessity - couldn't 
> read my own code when it was all smashed against the left margin!

There is an almost universal appreciation of the value of syntax-
oriented formatting.  Of course, essentially all books show examples
of such formatting.

Capricious or misleading (non-syntactic) formatting would be a
disaster--even in a one-person programming team.  ;-)

>> Not everyone likes to spell words the same way, either, but we
>> don't care what they think--the convention is king.
> 
> 
> Of course there is no single convention for C; I use braces on separate 
> lines with an indent of 1 space within the braces, and my function 
> headers are one line - and there is a minimum of whitespace against the 
> last margin but it's fairly readable.

But within a programming project, *someone* will have to define a common
convention for all to use--otherwise, there will be lots of errors, and
design reviews will be a nightmare.  ;-)

>> BTW, programmers shouldn't choose names they "like", either.  Naming
>> should all be within a simple, rigid framework, so that the semantics
>> of any name are expressed by the identifier.
> 
> 
> I use several metasyntactic names for throwaway variables (foo, bar, 
> grill; travel, travel2, travel3; i, j, k; x, y, z), but usually it's 
> something like "nolin" (number of lines), "curlin" (current line), etc. 
> - an abbreviation, since I don't like to type any more than I have to.

For a small namespace, simple schemes can be workable, but for large
namespaces, with many hundreds of identifiers, naming conventions help
keep things straight, avoiding conflicts and, even more importantly,
providing instant recognition to a reader who understands the naming
convention.

-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."
0
Michael
6/4/2006 10:00:09 AM
Michael J. Mahon wrote:
> Lyrical Nanoha wrote:
> > I use several metasyntactic names for throwaway variables (foo, bar,
> > grill; travel, travel2, travel3; i, j, k; x, y, z), but usually it's
> > something like "nolin" (number of lines), "curlin" (current line), etc.
> > - an abbreviation, since I don't like to type any more than I have to.
>
> For a small namespace, simple schemes can be workable, but for large
> namespaces, with many hundreds of identifiers, naming conventions help
> keep things straight, avoiding conflicts and, even more importantly,
> providing instant recognition to a reader who understands the naming
> convention.

Saving keypresses in the way LN describes can really waste brain cycles
elsewhere. Years ago I tired of the proclivity for programmers to
abbreviate into 3 letters even 4 letter words (etc), just to fit a
pattern. Those days are long gone for me, and today's IDEs it's easy
enough to type the first few letters then ctrl-space to complete the
rest.

Using "no" within a variable name is confusing, because as we all know,
no means no. A "Num" suffix is much clearer IMO. As for foo, bar and
other "throwaways", I find there is almost always a better word for
such a temporary variable, otherwise just call it what it is "temp".
This might seem trivial, but like MM says, get a huge project and watch
the "obvious" abbreviations start to collide. Heh, I remember
refactoring someone's code, and having to work out what purpose was
served by the variable
"i_cant_be_bothered_thinking_of_a_f*cking_name_for_this_one". ;-)

Cheers,
Nick.

0
sicklittlemonkey
6/4/2006 11:20:51 AM
Michael J. Mahon wrote:

> It isn't about beauty--it's about clarity.  And there are *huge*
> payoffs in adopting a standard format for programs--as, indeed,
> most serious projects do.
>
> Not everyone likes to spell words the same way, either, but we
> don't care what they think--the convention is king.
>
> With proper rules, a program's beauty when expressed in a language
> is *precisely* its evident function.
>
> BTW, programmers shouldn't choose names they "like", either.  Naming
> should all be within a simple, rigid framework, so that the semantics
> of any name are expressed by the identifier.
>
> The lack of widespread adoption of such a convention is a measure of
> the immaturity of programming as a discipline.

Oh I completely agree. I just think we're a fair number of years away
yet from that level of discipline. A pity.

I hope that eventually we'll be dealing with very high abstraction
levels, perhaps languages with its own symbology rather than being
forced into being expressed in roman character sets, etc. There is a
long, long way to go before such ideals are realised though.
Fortunately, some people are beginning to see the light.

Matt

0
mdj
6/4/2006 1:45:11 PM
sicklittlemonkey wrote:

> Saving keypresses in the way LN describes can really waste brain cycles
> elsewhere. Years ago I tired of the proclivity for programmers to
> abbreviate into 3 letters even 4 letter words (etc), just to fit a
> pattern. Those days are long gone for me, and today's IDEs it's easy
> enough to type the first few letters then ctrl-space to complete the
> rest.

The old formatting 'rule' of not exceeding 80 characters on a line has
finally started to die, along with the terminals that encouraged it,
which has helped things a great deal.

I share your appreciation of IDE's abilities to autocomplete code - the
productivity difference is enormous, but then the mental agility lost
to not remembering API definitions anymore is a bit of a concern.

Matt

0
mdj
6/4/2006 1:49:18 PM
"mdj" <mdj.mdj@gmail.com> wrote in news:1149428711.900916.89960
@g10g2000cwb.googlegroups.com:

> I hope that eventually we'll be dealing with very high abstraction
> levels, perhaps languages with its own symbology rather than being
> forced into being expressed in roman character sets, etc. There is a
> long, long way to go before such ideals are realised though.
> Fortunately, some people are beginning to see the light.
> 
> Matt
> 

Pining for APL are we?

:-)

Dan.

0
Dan
6/4/2006 2:39:43 PM
Dan Lingman wrote:
> "mdj" <mdj.mdj@gmail.com> wrote in news:1149428711.900916.89960
> @g10g2000cwb.googlegroups.com:
> 
> 
>>I hope that eventually we'll be dealing with very high abstraction
>>levels, perhaps languages with its own symbology rather than being
>>forced into being expressed in roman character sets, etc. There is a
>>long, long way to go before such ideals are realised though.
>>Fortunately, some people are beginning to see the light.
>>
>>Matt
>>
> 
> 
> Pining for APL are we?
> 
> :-)

Ah--brevity of expression carried to its limit--often described
as a "write-only language".  ;-)

It is interesting to think of APL as a subject for some advanced
(dynamic) optimization.

It was conceived as a fully interpreted language, encouraging
the use of vector and matrix ops that could produce truly huge
intermediate data structures, just to eventually boil them down
to a scalar.  Later implementations introduced optimizations that
attempted to create some of the larger data structures "lazily"
to save space and time, while leaving the pure algebra of the
source APL intact.

The "near applicative" nature of APLs semantics was quite well suited
to parallel evaluation.  I wonder what modern optimization techniques
and multiprocessor platforms could do with it today--perhaps with some
semantic tweaks to clean things up.

Then there's always that amazing keyboard...  ;-)

-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."
0
Michael
6/4/2006 9:43:45 PM
Michael J. Mahon wrote:

> > Pining for APL are we?
> >
> > :-)
>
> Ah--brevity of expression carried to its limit--often described
> as a "write-only language".  ;-)
>
> It is interesting to think of APL as a subject for some advanced
> (dynamic) optimization.

Yes. Many people tend to feel high level languages are inefficient
because they're too abstract, but I feel they're inefficient because
they're not abstract enough :-)

> The "near applicative" nature of APLs semantics was quite well suited
> to parallel evaluation.  I wonder what modern optimization techniques
> and multiprocessor platforms could do with it today--perhaps with some
> semantic tweaks to clean things up.

I'm very sure we'll end up on a path towards "near applicative"
semantics. I imagine libraries of algorithms rather than 'code' and
compilers that truly understand computational complexity, plus take
full advantage of being able to determine the scope of an object to
distill things into extremely efficient machine representations. Couple
that with runtime instrumentation during development and test, and some
amazing possibilities open up.

These days I tend to write things in Ruby, which gives me SmallTalk
without SmallTalk, LISP without LISP (Ruby has the 'yield' operator
borrowed from CLU), Perl without Perl.

It's a great deal of fun to be able to combine full OO, lambda
calculus, dynamic rewriting of code, and not have to use something like
CLOS. Python has most of the same features, too, but I'm not fond of
its syntax so I found myself in the Ruby camp. It's great to be able to
use a pure OO scripting language and have the execution speed be very
respectable.

Matt

0
mdj
6/5/2006 1:24:28 AM
In article <1149383070.763983.291190@h76g2000cwa.googlegroups.com>,
mdj <mdj.mdj@gmail.com> wrote:

> Paul Schlyter wrote:
> 
>> I fully agree with that!  The API is the specification, not the
>> implementation.  There might be some parts of the library which
>> can be called by outside code but wasn't intended to be called in
>> that way - they're not part of the API, even though they're part of
>> the library!
> 
> Of course, if you use features of a library that aren't part of it's
> documented interface you'll eventually be cursed by almost everybody.
> 
> Hey, we're almost back on topic, considering this was supposed to be
> about 'undocumented opcodes' :-) Of course, my feelings on using
> undocumented library calls is much the same as my feelings on
> undocumented opcodes. They are very similar problems.
> 
> Matt

In the Apple II world we had other similar situations: calling Monitor
ROM routines at some fixed address.  Or calling routines in the Applesoft
Basic ROM's.

-- 
----------------------------------------------------------------
Paul Schlyter,  Grev Turegatan 40,  SE-114 38 Stockholm,  SWEDEN
e-mail:  pausch at stockholm dot bostream dot se
WWW:     http://stjarnhimlen.se/
0
pausch
6/5/2006 3:13:45 PM
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.

>>> It's still frowned upon, in favour of using a constant plus
>>> if/else/switch constructs to do conditional compilation.
>>
>> That causes a problem: a source line which shouldn't be used in some
>> particular environment can also be a syntax error in such an environment.
> 
> 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.

>> 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.

> 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.

I believe the biggest problem here is the mind of those programmers
who don't realize that they're acutally using two different languages
simultaneously when using C (or C++) with macros.  They believe they
program only in C (or C++), without realizing that the preprocessor really
is a language of itself, which obeys different rules.  Line breaks are
for instance insignificant in C and C++ - it's just another kind of
whitespace, nothing more.  But to the preprocessor in C and C++, line breaks
are quite significant since they terminate the preprocessor statement
(unless that line end with the "line continuation character" \).


> Of course, most good programmers utilise some form of poor-mans
> namespacing by prefixing their preprocessor names with something that's
> likely to be unique. This illustrates the point that the feature would
> be useful.

Note that the macros are "global" only over the source file, not over
the entire application.

>>> But then, many people want to treat Java as if it's C++ minus features,
>>> rather than the very different language that it is.
>>
>> These peope are wrong of course.  Java resembles C++ only
>> superficially, mostly by having similar syntax.  But the semantics
>> under that syntax is quite different, and more resembles
>> "strait-jacket languages" like Pascal --- of course with a lot of
>> features not available in Pascal.  I usually think of Java as "the
>> UCSD Pascal of our times": it has portable object code which must be
>> run on a virtual machine.  However, it is object oriented, it is net
>> aware, and it is 32-bit rather than 16-bit.  And Java is also a
>> subsystem, not a whole OS like UCSD Pascal was.
> 
> Straightjacket is a little harsh :-) If we're comparing Java to C++,
> it's really C++ that's the straightjacket language, by forcing you to
> make all binding decisions at compile time.
> 
> 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.
 
> To me it's more like this: C++ is C, but with stricter type checking,
> and object oriented like extensions, staying within the realm of a
> static language with no runtime system or typing.
> 
> Java is C++ like in syntax, but is underneath a 'real' OO language,
> allowing dynamic binding, loading, etc, within a C++ like typing
> system. It's actually far more flexible than it first appears, but you
> have to think like an OO programmer.

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.

But there are ways out of OO in Java too, just wrap your
non-OO-program like this:

class programname
{
    <your non-OO-program, in one single source file, goes here>
}


> The only time the typing system annoys me is when I want to do
> something REALLY OO, with some fairly heavy reflection. The lack of
> syntactic sugar in the reflection API is at times most tedious, and
> results in code being very hard to read where it should be simple and
> concise.
> 
> To this day, I don't miss the implicit conversion between integer and
> boolean type that C/C++ programs use. This is the only area where
> Java's type checking is stricter. Other differences are feature
> removals as mentioned previously
> 
> Matt
-- 
----------------------------------------------------------------
Paul Schlyter,  Grev Turegatan 40,  SE-114 38 Stockholm,  SWEDEN
e-mail:  pausch at stockholm dot bostream dot se
WWW:     http://stjarnhimlen.se/
0
pausch
6/5/2006 3:13:45 PM
In article <gpadnZTfo-dlPB_ZnZ2dnUVZ_qmdnZ2d@comcast.com>,
Michael J. Mahon <mjmahon@aol.com> wrote:

> mdj wrote:
>> Paul Schlyter wrote:
> 
> <snip>
> 
>>>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? 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.
>> 
>> Of course, most good programmers utilise some form of poor-mans
>> namespacing by prefixing their preprocessor names with something that's
>> likely to be unique. This illustrates the point that the feature would
>> be useful.
> 
> In the "olden days", assemblers frequently had HEAD "x" pseudo ops that
> would treat all identifiers encountered from then on as if they had an
> "x" prefixed to them, until the next HEAD operation.
> 
> This didn't produce any visible change in the labels, but it did serve
> to create "local" scopes if the HEAD characters were well chosen.
> 
> -michael

In the Apple II world, the S-C Assembler implemented local labels which
had special names: a dot '.' followed by a decimal number from 0 to 99.
The local labels were visible only between one normal label and the
next -- after next normal label, all local label names could be reused.

-- 
----------------------------------------------------------------
Paul Schlyter,  Grev Turegatan 40,  SE-114 38 Stockholm,  SWEDEN
e-mail:  pausch at stockholm dot bostream dot se
WWW:     http://stjarnhimlen.se/
0
pausch
6/5/2006 3:13:45 PM
In article <1149428957.970012.309990@y43g2000cwc.googlegroups.com>,
mdj <mdj.mdj@gmail.com> wrote:

> sicklittlemonkey wrote:
> 
>> Saving keypresses in the way LN describes can really waste brain cycles
>> elsewhere. Years ago I tired of the proclivity for programmers to
>> abbreviate into 3 letters even 4 letter words (etc), just to fit a
>> pattern. Those days are long gone for me, and today's IDEs it's easy
>> enough to type the first few letters then ctrl-space to complete the
>> rest.
> 
> The old formatting 'rule' of not exceeding 80 characters on a line has
> finally started to die, along with the terminals that encouraged it,
> which has helped things a great deal.

That old formatting rule originated with the 80-column punched cards.
Early terminals more or less mimiced punched cards, and of course the
80-character line limit was more or less hardwired into the terminal.

Some programming languages even had these formatting rules built-in.
In e.g. FORTRAN (up to FORTRAN-77), these rules had to be obeyed:

Column 1:      C or * marked the whole line as a comment
Columns 2-6:   Labels went here - 1-5 decimal digits
Column 7:      A non-space character here marked this line as a contination line
Columns 8-71:  The program statement went here
Columns 72-80: Comment - anything here was ignored by the compiler

If your line happened to be longer than 80 characters (impossible on a
punched card, but quite possible in a text file), the compiler considered
the excess characters to be a new line.

Having a long statement spill over into and beyond column 72 could have
"interesting" side effect: that text was truncated by the compiler.  So if
it was a variable name, that name was truncated.  Did this lead to an
"undefined variable" error?  Oh no -- FORTRAN had implicit variable
declarations, so the compiler merely created a new variable with the truncated
name as variable name.....

> I share your appreciation of IDE's abilities to autocomplete code - the
> productivity difference is enormous, but then the mental agility lost
> to not remembering API definitions anymore is a bit of a concern.
> 
> Matt

-- 
----------------------------------------------------------------
Paul Schlyter,  Grev Turegatan 40,  SE-114 38 Stockholm,  SWEDEN
e-mail:  pausch at stockholm dot bostream dot se
WWW:     http://stjarnhimlen.se/
0
pausch
6/5/2006 3:13:45 PM
Paul Schlyter wrote:

> Some programming languages even had these formatting rules built-in.
> In e.g. FORTRAN (up to FORTRAN-77), these rules had to be obeyed:
> 
> Column 1:      C or * marked the whole line as a comment
> Columns 2-6:   Labels went here - 1-5 decimal digits
> Column 7:      A non-space character here marked this line as a contination line
> Columns 8-71:  The program statement went here
> Columns 72-80: Comment - anything here was ignored by the compiler

Actually, it was:

Column 1-5:    Statement number, or "C" in column 1 for comment lines
Column 6:      Non-blank marks continuation line (often 1-9 to indicate
                sequence of the continuations if more than one)
Columns 7-72:  FORTRAN Statement
Columns 73-80: ID/sequence field, ignored by compiler

The sequence field was often left blank on manually keypunched cards,
but was almost always filled with some combination of a "deck" ID and
a sequence number on machine-punched decks, as were "binary" decks.

I remember many times using an IBM 82 card sorter to restore order
to a deck containing gravity-induced entropy.  ;-)

There is an interesting historical reason for the FORTRAN compiler
to ignore columns 73-80.  FORTRAN was first implemented on the IBM 704
computer, and that machine and its successors, the 709, 7090, 7040,
and 7094, all used a binary card console card reader that read in
"row binary".  Since these machines had 36-bit words, the standard
binary card format was 12 pairs of 36-bit words, read from successive
rows of the card, and therefore covering only the first 72 columns.

As a result, the computer could not read columns 73-80 from the console
card reader, and those columns were already conventionally used for
deck sequence numbers.  FORTRAN merely continued that convention.
And, of course, what the computer could not read, the compiler must
ignore.  ;-)

For example, see:

www.atkielski.com/PDF/data/fortran.pdf

-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."
0
Michael
6/5/2006 7:18:30 PM
Paul Schlyter wrote:
> In article <gpadnZTfo-dlPB_ZnZ2dnUVZ_qmdnZ2d@comcast.com>,
> Michael J. Mahon <mjmahon@aol.com> wrote:
> 
> 
>>mdj wrote:
>>
>>>Paul Schlyter wrote:
>>
>><snip>
>>
>>>>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? 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.
>>>
>>>Of course, most good programmers utilise some form of poor-mans
>>>namespacing by prefixing their preprocessor names with something that's
>>>likely to be unique. This illustrates the point that the feature would
>>>be useful.
>>
>>In the "olden days", assemblers frequently had HEAD "x" pseudo ops that
>>would treat all identifiers encountered from then on as if they had an
>>"x" prefixed to them, until the next HEAD operation.
>>
>>This didn't produce any visible change in the labels, but it did serve
>>to create "local" scopes if the HEAD characters were well chosen.
>>
>>-michael
> 
> 
> In the Apple II world, the S-C Assembler implemented local labels which
> had special names: a dot '.' followed by a decimal number from 0 to 99.
> The local labels were visible only between one normal label and the
> next -- after next normal label, all local label names could be reused.

Yes, this is a common convention for defining the scope of local labels.

Frankly, having used a number of such systems, I prefer having a pseudo
op to explicitly discard local labels, since it allows the occasional
global label to be defined within a local label scope.  (Error exits
and cleanup are often usefully shared between subroutines.)

-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."
0
Michael
6/5/2006 7:21:36 PM
Paul Schlyter wrote:
> In article <1149383070.763983.291190@h76g2000cwa.googlegroups.com>,
> mdj <mdj.mdj@gmail.com> wrote:
> 
> 
>>Paul Schlyter wrote:
>>
>>
>>>I fully agree with that!  The API is the specification, not the
>>>implementation.  There might be some parts of the library which
>>>can be called by outside code but wasn't intended to be called in
>>>that way - they're not part of the API, even though they're part of
>>>the library!
>>
>>Of course, if you use features of a library that aren't part of it's
>>documented interface you'll eventually be cursed by almost everybody.
>>
>>Hey, we're almost back on topic, considering this was supposed to be
>>about 'undocumented opcodes' :-) Of course, my feelings on using
>>undocumented library calls is much the same as my feelings on
>>undocumented opcodes. They are very similar problems.
>>
>>Matt
> 
> 
> In the Apple II world we had other similar situations: calling Monitor
> ROM routines at some fixed address.  Or calling routines in the Applesoft
> Basic ROM's.

And, intrestingly, this also returns us to another earlier theme of this
thread--how widespread use of undocumented features can create a barrier
to the creation of new, improved implementations.

The Apple ROM was not significantly changed until the //e, where much
of the actual code was placed in a bank-switched area.  Much of the F8
region became stubs at documented entry points vectoring to the actual
routines.  Updating the F8 region of the ROM was known to be a minefield
of compatibility issues.

The notion of defining the ROM entry points more architecturally was
not widespread at the time the Apple II was designed, and the impact
of the subsequent loss of control over ROM code became a problem.

(I've always wondered how much "compatibility issues" and how much
"renegotiation issues" factored into the decision to never update
the Applesoft ROMs to fix bugs...)

Later systems used a combination of less documentation and more
complexity to make calls into the middle of ROM less likely.  Still
not an ideal solution, but one well adapted to the Apple II.  ;-)

-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."
0
Michael
6/5/2006 7:41:04 PM
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.


> > 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 th 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!

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.

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...."

> >> 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!

> > 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.

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

> > 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.

> 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 ;-)

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.

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.

Matt

0
mdj
6/6/2006 1:38:32 AM
Michael J. Mahon wrote:

> And, intrestingly, this also returns us to another earlier theme of this
> thread--how widespread use of undocumented features can create a barrier
> to the creation of new, improved implementations.
>
> The Apple ROM was not significantly changed until the //e, where much
> of the actual code was placed in a bank-switched area.  Much of the F8
> region became stubs at documented entry points vectoring to the actual
> routines.  Updating the F8 region of the ROM was known to be a minefield
> of compatibility issues.
>
> The notion of defining the ROM entry points more architecturally was
> not widespread at the time the Apple II was designed, and the impact
> of the subsequent loss of control over ROM code became a problem.

Yeah - I used to think the best approach would've been an additional
softswitch and an extra ROM chip, providing absolute compatibility with
the old AutoStart ROM. Considering the cost of manufacture of the IIe,
it would've been a simpler solution.

That said, the engineers that wrote the IIc and enhanced IIe ROMS (I'm
not much of a fan of the original IIe ROM) did a fantastic job.

The only real issue for me was a hardware issue, in that the IIe and
IIc had a feature that would reenable the ROM on reset, which annoyed
me a great deal. I know it was necessary to implement the warm boot,
but it would have been nice if that hardware feature only worked while
PB0 was active.

> (I've always wondered how much "compatibility issues" and how much
> "renegotiation issues" factored into the decision to never update
> the Applesoft ROMs to fix bugs...)

I never really did understand why they licensed a new BASIC from
Microsoft instead of expanding Integer to include the missing features.

> Later systems used a combination of less documentation and more
> complexity to make calls into the middle of ROM less likely.  Still
> not an ideal solution, but one well adapted to the Apple II.  ;-)

The API based approach used in the IIgs was quite nice, particularly
since it allowed the OS to patch broken ROM code at boot time, although
this in itself caused problems. But then only if one ignored the
explicit directions of Apple to NOT jump to absolute locations in ROM.

But then there were applications that had to be modified to run on
ROM03 IIgs's. Some people never learn ....

0
mdj
6/6/2006 2:18:14 AM
On Mon, 5 Jun 2006, mdj wrote:

> Yeah - I used to think the best approach would've been an additional
> softswitch and an extra ROM chip, providing absolute compatibility with
> the old AutoStart ROM. Considering the cost of manufacture of the IIe,
> it would've been a simpler solution.

If you're only running 48K apps on DOS 3.x that's easy.  Use NEWBASIC 
LOADER from Beagle Basic to load FPBASIC off the 1980 DOS 3.3 System 
Master.  Presto.  Apple ][+ ROM on the LC.

> That said, the engineers that wrote the IIc and enhanced IIe ROMS (I'm
> not much of a fan of the original IIe ROM) did a fantastic job.

I never cared for the 6502 //e ROM either.  Bug city.  Ew.

> I never really did understand why they licensed a new BASIC from
> Microsoft instead of expanding Integer to include the missing features.

Because their own project got bogged down in details...

-uso.
0
Lyrical
6/6/2006 2:40:39 AM
Lyrical Nanoha wrote:

> If you're only running 48K apps on DOS 3.x that's easy.  Use NEWBASIC
> LOADER from Beagle Basic to load FPBASIC off the 1980 DOS 3.3 System
> Master.  Presto.  Apple ][+ ROM on the LC.

Sure - works fine for 48k ... Was also nicer on an original Apple II,
as pressing reset didn't switch out the language card.

In the end it wasn't a big problem - the enhanced ROMS were pretty
compatible.
I always enjoyed the SmartPort concept that emerged to run the UniDisk
3.5. One of the nicest 8-bit I/O interfaces I've seen.

> Because their own project got bogged down in details...

Ok.. Wasn't aware there was a replacement project underway...

0
mdj
6/6/2006 3:06:54 AM
"Paul Schlyter" wrote ...

> In article <1149383070.763983.291190@h76g2000cwa.googlegroups.com>,
> mdj <mdj.mdj@gmail.com> wrote:
>
>> Hey, we're almost back on topic, considering this was supposed to be
>> about 'undocumented opcodes' :-) Of course, my feelings on using
>> undocumented library calls is much the same as my feelings on
>> undocumented opcodes. They are very similar problems.
>
> In the Apple II world we had other similar situations: calling Monitor
> ROM routines at some fixed address.  Or calling routines in the Applesoft
> Basic ROM's.

Programmers in the Commodore world also made extensive use of calling ROM
routines.  But, not all of them were undocumented.  Commodore listed the
entry address for many of the more useful Kernal routines, along with a name
for the routine and a brief description of its function, in the C64
Programmer's Reference Guide.

When the C128 came along, Commodore also documented Kernal calls for that
machine in the C128 PRG.
-- 
Best regards,

Sam Gillett

Change is inevitable,
except from vending machines!



0
Sam
6/6/2006 4:50:10 AM
mdj wrote:
> 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.

Exactly. One reason I'm very happy to be out of the C++ world (for now)
is that there wasn't much support for 'compile-time debugging'! And it
was sorely needed when includes reached a critical mass. Debugging with
preprocessor directives doesn't really cut it.

Cheers,
Nick.

0
sicklittlemonkey
6/6/2006 6:16:30 AM
mdj wrote:
> Michael J. Mahon wrote:
> 
> 
>>And, intrestingly, this also returns us to another earlier theme of this
>>thread--how widespread use of undocumented features can create a barrier
>>to the creation of new, improved implementations.
>>
>>The Apple ROM was not significantly changed until the //e, where much
>>of the actual code was placed in a bank-switched area.  Much of the F8
>>region became stubs at documented entry points vectoring to the actual
>>routines.  Updating the F8 region of the ROM was known to be a minefield
>>of compatibility issues.
>>
>>The notion of defining the ROM entry points more architecturally was
>>not widespread at the time the Apple II was designed, and the impact
>>of the subsequent loss of control over ROM code became a problem.
> 
> 
> Yeah - I used to think the best approach would've been an additional
> softswitch and an extra ROM chip, providing absolute compatibility with
> the old AutoStart ROM. Considering the cost of manufacture of the IIe,
> it would've been a simpler solution.
> 
> That said, the engineers that wrote the IIc and enhanced IIe ROMS (I'm
> not much of a fan of the original IIe ROM) did a fantastic job.

I agree--it's remarkable how much original behavior they preserved
while making some really fundamental improvements.

> The only real issue for me was a hardware issue, in that the IIe and
> IIc had a feature that would reenable the ROM on reset, which annoyed
> me a great deal. I know it was necessary to implement the warm boot,
> but it would have been nice if that hardware feature only worked while
> PB0 was active.

I expect the issue was deference to copy protection.  They had to keep
control of the RESET vector to ensure that it was at least "hard" to
break out of a game with all its memory intact.

This did interfere with some straightforward approaches to user-friendly
systems, however.

>>(I've always wondered how much "compatibility issues" and how much
>>"renegotiation issues" factored into the decision to never update
>>the Applesoft ROMs to fix bugs...)
> 
> 
> I never really did understand why they licensed a new BASIC from
> Microsoft instead of expanding Integer to include the missing features.

It's clear that Woz had considered FP, since he had already written the
routines.

It was probably a case of time pressure, the fact that realistically
only Woz could make such a modification to Integer BASIC, and he was
busy with other needed improvements (like Disk ][).  Couple that
pressure with the _de facto_ success of Microsoft BASIC in the
marketplace and things shake out the way they did.

>>Later systems used a combination of less documentation and more
>>complexity to make calls into the middle of ROM less likely.  Still
>>not an ideal solution, but one well adapted to the Apple II.  ;-)
> 
> 
> The API based approach used in the IIgs was quite nice, particularly
> since it allowed the OS to patch broken ROM code at boot time, although
> this in itself caused problems. But then only if one ignored the
> explicit directions of Apple to NOT jump to absolute locations in ROM.
> 
> But then there were applications that had to be modified to run on
> ROM03 IIgs's. Some people never learn ....

In fact, some people prided themselves in programming "to the metal"...

-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."
0
Michael
6/6/2006 7:54:03 AM
Sam Gillett wrote:
> "Paul Schlyter" wrote ...
> 
> 
>>In article <1149383070.763983.291190@h76g2000cwa.googlegroups.com>,
>>mdj <mdj.mdj@gmail.com> wrote:
>>
>>
>>>Hey, we're almost back on topic, considering this was supposed to be
>>>about 'undocumented opcodes' :-) Of course, my feelings on using
>>>undocumented library calls is much the same as my feelings on
>>>undocumented opcodes. They are very similar problems.
>>
>>In the Apple II world we had other similar situations: calling Monitor
>>ROM routines at some fixed address.  Or calling routines in the Applesoft
>>Basic ROM's.
> 
> 
> Programmers in the Commodore world also made extensive use of calling ROM
> routines.  But, not all of them were undocumented.  Commodore listed the
> entry address for many of the more useful Kernal routines, along with a name
> for the routine and a brief description of its function, in the C64
> Programmer's Reference Guide.
> 
> When the C128 came along, Commodore also documented Kernal calls for that
> machine in the C128 PRG.

The Apple II manual documented a couple of dozen monitor routines also,
but since the ROM listing was provided, many called other entry points.

-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."
0
Michael
6/6/2006 7:57:32 AM
In article <S6mdnYNMG-caHhnZnZ2dnUVZ_vidnZ2d@comcast.com>,
Michael J. Mahon <mjmahon@aol.com> wrote:

> Paul Schlyter wrote:
> 
>> Some programming languages even had these formatting rules built-in.
>> In e.g. FORTRAN (up to FORTRAN-77), these rules had to be obeyed:
>> 
>> Column 1:      C or * marked the whole line as a comment
>> Columns 2-6:   Labels went here - 1-5 decimal digits
>> Column 7:      A non-space character here marked this line as a contination line
>> Columns 8-71:  The program statement went here
>> Columns 72-80: Comment - anything here was ignored by the compiler
> 
> Actually, it was:
> 
> Column 1-5:    Statement number, or "C" in column 1 for comment lines
> Column 6:      Non-blank marks continuation line (often 1-9 to indicate
>                 sequence of the continuations if more than one)
> Columns 7-72:  FORTRAN Statement
> Columns 73-80: ID/sequence field, ignored by compiler

Thanks for the correction.  Yep, my fortran skills are getting rusty -- it's some
20 years since I last coded in that language.

 
> The sequence field was often left blank on manually keypunched cards,
> but was almost always filled with some combination of a "deck" ID and
> a sequence number on machine-punched decks, as were "binary" decks.
> 
> I remember many times using an IBM 82 card sorter to restore order
> to a deck containing gravity-induced entropy.  ;-)
> 
> There is an interesting historical reason for the FORTRAN compiler
> to ignore columns 73-80.  FORTRAN was first implemented on the IBM 704
> computer, and that machine and its successors, the 709, 7090, 7040,
> and 7094, all used a binary card console card reader that read in
> "row binary".  Since these machines had 36-bit words, the standard
> binary card format was 12 pairs of 36-bit words, read from successive
> rows of the card, and therefore covering only the first 72 columns.
> 
> As a result, the computer could not read columns 73-80 from the console
> card reader, and those columns were already conventionally used for
> deck sequence numbers.  FORTRAN merely continued that convention.
> And, of course, what the computer could not read, the compiler must
> ignore.  ;-)
> 
> For example, see:
> 
> www.atkielski.com/PDF/data/fortran.pdf
> 
> -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."
> 
> 
> 
> 
-- 
----------------------------------------------------------------
Paul Schlyter,  Grev Turegatan 40,  SE-114 38 Stockholm,  SWEDEN
e-mail:  pausch at stockholm dot bostream dot se
WWW:     http://stjarnhimlen.se/
0
pausch
6/6/2006 9:42:47 AM
In article <GfqdnShMo7JOFRnZnZ2dnUVZ_tKdnZ2d@comcast.com>,
Michael J. Mahon <mjmahon@aol.com> wrote:

> Paul Schlyter wrote:
>> In article <1149383070.763983.291190@h76g2000cwa.googlegroups.com>,
>> mdj <mdj.mdj@gmail.com> wrote:
>> 
>> 
>>>Paul Schlyter wrote:
>>>
>>>
>>>>I fully agree with that!  The API is the specification, not the
>>>>implementation.  There might be some parts of the library which
>>>>can be called by outside code but wasn't intended to be called in
>>>>that way - they're not part of the API, even though they're part of
>>>>the library!
>>>
>>>Of course, if you use features of a library that aren't part of it's
>>>documented interface you'll eventually be cursed by almost everybody.
>>>
>>>Hey, we're almost back on topic, considering this was supposed to be
>>>about 'undocumented opcodes' :-) Of course, my feelings on using
>>>undocumented library calls is much the same as my feelings on
>>>undocumented opcodes. They are very similar problems.
>> 
>> In the Apple II world we had other similar situations: calling Monitor
>> ROM routines at some fixed address.  Or calling routines in the Applesoft
>> Basic ROM's.
> 
> And, intrestingly, this also returns us to another earlier theme of this
> thread--how widespread use of undocumented features can create a barrier
> to the creation of new, improved implementations.
> 
> The Apple ROM was not significantly changed until the //e, where much
> of the actual code was placed in a bank-switched area.  Much of the F8
> region became stubs at documented entry points vectoring to the actual
> routines.  Updating the F8 region of the ROM was known to be a minefield
> of compatibility issues.
> 
> The notion of defining the ROM entry points more architecturally was
> not widespread at the time the Apple II was designed, and the impact
> of the subsequent loss of control over ROM code became a problem.
> 
> (I've always wondered how much "compatibility issues" and how much
> "renegotiation issues" factored into the decision to never update
> the Applesoft ROMs to fix bugs...)
> 
> Later systems used a combination of less documentation and more
> complexity to make calls into the middle of ROM less likely.  Still
> not an ideal solution, but one well adapted to the Apple II.  ;-)
> 
> -michael

IBM learnt from these mistakes by providing entry points to their ROM
BIOS in another way: instead of using fixed addresses, they reserved
16 of the 256 possible interrupts as documented entry points for the
ROM BIOS.  Early PC's came with as much technical documentation as
the Apple II did, including full schematics and assembly source code
listing of the ROM BIOS.

Using soft interrupts as entry points on the Apple II would have been
infeasible -- but Apple could have used a JMP table instead, positioned
near the beginning or the end of the ROM address space.  CP/M used that
method for entry points to its BIOS: a series of JMP operations at the
very beginning of the memory block used by the CP/M BIOS.

-- 
----------------------------------------------------------------
Paul Schlyter,  Grev Turegatan 40,  SE-114 38 Stockholm,  SWEDEN
e-mail:  pausch at stockholm dot bostream dot se
WWW:     http://stjarnhimlen.se/
0
pausch
6/6/2006 9:42:47 AM
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/
0
pausch
6/6/2006 9:42:47 AM
In article <1149560293.988918.82200@y43g2000cwc.googlegroups.com>,
mdj <mdj.mdj@gmail.com> wrote:

> Michael J. Mahon wrote:
..............
>> (I've always wondered how much "compatibility issues" and how much
>> "renegotiation issues" factored into the decision to never update
>> the Applesoft ROMs to fix bugs...)
> 
> I never really did understand why they licensed a new BASIC from
> Microsoft instead of expanding Integer to include the missing features.

Maybe Wozniak didn't have the time needed to do this?  Wasn't he busy
with the disk hardware and Apple DOS 3.1 around then?  So to not fall
behind Commodore PET, Apple bought its Basic from Microsoft.

-- 
----------------------------------------------------------------
Paul Schlyter,  Grev Turegatan 40,  SE-114 38 Stockholm,  SWEDEN
e-mail:  pausch at stockholm dot bostream dot se
WWW:     http://stjarnhimlen.se/
0
pausch
6/6/2006 9:42:47 AM
In article <Pine.LNX.4.64.0606052238350.11213@dosius.ath.cx>,
Lyrical Nanoha  <lyricalnanoha@dosius.ath.cx> wrote:

> On Mon, 5 Jun 2006, mdj wrote:
> 
>> Yeah - I used to think the best approach would've been an additional
>> softswitch and an extra ROM chip, providing absolute compatibility with
>> the old AutoStart ROM. Considering the cost of manufacture of the IIe,
>> it would've been a simpler solution.
> 
> If you're only running 48K apps on DOS 3.x that's easy.  Use NEWBASIC 
> LOADER from Beagle Basic to load FPBASIC off the 1980 DOS 3.3 System 
> Master.  Presto.  Apple ][+ ROM on the LC.

You don't need to use that product to accomplish that.  A few lines in
INTEGER BASIC will accomplish the same thing:

1. Set the soft switches of the LC so that reading is done from ROM
   and writing is done to RAM.

2. Next, BLOAD the FPBASIC file

3. Presto.  Apple ][+ ROM on the LC
 
>> That said, the engineers that wrote the IIc and enhanced IIe ROMS (I'm
>> not much of a fan of the original IIe ROM) did a fantastic job.
> 
> I never cared for the 6502 //e ROM either.  Bug city.  Ew.
> 
>> I never really did understand why they licensed a new BASIC from
>> Microsoft instead of expanding Integer to include the missing features.
> 
> Because their own project got bogged down in details...
> 
> -uso.
-- 
----------------------------------------------------------------
Paul Schlyter,  Grev Turegatan 40,  SE-114 38 Stockholm,  SWEDEN
e-mail:  pausch at stockholm dot bostream dot se
WWW:     http://stjarnhimlen.se/
0
pausch
6/6/2006 9:42:47 AM
Paul Schlyter wrote:

> 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.

You can, thanks to autoboxing. What's actually going on is this:

void foo(Obect j ...) {}

is in reality

void foo(Object[] j)

if you then call foo with primitives, what actually happens is this:

int x = 1; int y = 2;

foo(x, y) actually translates to

foo({new Integer(x), new Integer(y)});

(Syntax might not be exact, I don't use the varargs myself that often,
and couldn't be bothered looking it up. but you get the point)

> 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...

Indeed. If you have a large application that's already written to a
standard that allows it to be portable, you keep maintaining it until
end of life. Unless the language it's written in becomes end of life
first :-)

My concern is the manner in which small libraries or copy/paste chunks
of code pollute the relatively portable space of newer languages. In
..NET, you can issue a keyword and switch into old-school mode. It
doesn't exactly provide an environment that encourages good design. Why
you would include features that good developers won't use is beyond me,
unless of course it's lousy developers you're catering to, which may
well be the point.

> 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.....

It's actually irrelevant what sector we speak of - productivity
enhancements are productivity enhancements. While there are sectors
where you can 'afford' the extra time investment required to develop in
legacy languages, there's little reason to do so.

> 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.

In this case, the old wheel has humps and bumps with regards to
portability and security. Should we throw those away? Absolutely.

> > 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....

Of course, but when your platform isn't evolving you don't need
evolving development methodologies. The older techniques are adequate,
and in the case of the Apple II, a great deal of fun on such a
constrained environment. However, old techniques only scale so high,
and hit those limits. In the case of C/C++, those limits have been hit,
or close to it. There's still a large problem domain you use these
tools for, as it's the most appropriate. But many new problem domains
demand tools that have less restrictions, particularly in terms of
development time. Sometimes this involves using a slightly more
constrained language. Less is more!

> 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....

This is precisely why it is advocated that constants, plus language
constructs be used for conditional compilation.

> 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:

Sure. Eventually you reach the point where the manual on good coding
convention and style is larger than the language specification. At that
point, it's time to rethink, and use more appropriate tools.

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

Yeah, and Java VM's as well :-(

> Are you trying to say one can do something in C that cannot be done in C++ ?  :-)

:-) No, just that C++ style OO is 'broken'

But for the sake of being anal and including yet another example:

int x = 1;
void *p = &x;
int *i = p;
printf("The number was %d ", *i);

Won't work 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>

unsigned types have error prone issues when casting from signed to
unsigned types of the same size in C/C++, as no conversion takes place.
You lose a little space efficiency without them but little else.

The case for operator overloading has been argued over and over.
Originally, it was argued that they unnecessarily complicated the
language, and the number of legitimate use cases for them is relatively
small. I tend to agree that the feature is overused in C++, but I don't
think that justifies removing it.

Many features originally left out have made appearances recently, and
it's likely to continue. I'd expect to see operator overloading appear.

Matt

0
mdj
6/6/2006 10:45:10 AM
Paul Schlyter wrote:
> In article <S6mdnYNMG-caHhnZnZ2dnUVZ_vidnZ2d@comcast.com>,
> Michael J. Mahon <mjmahon@aol.com> wrote:
> 
>> Paul Schlyter wrote:
>>
>>> Some programming languages even had these formatting rules built-in.
>>> In e.g. FORTRAN (up to FORTRAN-77), these rules had to be obeyed:
>>>
>>> Column 1:      C or * marked the whole line as a comment
>>> Columns 2-6:   Labels went here - 1-5 decimal digits
>>> Column 7:      A non-space character here marked this line as a contination line
>>> Columns 8-71:  The program statement went here
>>> Columns 72-80: Comment - anything here was ignored by the compiler
>> Actually, it was:
>>
>> Column 1-5:    Statement number, or "C" in column 1 for comment lines
>> Column 6:      Non-blank marks continuation line (often 1-9 to indicate
>>                 sequence of the continuations if more than one)
>> Columns 7-72:  FORTRAN Statement
>> Columns 73-80: ID/sequence field, ignored by compiler
> 
> Thanks for the correction.  Yep, my fortran skills are getting rusty -- it's some
> 20 years since I last coded in that language.
>

If you think you are rusty, its been 45 years for me and on an IBM 7094 
mentioned below.  And just think that was state of the art then.  It was 
fun getting the back together if you were clumsy and dropped it. 
Speaking from experience :-).

>  
>> The sequence field was often left blank on manually keypunched cards,
>> but was almost always filled with some combination of a "deck" ID and
>> a sequence number on machine-punched decks, as were "binary" decks.
>>
>> I remember many times using an IBM 82 card sorter to restore order
>> to a deck containing gravity-induced entropy.  ;-)
>>
>> There is an interesting historical reason for the FORTRAN compiler
>> to ignore columns 73-80.  FORTRAN was first implemented on the IBM 704
>> computer, and that machine and its successors, the 709, 7090, 7040,
>> and 7094, all used a binary card console card reader that read in
>> "row binary".  Since these machines had 36-bit words, the standard
>> binary card format was 12 pairs of 36-bit words, read from successive
>> rows of the card, and therefore covering only the first 72 columns.
>>
>> As a result, the computer could not read columns 73-80 from the console
>> card reader, and those columns were already conventionally used for
>> deck sequence numbers.  FORTRAN merely continued that convention.
>> And, of course, what the computer could not read, the compiler must
>> ignore.  ;-)
>>
>> For example, see:
>>
>> www.atkielski.com/PDF/data/fortran.pdf
>>
>> -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."
>>
>>
>>
>>
0
fred
6/6/2006 5:15:49 PM
mdj wrote:
> Paul Schlyter wrote:

<snip>

> My concern is the manner in which small libraries or copy/paste chunks
> of code pollute the relatively portable space of newer languages. In
> ..NET, you can issue a keyword and switch into old-school mode. It
> doesn't exactly provide an environment that encourages good design. Why
> you would include features that good developers won't use is beyond me,
> unless of course it's lousy developers you're catering to, which may
> well be the point.
> 
> 
>>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.....
> 
> 
> It's actually irrelevant what sector we speak of - productivity
> enhancements are productivity enhancements. While there are sectors
> where you can 'afford' the extra time investment required to develop in
> legacy languages, there's little reason to do so.

The previous exchange neglects to make the important distinction between
time spent "up front" on design and implementation, and time spent
"after the fact" on support and maintenance.

It is a sad but inescapable fact of commercial life that there is never
time to do a job right, but always time to try to make it work.

One of my development laws is:  "'Quick and dirty' is never quick but
always dirty."

The commercial pressure to get a product out the door that Paul refers
to is so real that it generally precludes the design and implementation
team from doing what they would do in the "best of all possible worlds"
and instead condemns them to shipping a product that has many structual
flaws.  Those flaws will cost dearly over the next few years, but, given
the structure of corporate software teams, it is unlikely that senior
team members will have to deal with much of the flak.

Management will be rewarded for "making the schedule" and the elevated
support costs won't hit the fan until months later--when they can be
blamed on an inexperienced implementation team.

Matt is making a idealistic argument for what is achievable with great
discipline--and there's nothing wrong with that!  But in the "real
world", discipline is much harder to come by, and almost impossible to
stick to without (rare) management support.

>>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.
> 
> 
> In this case, the old wheel has humps and bumps with regards to
> portability and security. Should we throw those away? Absolutely.

Never assume that doing something over will mean doing it better.
Life is full of counterexamples.

It will only be done better if a higher quality design and
implementation can be done, and that's a big "if".  For one thing,
management always thinks of the bad old solution as a _solution_,
so they are unwilling to invest much time and effort in re-solving
a problem "just" to obtain some "airy-fairy benefit" on the *next*
manager's watch...  ;-(

>>>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.

Many of the short-sighted additions to otherwise clean languages are
there *exactly* to solve short-term, schedule-driven problems.

We have a long history as a species of mortgaging the future for the
present.  Whoever said "Pay me now or pay me later" neglected to
mention the effect of high interest rates.  ;-)

As I often say, we tend to use our nose for a wall detector.  It works
very well in the sense that it detects all the walls, but by the time
it works, many of the wall's consequences are already felt.  ;-)

>>>"Those who cannot learn from history are doomed to repeat it...."

And, statistically, that would be all of us...  ;-)

>>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....
> 
> 
> Of course, but when your platform isn't evolving you don't need
> evolving development methodologies. The older techniques are adequate,
> and in the case of the Apple II, a great deal of fun on such a
> constrained environment. However, old techniques only scale so high,
> and hit those limits. In the case of C/C++, those limits have been hit,
> or close to it. There's still a large problem domain you use these
> tools for, as it's the most appropriate. But many new problem domains
> demand tools that have less restrictions, particularly in terms of
> development time. Sometimes this involves using a slightly more
> constrained language. Less is more!

Software folks are more likely to be afflicted with grandiosity than
hardware folks.  Perhaps its the stronger engineering discipline of
the hardware world, perhaps its the real smoke when something "blows
up", or perhaps its because hardware people live *constantly* with
constricting limits that discipline their dreams.

Software folks seldom experience real limits anymore.  They find it
all too easy to imagine that they can accomplish *anything* through
programming (even if they don't understand how to do it  ;-).

Most of the problems of todays software are a result of attempting to
deal with more complexity than we can actually manage--and on a short
schedule.  ;-)  The irony is that much of the complexity comes from
aspects of "solutions" that are entirely optional--like GUI eye candy.

<fogeymode>

Most of what is done with computers today is much like what was done
decades ago--text editing and formatting, modest number crunching.
Only now, instead of spending 20 minutes choosing your words when
writing a letter, you spend 10 minutes writing and 10 minutes choosing
fonts.  ;-)

High quality image processing is relatively new, because of its demand
for large memories and fast processors, but the basic image processing
operations are purely mathematical and easily disciplined.  The same is
true for most "media" processing.

Pasting databases together over the web is an example of an emergent
capability, but one that is largely done using scripting languages.

Sometimes it's hard to see just what real value is being created in
this endless hierarchy of levels of interpretation.  If anything
turns out to be really useful, then it could be rewritten "flatter"
to save about a factor of 1000 in computing resources!

Maybe in computers, too, power corrupts.  ;-)

</fogeymode>

-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."
0
Michael
6/6/2006 5:25:38 PM
Paul Schlyter wrote:
> In article <GfqdnShMo7JOFRnZnZ2dnUVZ_tKdnZ2d@comcast.com>,
> Michael J. Mahon <mjmahon@aol.com> wrote:
> 
> 
>>Paul Schlyter wrote:
>>
>>>In article <1149383070.763983.291190@h76g2000cwa.googlegroups.com>,
>>>mdj <mdj.mdj@gmail.com> wrote:
>>>
>>>
>>>
>>>>Paul Schlyter wrote:
>>>>
>>>>
>>>>
>>>>>I fully agree with that!  The API is the specification, not the
>>>>>implementation.  There might be some parts of the library which
>>>>>can be called by outside code but wasn't intended to be called in
>>>>>that way - they're not part of the API, even though they're part of
>>>>>the library!
>>>>
>>>>Of course, if you use features of a library that aren't part of it's
>>>>documented interface you'll eventually be cursed by almost everybody.
>>>>
>>>>Hey, we're almost back on topic, considering this was supposed to be
>>>>about 'undocumented opcodes' :-) Of course, my feelings on using
>>>>undocumented library calls is much the same as my feelings on
>>>>undocumented opcodes. They are very similar problems.
>>>
>>>In the Apple II world we had other similar situations: calling Monitor
>>>ROM routines at some fixed address.  Or calling routines in the Applesoft
>>>Basic ROM's.
>>
>>And, intrestingly, this also returns us to another earlier theme of this
>>thread--how widespread use of undocumented features can create a barrier
>>to the creation of new, improved implementations.
>>
>>The Apple ROM was not significantly changed until the //e, where much
>>of the actual code was placed in a bank-switched area.  Much of the F8
>>region became stubs at documented entry points vectoring to the actual
>>routines.  Updating the F8 region of the ROM was known to be a minefield
>>of compatibility issues.
>>
>>The notion of defining the ROM entry points more architecturally was
>>not widespread at the time the Apple II was designed, and the impact
>>of the subsequent loss of control over ROM code became a problem.
>>
>>(I've always wondered how much "compatibility issues" and how much
>>"renegotiation issues" factored into the decision to never update
>>the Applesoft ROMs to fix bugs...)
>>
>>Later systems used a combination of less documentation and more
>>complexity to make calls into the middle of ROM less likely.  Still
>>not an ideal solution, but one well adapted to the Apple II.  ;-)
>>
>>-michael
> 
> 
> IBM learnt from these mistakes by providing entry points to their ROM
> BIOS in another way: instead of using fixed addresses, they reserved
> 16 of the 256 possible interrupts as documented entry points for the
> ROM BIOS.  Early PC's came with as much technical documentation as
> the Apple II did, including full schematics and assembly source code
> listing of the ROM BIOS.
> 
> Using soft interrupts as entry points on the Apple II would have been
> infeasible -- but Apple could have used a JMP table instead, positioned
> near the beginning or the end of the ROM address space.  CP/M used that
> method for entry points to its BIOS: a series of JMP operations at the
> very beginning of the memory block used by the CP/M BIOS.

Yes, but that would have used 3 bytes for each entry point--a
non-negligible amount of ROM for a 2KB monitor!

In retrospect, it would have been a nice idea, but doing it in the
original Apple II would have cost capability.  Even adding autostart
required step and trace to be removed.

-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."
0
Michael
6/6/2006 5:31:42 PM
Paul Schlyter wrote:

> IBM learnt from these mistakes by providing entry points to their ROM
> BIOS in another way: instead of using fixed addresses, they reserved
> 16 of the 256 possible interrupts as documented entry points for the
> ROM BIOS.  Early PC's came with as much technical documentation as
> the Apple II did, including full schematics and assembly source code
> listing of the ROM BIOS.
> 
> Using soft interrupts as entry points on the Apple II would have been
> infeasible -- but Apple could have used a JMP table instead, positioned
> near the beginning or the end of the ROM address space. 

....just like Commodore did since the first PET model.

0
Peter
6/6/2006 5:47:46 PM
fred mueller wrote:
> Paul Schlyter wrote:
> 
>> In article <S6mdnYNMG-caHhnZnZ2dnUVZ_vidnZ2d@comcast.com>,
>> Michael J. Mahon <mjmahon@aol.com> wrote:
>>
>>> Paul Schlyter wrote:
>>>
>>>> Some programming languages even had these formatting rules built-in.
>>>> In e.g. FORTRAN (up to FORTRAN-77), these rules had to be obeyed:
>>>>
>>>> Column 1:      C or * marked the whole line as a comment
>>>> Columns 2-6:   Labels went here - 1-5 decimal digits
>>>> Column 7:      A non-space character here marked this line as a 
>>>> contination line
>>>> Columns 8-71:  The program statement went here
>>>> Columns 72-80: Comment - anything here was ignored by the compiler
>>>
>>> Actually, it was:
>>>
>>> Column 1-5:    Statement number, or "C" in column 1 for comment lines
>>> Column 6:      Non-blank marks continuation line (often 1-9 to indicate
>>>                 sequence of the continuations if more than one)
>>> Columns 7-72:  FORTRAN Statement
>>> Columns 73-80: ID/sequence field, ignored by compiler
>>
>>
>> Thanks for the correction.  Yep, my fortran skills are getting rusty 
>> -- it's some
>> 20 years since I last coded in that language.
>>
> 
> If you think you are rusty, its been 45 years for me and on an IBM 7094 
> mentioned below.  And just think that was state of the art then.  It was 
> fun getting the back together if you were clumsy and dropped it. 
> Speaking from experience :-).
> 
>>  
>>
>>> The sequence field was often left blank on manually keypunched cards,
>>> but was almost always filled with some combination of a "deck" ID and
>>> a sequence number on machine-punched decks, as were "binary" decks.
>>>
>>> I remember many times using an IBM 82 card sorter to restore order
>>> to a deck containing gravity-induced entropy.  ;-)

I think most people who used punched cards had the experience of
dropping a deck at one time or another!  And if it wasn't a dropped
deck, it was a reader jam and subsequent imperfect recovery.

I habitually used a Magic Marker to make a diagonal stripe across the
top of my deck after making any changes, using different colors and
locations for the stripes over time.  That is a very simple way to
"sequence" a deck, and provides instant visual verification that the
cards are in the intended order.

-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."
0
Michael
6/6/2006 5:51:52 PM
In article <1149590709.940712.268140@h76g2000cwa.googlegroups.com>,
mdj <mdj.mdj@gmail.com> wrote:

> Paul Schlyter wrote:
>
>> 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...
> 
> Indeed. If you have a large application that's already written to a
> standard that allows it to be portable, you keep maintaining it until
> end of life. Unless the language it's written in becomes end of life
> first :-)

If the application is important, and if it's too expensive to port to
a new environment, it would be feasible to maintain an old environment
(either physically or through emulation) just to be able to run that
application.

> My concern is the manner in which small libraries or copy/paste chunks
> of code pollute the relatively portable space of newer languages. In
> .NET, you can issue a keyword and switch into old-school mode. It
> doesn't exactly provide an environment that encourages good design. Why
> you would include features that good developers won't use is beyond me,
> unless of course it's lousy developers you're catering to, which may
> well be the point.

The point isn't whether the developers are lousy or good - the point
(to the management) is whether one can get the product out the door
more quickly.  Pasting old code in old-school mode is often quicker
than reimplementing the old code in new-school mode.  That's what
matters in a commercial situation: to meet the deadline - a deadline
which often is quite tight because your company won the contract over
its competitors.  Basically it's about promising amost more than you
can keep later.

>> 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.....
> 
> It's actually irrelevant what sector we speak of - productivity
> enhancements are productivity enhancements. While there are sectors
> where you can 'afford' the extra time investment required to develop in
> legacy languages, there's little reason to do so.
> 
>> 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.
> 
> In this case, the old wheel has humps and bumps with regards to
> portability and security. Should we throw those away? Absolutely.
> 
>>> 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....
> 
> Of course, but when your platform isn't evolving you don't need
> evolving development methodologies. The older techniques are adequate,
> and in the case of the Apple II, a great deal of fun on such a
> constrained environment. However, old techniques only scale so high,
> and hit those limits. In the case of C/C++, those limits have been hit,
> or close to it. There's still a large problem domain you use these
> tools for, as it's the most appropriate. But many new problem domains
> demand tools that have less restrictions, particularly in terms of
> development time. Sometimes this involves using a slightly more
> constrained language. Less is more!
> 
>> 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....
> 
> This is precisely why it is advocated that constants, plus language
> constructs be used for conditional compilation.

Then you'll have to choose a language which indeed supports conditional
compilation, and which e.g. doesn't enforce correct syntax on those pieces
which shouldn't be compiled at that time.  In C and C++ you'll need
the preprocessor for this. In Java, your only option is regular if statements.

>> 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:
> 
> Sure. Eventually you reach the point where the manual on good coding
> convention and style is larger than the language specification. At that
> point, it's time to rethink, and use more appropriate tools.
> 
>> Unfortunately, Ruby interpreters aren't particularly common in web browsers.. :-)
> 
> Yeah, and Java VM's as well :-(
> 
>> Are you trying to say one can do something in C that cannot be done in C++ ?  :-)
> 
> :-) No, just that C++ style OO is 'broken'

C++ isn't a pure OO langauge, and it never pretended to be.

C++ tries to be a "do-everything" language.  You can do OO development
in it and it works if you keep the discipline.  You can do non-OO
development - that works too.  And you're quite backwards compatible
to C.

> But for the sake of being anal and including yet another example:
> 
> int x = 1;
> void *p = &x;
> int *i = p;
> printf("The number was %d ", *i);
> 
> Won't work in C++ :-)

That's because you're trying to voilate the C++ type checking here.
You must either switch to C, or do one of the following:

  int x = 1;
  void *p = &x;
  int *i = (int *) p;
  printf("The number was %d ", *i);

or:

  int x = 1;
  int *p = &x;
  int *i = p;
  printf("The number was %d ", *i);

:-)

 
>>> 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>
> 
> unsigned types have error prone issues when casting from signed to
> unsigned types of the same size in C/C++, as no conversion takes place.
> You lose a little space efficiency without them but little else.

In Java one could add some code for checking here, since efficiency
isn't such a big concern anyway, and throw an exception in case the
conversion caused an overflow.

Btw this issue already exists in Java.  Try this in Java:

    int i = -2147483648;
    int j = -i;
    if ( i == j )
        System.out.println("Java thinks -2147483648 is equal to -(-2147483648)....");

There will be no compile time error or even warning, and no exception at runtime....

> The case for operator overloading has been argued over and over.
> Originally, it was argued that they unnecessarily complicated the
> language, and the number of legitimate use cases for them is relatively
> small. I tend to agree that the feature is overused in C++, but I don't
> think that justifies removing it.
> 
> Many features originally left out have made appearances recently, and
> it's likely to continue. I'd expect to see operator overloading appear.
> 
> Matt

-- 
----------------------------------------------------------------
Paul Schlyter,  Grev Turegatan 40,  SE-114 38 Stockholm,  SWEDEN
e-mail:  pausch at stockholm dot bostream dot se
WWW:     http://stjarnhimlen.se/
0
pausch
6/6/2006 9:43:40 PM
In article <hbOdncoOR8IOJxjZnZ2dnUVZ_vqdnZ2d@comcast.com>,
Michael J. Mahon <mjmahon@aol.com> wrote:

> mdj wrote:
>> Paul Schlyter wrote:
> 
> <snip>
> 
>> My concern is the manner in which small libraries or copy/paste chunks
>> of code pollute the relatively portable space of newer languages. In
>> ..NET, you can issue a keyword and switch into old-school mode. It
>> doesn't exactly provide an environment that encourages good design. Why
>> you would include features that good developers won't use is beyond me,
>> unless of course it's lousy developers you're catering to, which may
>> well be the point.
>> 
>> 
>>>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.....
>> 
>> 
>> It's actually irrelevant what sector we speak of - productivity
>> enhancements are productivity enhancements. While there are sectors
>> where you can 'afford' the extra time investment required to develop in
>> legacy languages, there's little reason to do so.
> 
> The previous exchange neglects to make the important distinction between
> time spent "up front" on design and implementation, and time spent
> "after the fact" on support and maintenance.
> 
> It is a sad but inescapable fact of commercial life that there is never
> time to do a job right, but always time to try to make it work.
> 
> One of my development laws is:  "'Quick and dirty' is never quick but
> always dirty."
> 
> The commercial pressure to get a product out the door that Paul refers
> to is so real that it generally precludes the design and implementation
> team from doing what they would do in the "best of all possible worlds"
> and instead condemns them to shipping a product that has many structual
> flaws.  Those flaws will cost dearly over the next few years, but, given
> the structure of corporate software teams, it is unlikely that senior
> team members will have to deal with much of the flak.
> 
> Management will be rewarded for "making the schedule" and the elevated
> support costs won't hit the fan until months later--when they can be
> blamed on an inexperienced implementation team.
> 
> Matt is making a idealistic argument for what is achievable with great
> discipline--and there's nothing wrong with that!  But in the "real
> world", discipline is much harder to come by, and almost impossible to
> stick to without (rare) management support.

I couldn't have said that better myself....

In the end, it's really the customers' fault -- after all, we make the
choice to get stuff as cheaply and quickly as we can, rather than wait
for, and pay for, quality stuff.

So I guess we all get what we deserve....



>>>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.
>> 
>> 
>> In this case, the old wheel has humps and bumps with regards to
>> portability and security. Should we throw those away? Absolutely.
> 
> Never assume that doing something over will mean doing it better.
> Life is full of counterexamples.
> 
> It will only be done better if a higher quality design and
> implementation can be done, and that's a big "if".  For one thing,
> management always thinks of the bad old solution as a _solution_,
> so they are unwilling to invest much time and effort in re-solving
> a problem "just" to obtain some "airy-fairy benefit" on the *next*
> manager's watch...  ;-(
> 
>>>>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.
> 
> Many of the short-sighted additions to otherwise clean languages are
> there *exactly* to solve short-term, schedule-driven problems.
> 
> We have a long history as a species of mortgaging the future for the
> present.  Whoever said "Pay me now or pay me later" neglected to
> mention the effect of high interest rates.  ;-)
> 
> As I often say, we tend to use our nose for a wall detector.  It works
> very well in the sense that it detects all the walls, but by the time
> it works, many of the wall's consequences are already felt.  ;-)
> 
>>>>"Those who cannot learn from history are doomed to repeat it...."
> 
> And, statistically, that would be all of us...  ;-)
> 
>>>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....
>> 
>> 
>> Of course, but when your platform isn't evolving you don't need
>> evolving development methodologies. The older techniques are adequate,
>> and in the case of the Apple II, a great deal of fun on such a
>> constrained environment. However, old techniques only scale so high,
>> and hit those limits. In the case of C/C++, those limits have been hit,
>> or close to it. There's still a large problem domain you use these
>> tools for, as it's the most appropriate. But many new problem domains
>> demand tools that have less restrictions, particularly in terms of
>> development time. Sometimes this involves using a slightly more
>> constrained language. Less is more!
> 
> Software folks are more likely to be afflicted with grandiosity than
> hardware folks.  Perhaps its the stronger engineering discipline of
> the hardware world, perhaps its the real smoke when something "blows
> up", or perhaps its because hardware people live *constantly* with
> constricting limits that discipline their dreams.
> 
> Software folks seldom experience real limits anymore.  They find it
> all too easy to imagine that they can accomplish *anything* through
> programming (even if they don't understand how to do it  ;-).
> 
> Most of the problems of todays software are a result of attempting to
> deal with more complexity than we can actually manage--and on a short
> schedule.  ;-)  The irony is that much of the complexity comes from
> aspects of "solutions" that are entirely optional--like GUI eye candy.
> 
> <fogeymode>
> 
> Most of what is done with computers today is much like what was done
> decades ago--text editing and formatting, modest number crunching.
> Only now, instead of spending 20 minutes choosing your words when
> writing a letter, you spend 10 minutes writing and 10 minutes choosing
> fonts.  ;-)
> 
> High quality image processing is relatively new, because of its demand
> for large memories and fast processors, but the basic image processing
> operations are purely mathematical and easily disciplined.  The same is
> true for most "media" processing.
> 
> Pasting databases together over the web is an example of an emergent
> capability, but one that is largely done using scripting languages.
> 
> Sometimes it's hard to see just what real value is being created in
> this endless hierarchy of levels of interpretation.  If anything
> turns out to be really useful, then it could be rewritten "flatter"
> to save about a factor of 1000 in computing resources!
> 
> Maybe in computers, too, power corrupts.  ;-)
> 
> </fogeymode>
> 
> -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."
-- 
----------------------------------------------------------------
Paul Schlyter,  Grev Turegatan 40,  SE-114 38 Stockholm,  SWEDEN
e-mail:  pausch at stockholm dot bostream dot se
WWW:     http://stjarnhimlen.se/
0
pausch
6/6/2006 9:43:41 PM
Michael J. Mahon wrote:

> > It's actually irrelevant what sector we speak of - productivity
> > enhancements are productivity enhancements. While there are sectors
> > where you can 'afford' the extra time investment required to develop in
> > legacy languages, there's little reason to do so.
>
> The previous exchange neglects to make the important distinction between
> time spent "up front" on design and implementation, and time spent
> "after the fact" on support and maintenance.

We're straying pretty far from the comparison of approaches between
implementation languages, of which the core of it was portability, but
anyway....

> It is a sad but inescapable fact of commercial life that there is never
> time to do a job right, but always time to try to make it work.
>
> One of my development laws is:  "'Quick and dirty' is never quick but
> always dirty."
>
> The commercial pressure to get a product out the door that Paul refers
> to is so real that it generally precludes the design and implementation
> team from doing what they would do in the "best of all possible worlds"
> and instead condemns them to shipping a product that has many structual
> flaws.  Those flaws will cost dearly over the next few years, but, given
> the structure of corporate software teams, it is unlikely that senior
> team members will have to deal with much of the flak.
>
> Management will be rewarded for "making the schedule" and the elevated
> support costs won't hit the fan until months later--when they can be
> blamed on an inexperienced implementation team.
>
> Matt is making a idealistic argument for what is achievable with great
> discipline--and there's nothing wrong with that!  But in the "real
> world", discipline is much harder to come by, and almost impossible to
> stick to without (rare) management support.

I agree completely, as would anyone who's done it for any length of
time. My point, *is* that it's idealistic to believe that you can
expect such discipline in a development team. I'm not arguing about how
people will work, but the development tools they're using. If anything,
Pauls argument is idealistic to believe programming teams will produce
portable C/C++ code just because it's feasible to do so with great
discipline. Sure you can do it. In the open source world most of the
code achieves architecture neutrality (but not often OS neutrality).
But there's no time pressure there.

Java teams will produce *far* more portable solutions essentially by
accident, since they're using toolsets that are designed with those
concerns in mind.

> >>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.
> >
> >
> > In this case, the old wheel has humps and bumps with regards to
> > portability and security. Should we throw those away? Absolutely.
>
> Never assume that doing something over will mean doing it better.
> Life is full of counterexamples.

Indeed. But if someone does something over for you (designs a new
language) and the results come out better, then you should take a look
at it. I'm not big on reinventing wheels either (hell, I'm a UNIX fan)

> It will only be done better if a higher quality design and
> implementation can be done, and that's a big "if".  For one thing,
> management always thinks of the bad old solution as a _solution_,
> so they are unwilling to invest much time and effort in re-solving
> a problem "just" to obtain some "airy-fairy benefit" on the *next*
> manager's watch...  ;-(

There are some good managers who see the benefits, but they're a rarity
for sure. I've seen at least one place do the opposite of everyone
else, and hire contract teams to maintain their existing systems, while
their staff went off and designed newer systems. The idea was that the
money they saved on maintenence down the track more than covered the
contracting costs, and they had better systems and happier staff, for
less money.

> >>>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.
>
> Many of the short-sighted additions to otherwise clean languages are
> there *exactly* to solve short-term, schedule-driven problems.

Indeed. There have been a few additions to Java of late to make it more
like C, which makes it easier to port code. They've managed not to
break the portability of Java in the process, but they've added a lot
of functionality that allows some pretty ugly code. In some ways I
*like* it that you have to rework certain things, and if it's too much
effort, use the callthroughs.

The limitations placed in Java haven't prevented it from becoming one
of the most widely used languages today. The portability is a real
benefit too, especially now that we're starting to hit some real
limitations: floor space and heat. Having the option to pick different
hardware based on the restrictions of the physical environment has real
benefit.

> We have a long history as a species of mortgaging the future for the
> present.  Whoever said "Pay me now or pay me later" neglected to
> mention the effect of high interest rates.  ;-)

lol!

> As I often say, we tend to use our nose for a wall detector.  It works
> very well in the sense that it detects all the walls, but by the time
> it works, many of the wall's consequences are already felt.  ;-)

Brilliant analogy :-)

> >>>"Those who cannot learn from history are doomed to repeat it...."
>
> And, statistically, that would be all of us...  ;-)
>
> >>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....
> >
> >
> > Of course, but when your platform isn't evolving you don't need
> > evolving development methodologies. The older techniques are adequate,
> > and in the case of the Apple II, a great deal of fun on such a
> > constrained environment. However, old techniques only scale so high,
> > and hit those limits. In the case of C/C++, those limits have been hit,
> > or close to it. There's still a large problem domain you use these
> > tools for, as it's the most appropriate. But many new problem domains
> > demand tools that have less restrictions, particularly in terms of
> > development time. Sometimes this involves using a slightly more
> > constrained language. Less is more!
>
> Software folks are more likely to be afflicted with grandiosity than
> hardware folks.  Perhaps its the stronger engineering discipline of
> the hardware world, perhaps its the real smoke when something "blows
> up", or perhaps its because hardware people live *constantly* with
> constricting limits that discipline their dreams.

I agree. I don't feel that I'm being grandious, though. I'm referring
to a language that's been in the field for a decade now. The Ruby boys
sure get a little grandious, but hey, a little dreaming is a necessity
to progression. It's all about balance.

I'm finding FPGA's pretty fun from that regard. Hardware, without
breadboards and blue smoke :-)

> Software folks seldom experience real limits anymore.  They find it
> all too easy to imagine that they can accomplish *anything* through
> programming (even if they don't understand how to do it  ;-).

And routinely fail to achieve anything useful in the process :-)

> Most of the problems of todays software are a result of attempting to
> deal with more complexity than we can actually manage--and on a short
> schedule.  ;-)  The irony is that much of the complexity comes from
> aspects of "solutions" that are entirely optional--like GUI eye candy.

This is the principle reason for evolving languages and tools. Improved
langugages allow ideas to be expressed more concisely, support
encapsulation mechanisms that allow complex modules to reused, thus
allowing complexity to be more effectively managed. Sure it's
idealistic to expect new tools solve all the problems, they don't. They
do however mitigate some of the old issues and allow some progress to
be made.

> <fogeymode>
>
> Most of what is done with computers today is much like what was done
> decades ago--text editing and formatting, modest number crunching.
> Only now, instead of spending 20 minutes choosing your words when
> writing a letter, you spend 10 minutes writing and 10 minutes choosing
> fonts.  ;-)
>
> High quality image processing is relatively new, because of its demand
> for large memories and fast processors, but the basic image processing
> operations are purely mathematical and easily disciplined.  The same is
> true for most "media" processing.

Ultimately, that's all we do with machines - manipulate media. Now that
extremely cheap machines can manipulate high definition AV content in
better than realtime, we're running out of reasons to make faster
machines. This is a good thing, in many ways.

> Pasting databases together over the web is an example of an emergent
> capability, but one that is largely done using scripting languages.
>
> Sometimes it's hard to see just what real value is being created in
> this endless hierarchy of levels of interpretation.  If anything
> turns out to be really useful, then it could be rewritten "flatter"
> to save about a factor of 1000 in computing resources!

It certainly opens up areas of research for 'real' Computer Science.
How do we get the computer to flatten the hierarchies for us ... ;-)

> Maybe in computers, too, power corrupts.  ;-)

It sure does... Don't get me wrong, guys, I've enjoyed my journey from
BASIC, 6502 assembly, Pascal, through to the C/C++ world, through Java,
and now emerging into 'scripting' languages like Ruby (although
scripting implies something ad-hoc, which I don't like). Through this
journey I've essentially used the highest level tool that would let me
get what I need done on current computers. Each step has allowed me to
do more, with less (as in my time). It's still fun to go back and write
6502 code on an Apple II, so I do. Still fun (at times) to write C, and
at times I do that (on the Apple II these days). It's a fun ride.

Matt

0
mdj
6/7/2006 2:59:20 AM
Paul Schlyter wrote:

> > My concern is the manner in which small libraries or copy/paste chunks
> > of code pollute the relatively portable space of newer languages. In
> > .NET, you can issue a keyword and switch into old-school mode. It
> > doesn't exactly provide an environment that encourages good design. Why
> > you would include features that good developers won't use is beyond me,
> > unless of course it's lousy developers you're catering to, which may
> > well be the point.
>
> The point isn't whether the developers are lousy or good - the point
> (to the management) is whether one can get the product out the door
> more quickly.  Pasting old code in old-school mode is often quicker
> than reimplementing the old code in new-school mode.  That's what
> matters in a commercial situation: to meet the deadline - a deadline
> which often is quite tight because your company won the contract over
> its competitors.  Basically it's about promising amost more than you
> can keep later.

Pasting code in old-school mode is only very slightly more time
efficient that wrapping it with a method call (which you'd do anyway
with the old school approach) at the cost of allowing new school code
to be written old school ways. There's not much difference either way,
except long term cost.

> >> 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....
> >
> > This is precisely why it is advocated that constants, plus language
> > constructs be used for conditional compilation.
>
> Then you'll have to choose a language which indeed supports conditional
> compilation, and which e.g. doesn't enforce correct syntax on those pieces
> which shouldn't be compiled at that time.  In C and C++ you'll need
> the preprocessor for this. In Java, your only option is regular if statements.

No. In C++ you can leave C code as C, as you have link level
compatibility. There is no reason whatsoever to use the preprocessor in
C++ code.

> C++ isn't a pure OO langauge, and it never pretended to be.

It doesn't even support most of the features that make a language OO.
You've got OO like encapsulation, but this is more akin to ADT's on
steroids than OO.

> C++ tries to be a "do-everything" language.  You can do OO development
> in it and it works if you keep the discipline.  You can do non-OO
> development - that works too.  And you're quite backwards compatible
> to C.

Many would argue that you can't do everything with it. You can't do
dynamic binding (only late), you can't do reflection or introspection
or any other OO feature that requires runtime typing, which is to say,
all of the good ones :-)

I major annoyance to me is the hackery you have to pull to get dynamic
class loading to work.

> > But for the sake of being anal and including yet another example:
> >
> > int x = 1;
> > void *p = &x;
> > int *i = p;
> > printf("The number was %d ", *i);
> >
> > Won't work in C++ :-)
>
> That's because you're trying to voilate the C++ type checking here.
> You must either switch to C, or do one of the following:

I'm not trying at all, it's a bit of legacy code that I need to use in
a C++ application ...

You can either update the code to suit the more modern language, or
compile the old code with a C compiler and link it. If it's well tested
code, that's what I'd do. This is the same approach as Java essentially
- you can link against C/C++ code if you must, or you can rewrite it.
It works in principle.

> >>> 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>
> >
> > unsigned types have error prone issues when casting from signed to
> > unsigned types of the same size in C/C++, as no conversion takes place.
> > You lose a little space efficiency without them but little else.
>
> In Java one could add some code for checking here, since efficiency
> isn't such a big concern anyway, and throw an exception in case the
> conversion caused an overflow.

I agree - there's a lot of things they could've added to make the
discrete type aspects of the langauge safer. Too late now - too much
code in the wild.

Matt

0
mdj
6/7/2006 3:27:32 AM
mdj wrote:
> Michael J. Mahon wrote:

<snip>

>>It will only be done better if a higher quality design and
>>implementation can be done, and that's a big "if".  For one thing,
>>management always thinks of the bad old solution as a _solution_,
>>so they are unwilling to invest much time and effort in re-solving
>>a problem "just" to obtain some "airy-fairy benefit" on the *next*
>>manager's watch...  ;-(
> 
> 
> There are some good managers who see the benefits, but they're a rarity
> for sure. I've seen at least one place do the opposite of everyone
> else, and hire contract teams to maintain their existing systems, while
> their staff went off and designed newer systems. The idea was that the
> money they saved on maintenence down the track more than covered the
> contracting costs, and they had better systems and happier staff, for
> less money.

And most organizations give maintenance tasks to new programmers, as
a kind of hazing, I think!

But not supporting the code that you produced, at least for its first
year in the field, deprives a team of the *real* learning experience,
in which you discover which of your grand ideas worked and which didn't.

And it also serves as a test of whether the code is *actually*
maintainable, as opposed to theoretically maintainable.

I see doing at least "early" maintenance as a kind of accountability.

>>>>>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.
>>
>>Many of the short-sighted additions to otherwise clean languages are
>>there *exactly* to solve short-term, schedule-driven problems.
> 
> 
> Indeed. There have been a few additions to Java of late to make it more
> like C, which makes it easier to port code. They've managed not to
> break the portability of Java in the process, but they've added a lot
> of functionality that allows some pretty ugly code. In some ways I
> *like* it that you have to rework certain things, and if it's too much
> effort, use the callthroughs.
> 
> The limitations placed in Java haven't prevented it from becoming one
> of the most widely used languages today. The portability is a real
> benefit too, especially now that we're starting to hit some real
> limitations: floor space and heat. Having the option to pick different
> hardware based on the restrictions of the physical environment has real
> benefit.
> 
> 
>>We have a long history as a species of mortgaging the future for the
>>present.  Whoever said "Pay me now or pay me later" neglected to
>>mention the effect of high interest rates.  ;-)
> 
> 
> lol!
> 
> 
>>As I often say, we tend to use our nose for a wall detector.  It works
>>very well in the sense that it detects all the walls, but by the time
>>it works, many of the wall's consequences are already felt.  ;-)
> 
> 
> Brilliant analogy :-)
> 
> 
>>>>>"Those who cannot learn from history are doomed to repeat it...."
>>
>>And, statistically, that would be all of us...  ;-)
>>
>>
>>>>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....
>>>
>>>
>>>Of course, but when your platform isn't evolving you don't need
>>>evolving development methodologies. The older techniques are adequate,
>>>and in the case of the Apple II, a great deal of fun on such a
>>>constrained environment. However, old techniques only scale so high,
>>>and hit those limits. In the case of C/C++, those limits have been hit,
>>>or close to it. There's still a large problem domain you use these
>>>tools for, as it's the most appropriate. But many new problem domains
>>>demand tools that have less restrictions, particularly in terms of
>>>development time. Sometimes this involves using a slightly more
>>>constrained language. Less is more!
>>
>>Software folks are more likely to be afflicted with grandiosity than
>>hardware folks.  Perhaps its the stronger engineering discipline of
>>the hardware world, perhaps its the real smoke when something "blows
>>up", or perhaps its because hardware people live *constantly* with
>>constricting limits that discipline their dreams.
> 
> 
> I agree. I don't feel that I'm being grandious, though. I'm referring
> to a language that's been in the field for a decade now. The Ruby boys
> sure get a little grandious, but hey, a little dreaming is a necessity
> to progression. It's all about balance.
> 
> I'm finding FPGA's pretty fun from that regard. Hardware, without
> breadboards and blue smoke :-)

As we enter the era of 10 million transistor FPGAs, system compilers,
and "turnarounds" measured in seconds--in short, as the constraints on
hardware design are eased--I expect to see many of the same problems
that have afflicted software shift into the "hardware" realm.

Discipline is hard-won.  Discipline can only coexist with ease and
convenience *after* it has been formed through hard experience, since
ease puts greater demands on discipline.

Tools can give the appearance of discipline by restricting expression,
but to a truly disciplined mind, tools are merely secondary.

I think of "strict" tools as "discipline for the undisciplined", but
so much of system design is outside the realm of any formal tools, that
there is no substitute for design discipline.  A terrible fate awaits
those who think that there is.

My first software tools phase was a macrogenerator phase--anything
was possible, and complexity could flourish in five pages of code.
It was not well suited to team efforts.  ;-)

My second software tools phase was strict typing and enforced structure.
My mantra was, "If you think you need a macro, then something is missing
from the language."  Experienced programmers chafed at the "training
wheels" the language forced upon them.  Some of them filled their code
with unstructured "workarounds", perhaps a sign of their resentment at
the strictures of the programming environment.  (Unstructured code can
be written in any language.)

My third software tools phase was "the only thing that matters is
the team".  I strove for a small team of 98th percentile people, who
implicitly understood the need for and benefits of discipline, and
who had learned this by experience.  Tools are useful, but secondary.
If a tool is really needed, it will be written.  (Structured code can
be written in any language.)

Although I don't consider any of the three approaches ideal, there
is no doubt that the third worked the best, both in terms of team
esprit and in terms of product quality (function & reliability).

Don't count too much on tools--it's the people that make the real
difference.

>>Software folks seldom experience real limits anymore.  They find it
>>all too easy to imagine that they can accomplish *anything* through
>>programming (even if they don't understand how to do it  ;-).
> 
> 
> And routinely fail to achieve anything useful in the process :-)

And those are the *good* cases.  Many times they achieve something that
is sold and wastes many people's time, but is actually worthless.

Remember the "Serius Computer Corporation", whose products were so
full of niggly little errors and inconsistencies that no one ever
found out that they actually didn't work at all! (Paraphrased ;-)

>>Most of the problems of todays software are a result of attempting to
>>deal with more complexity than we can actually manage--and on a short
>>schedule.  ;-)  The irony is that much of the complexity comes from
>>aspects of "solutions" that are entirely optional--like GUI eye candy.
> 
> 
> This is the principle reason for evolving languages and tools. Improved
> langugages allow ideas to be expressed more concisely, support
> encapsulation mechanisms that allow complex modules to reused, thus
> allowing complexity to be more effectively managed. Sure it's
> idealistic to expect new tools solve all the problems, they don't. They
> do however mitigate some of the old issues and allow some progress to
> be made.

For balance, I have to point out that they also permit *needless*
complexity to be more effectively managed.  When "Hello, World!"
executes 8 megabytes of code, you know something has gone sour.
(And, yes, I do include *all* the code executed, not just the code
in the "Hello, World!" module.)

>><fogeymode>
>>
>>Most of what is done with computers today is much like what was done
>>decades ago--text editing and formatting, modest number crunching.
>>Only now, instead of spending 20 minutes choosing your words when
>>writing a letter, you spend 10 minutes writing and 10 minutes choosing
>>fonts.  ;-)
>>
>>High quality image processing is relatively new, because of its demand
>>for large memories and fast processors, but the basic image processing
>>operations are purely mathematical and easily disciplined.  The same is
>>true for most "media" processing.
> 
> 
> Ultimately, that's all we do with machines - manipulate media. Now that
> extremely cheap machines can manipulate high definition AV content in
> better than realtime, we're running out of reasons to make faster
> machines. This is a good thing, in many ways.

Since we're running out of silicon "smoothness", and with it Moore's
"Law", I suppose its just as well that we're feeling satisfied with
where we are.  ;-)

There are still orders of magnitude of improvements in cost/performance,
so the game certainly isn't up.  But those lavish resources will demand
ever more discipline from designers, lest they all go down the drain
(like much of the last few orders of magnitude ;-).

I have no problem conceiving computing tasks that would require 1000
times as much processing power as is currently affordable, but it all
needs to be spent on crunching, not on 3D widgets and redundant code.

>>Pasting databases together over the web is an example of an emergent
>>capability, but one that is largely done using scripting languages.
>>
>>Sometimes it's hard to see just what real value is being created in
>>this endless hierarchy of levels of interpretation.  If anything
>>turns out to be really useful, then it could be rewritten "flatter"
>>to save about a factor of 1000 in computing resources!
> 
> 
> It certainly opens up areas of research for 'real' Computer Science.
> How do we get the computer to flatten the hierarchies for us ... ;-)

I think that will be done as a partnership between very clever designers
and very fast machines.

-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."
0
Michael
6/7/2006 8:30:52 AM
Michael J. Mahon wrote:

> And most organizations give maintenance tasks to new programmers, as
> a kind of hazing, I think!
>
> But not supporting the code that you produced, at least for its first
> year in the field, deprives a team of the *real* learning experience,
> in which you discover which of your grand ideas worked and which didn't.
>
> And it also serves as a test of whether the code is *actually*
> maintainable, as opposed to theoretically maintainable.
>
> I see doing at least "early" maintenance as a kind of accountability.

Fully agree. All of the applicable data that needs to be fed into the
improvement process comes directly from supporting the code. Severing
the connection between the development group and this process is most
unwise, as it's these people that need to come up with ways of
improving this process. That's where you get real efficiency.

Of course the problem is that if your development team is spending its
time doing support, it doesn't have the time to develop new versions of
code. This is where the the process I outlined previously comes in.
Once the support issues around the product stabilise, you bring in
short-term resources to handle that support, free up the development
team, and start the process again.

> As we enter the era of 10 million transistor FPGAs, system compilers,
> and "turnarounds" measured in seconds--in short, as the constraints on
> hardware design are eased--I expect to see many of the same problems
> that have afflicted software shift into the "hardware" realm.
>
> Discipline is hard-won.  Discipline can only coexist with ease and
> convenience *after* it has been formed through hard experience, since
> ease puts greater demands on discipline.
>
> Tools can give the appearance of discipline by restricting expression,
> but to a truly disciplined mind, tools are merely secondary.
>
> I think of "strict" tools as "discipline for the undisciplined", but
> so much of system design is outside the realm of any formal tools, that
> there is no substitute for design discipline.  A terrible fate awaits
> those who think that there is.

It's also premanaged complexity, for those that have neither the time
or the resources to mangage it themselves. Tools don't necessarily have
to be strict, just work, and provide access to complex functionality
that's already proven. This is where tool and language evolution is
key. This complexity goes up all the time, while human discipline
evolves slowly and has real, known limits. In order to build more
complex systems, more complex toolsets that encapsulate that complexity
must be employed.

> My second software tools phase was strict typing and enforced structure.
> My mantra was, "If you think you need a macro, then something is missing
> from the language."  Experienced programmers chafed at the "training
> wheels" the language forced upon them.  Some of them filled their code
> with unstructured "workarounds", perhaps a sign of their resentment at
> the strictures of the programming environment.  (Unstructured code can
> be written in any language.)

Been there too. Time has proven it doesn't work well, and that test
driven development techniques provide more safety, and allow more
flexible forms of expression in the process, easing chafing.

> My third software tools phase was "the only thing that matters is
> the team".  I strove for a small team of 98th percentile people, who
> implicitly understood the need for and benefits of discipline, and
> who had learned this by experience.  Tools are useful, but secondary.
> If a tool is really needed, it will be written.  (Structured code can
> be written in any language.)
>
> Although I don't consider any of the three approaches ideal, there
> is no doubt that the third worked the best, both in terms of team
> esprit and in terms of product quality (function & reliability).
>
> Don't count too much on tools--it's the people that make the real
> difference.

The problem is such teams are very hard to build, and keep. And often
the 98th percentile people are already consumed by the very companies
that produce the technology you're trying to leverage. It's really up
to say, the 90th percentile group to manage the complexity for the
rest, and provide it in more accessible forms, through tools that
support higher abstractions, allowing more to be done.

It's certainly not ideal either, and it shifts a lot of 'waste' onto
the machines. But this is the only place you can feasibly put it,
because the machines are cheap and get bigger all the time. The humans
on the other hand....

> > This is the principle reason for evolving languages and tools. Improved
> > langugages allow ideas to be expressed more concisely, support
> > encapsulation mechanisms that allow complex modules to reused, thus
> > allowing complexity to be more effectively managed. Sure it's
> > idealistic to expect new tools solve all the problems, they don't. They
> > do however mitigate some of the old issues and allow some progress to
> > be made.
>
> For balance, I have to point out that they also permit *needless*
> complexity to be more effectively managed.  When "Hello, World!"
> executes 8 megabytes of code, you know something has gone sour.
> (And, yes, I do include *all* the code executed, not just the code
> in the "Hello, World!" module.)

Sure. Of course, it bares pointing out that you're referring to 8mb of
code that Hello World won't execute, but will carry around as a payload
anyway. Runtime systems are getting larger that's true, but they also
only have to be loaded once, thanks to copy on write memory, and much
of the initialisation work can be cached and shared amongst running
applications. Over time the issues bought about by this approach are
being mitigated, and besides, it's good fun work finding ways to tune
it out.

It's not ideal, but what's the alternative? If you don't follow this
road, a cap is placed on the possible solutions you can build. The
overheads introduced by high level abstraction systems is a very
interesting field of research, and one that great inroads into managing
has been made.

I can see a time when massive parallel computing clusters 'churn'
through algorithms, fitting them to particular machines are problem
domains. Programming done by the human will be not much more than
assembling from vast libraries of prevalidated solutions. It doesn't
take much thinking into the future to imagine a time when software
complexity is so high that this is the only feasible solution to
building more complex systems.

I think we're more or less on the right track, but breaking the ties to
legacy implementations that simply cannot be scaled in this way is one
of the biggest hurdles to moving further towards solving the current
issues in software design.

Matt

0
mdj
6/8/2006 3:36:34 AM
mdj wrote:
> Paul Schlyter wrote:
>
> > What "Java portability" ????
> >
> > Java is not a portable language.  Java is less portable than both
> > FORTRAN, C or C++, which runs on several platforms.  Java runs on one
> > single platform only: the Java platform.
>
> Sorry, this isn't true. The Java language specification is quite
> deliberately void of any language construct  that would bind it, or any
> program written in it to a specific architecture. The key concepts that
> are missing here are pointers,

It has pointers, just not accessible by the user.
i.e. null reference

> and more specifically, the ability to
> perform arbitrary arithmetic on pointer types. Additionally, the
> language specification defines EXACTLY the size and precision of each
> data type. C and C++ on the other hand, not only allow arbitrary
> pointer arithmetic, but also only define in the standard, the minimum
> size requirements of each data type.

You say that, as if it was a bad thing.

The problem is one of size vs speed, and ease of serialization, which
is why C99 added int#_t, int_fast#_t, int_least#_t

While most code doesn't need to know the bit size of types, you still
need to know the min sizes, so you don't have to worry about underflow
/ overflow.  The size issue comes up when serializing.  By the language
mandidating features, even if the hardware doesn't support them, say
like doubles on DSPs, or the PS2, is one of the reasons Java is so
slow.

See: "How Java's Floating-Point Hurts Everyone Everywhere"
http://www.cs.berkeley.edu/~wkahan/JAVAhurt.pdf


Maybe you have a different experience on "portability" you can comment
on, compared to Carmack's (May 2006) one with Java and cell-pohones?

http://www.armadilloaerospace.com/n.x/johnc/Recent%20Updates

It turns out that I'm a lot less fond of Java for
resource-constrained work. I remember all the little gripes I had with
the Java language, like no unsigned bytes, and the consequences of
strong typing, like no memset, and the inability to read resources into
anything but a char array, but the frustrating issues are details down
close to the hardware.

The biggest problem is that Java is really slow. On a pure cpu / memory
/ display / communications level, most modern cell phones should be
considerably better gaming platforms than a Game Boy Advanced. With
Java, on most phones you are left with about the CPU power of an
original 4.77 mhz IBM PC, and lousy control over everything.

I spent a fair amount of time looking at java byte code disassembly
while optimizing my little rendering engine. This is interesting fun
like any other optimization problem, but it alternates with a bleak
knowledge that even the most inspired java code is going to be a
fraction the performance of pedestrian native C code.

Even compiled to completely native code, Java semantic requirements
like range checking on every array access hobble it. One of the phones
(Motorola i730) has an option that does some load time compiling to
improve performance, which does help a lot, but you have no idea what
it is doing, and innocuous code changes can cause the compilable
heuristic to fail.

Write-once-run-anywhere. Ha. Hahahahaha. We are only testing on four
platforms right now, and not a single pair has the exact same quirks.
All the commercial games are tweaked and compiled individually for each
(often 100+) platform. Portability is not a justification for the awful
performance.

Cheers

0
Michael
6/8/2006 5:31:23 AM
Michael J. Mahon wrote:
> The Apple ROM was not significantly changed until the //e, where much
> of the actual code was placed in a bank-switched area.  Much of the F8
> region became stubs at documented entry points vectoring to the actual
> routines.  Updating the F8 region of the ROM was known to be a minefield
> of compatibility issues.
>
> The notion of defining the ROM entry points more architecturally was
> not widespread at the time the Apple II was designed, and the impact
> of the subsequent loss of control over ROM code became a problem.

This is related to another hobby of mine -- the HP48 calculator (which
in a lot of ways, has the same "Apple" feel.)  It had the same problem,
all though it wasn't as bad, since there became known 'entry points' of
the system ROM; i.e. SYSEVAL on the HP28 which exposed the problem to
the general public.  (You know how curious engineers/geeks are when
something has "undocumented" written all over it.  ;-)

I'll agree that it was not widespread, but it was known. The question
is when?
Woz did work at HP -- when did the calculator people come up with a
solution?  And did Woz know about it?



> (I've always wondered how much "compatibility issues" and how much
> "renegotiation issues" factored into the decision to never update
> the Applesoft ROMs to fix bugs...)
>
> Later systems used a combination of less documentation and more
> complexity to make calls into the middle of ROM less likely.  Still
> not an ideal solution, but one well adapted to the Apple II.  ;-)

It certainly looks like everyone was too busy writing their own code,
since the ROM code wasn't all that usefull.

Cheers

0
Michael
6/8/2006 5:50:52 AM
Michael wrote:

> While most code doesn't need to know the bit size of types, you still
> need to know the min sizes, so you don't have to worry about underflow
> / overflow.  The size issue comes up when serializing.  By the language
> mandidating features, even if the hardware doesn't support them, say
> like doubles on DSPs, or the PS2, is one of the reasons Java is so
> slow.

Obviously if your application requires the use of a data size or type
that's unsupported by your hardware you're going to have performance
problems, but this applies regardless of language used.

> See: "How Java's Floating-Point Hurts Everyone Everywhere"
> http://www.cs.berkeley.edu/~wkahan/JAVAhurt.pdf

For heavily numeric intensive applications, you need dedicated numerics
libraries. This is the case for C and C++ as well.

It'd be nice if people could come up with a nice standardised rich
numeric specification that could be added to Java. I'd imagine it'll
happen eventually.

> Maybe you have a different experience on "portability" you can comment
> on, compared to Carmack's (May 2006) one with Java and cell-pohones?

I've only used Java in desktop and server environments, where the
problems are mitigated by mature virtual machines.

> http://www.armadilloaerospace.com/n.x/johnc/Recent%20Updates
>
> It turns out that I'm a lot less fond of Java for
> resource-constrained work. I remember all the little gripes I had with
> the Java language, like no unsigned bytes, and the consequences of
> strong typing, like no memset, and the inability to read resources into
> anything but a char array, but the frustrating issues are details down
> close to the hardware.
>
> The biggest problem is that Java is really slow. On a pure cpu / memory
> / display / communications level, most modern cell phones should be
> considerably better gaming platforms than a Game Boy Advanced. With
> Java, on most phones you are left with about the CPU power of an
> original 4.77 mhz IBM PC, and lousy control over everything.
>
> I spent a fair amount of time looking at java byte code disassembly
> while optimizing my little rendering engine. This is interesting fun
> like any other optimization problem, but it alternates with a bleak
> knowledge that even the most inspired java code is going to be a
> fraction the performance of pedestrian native C code.
>
> Even compiled to completely native code, Java semantic requirements
> like range checking on every array access hobble it. One of the phones
> (Motorola i730) has an option that does some load time compiling to
> improve performance, which does help a lot, but you have no idea what
> it is doing, and innocuous code changes can cause the compilable
> heuristic to fail.

Every one of the issues you mention is the result of poorly implemented
virtual machines,  or at least *young* virtual machines. There's no
real reason for Java code to execute more slowly than C or C++, and
benchmarks routinely show that it does indeed run as fast, and in some
cases faster. It all depends on the sophistication of your compiler, or
in the Java case, the JIT/HotSpot engine.

> Write-once-run-anywhere. Ha. Hahahahaha. We are only testing on four
> platforms right now, and not a single pair has the exact same quirks.
> All the commercial games are tweaked and compiled individually for each
> (often 100+) platform. Portability is not a justification for the awful
> performance.

It's still a very young platform that's changing quickly.  As a result,
there's little API standardisation across phones. Then there's vendors
wanting to keep their own API under lock and key.

None of these are Java, or more generically VM based platform issues,
just immature platforms growing fast, and experiencing pains as a
result.

Matt

0
mdj
6/8/2006 6:42:08 AM
mdj wrote:
> Michael wrote:
> > The biggest problem is that Java is really slow. ...
>
> Every one of the issues you mention is the result of poorly implemented
> virtual machines,  or at least *young* virtual machines. There's no
> real reason for Java code to execute more slowly than C or C++, and
> benchmarks routinely show that it does indeed run as fast, and in some
> cases faster. It all depends on the sophistication of your compiler, or
> in the Java case, the JIT/HotSpot engine.

In case you didn't click the link, Michael doesn't make it clear that
he copied and pasted Carmack's actual comments, which are over one year
old. John also used NetBeans to develop, and criticized the IDE
performance. I use Eclipse, and see less slowdowns than I do in
VisualStudio Express. Java, .NET, same thing really, and MS is going
for the same markets (gaming etc).

Michael, you neglected to quote from John's recent post:
"O&E [game name] added a high end java version that kept most of the
quality of the high end BREW version on phones fast enough to support
it from carriers willing to allow the larger download. The download
size limits are probably the most significant restriction for gaming on
the high end phones."

This much more strongly implies that Matt is correct ...

> None of these are Java, or more generically VM based platform issues,
> just immature platforms growing fast, and experiencing pains as a result.

Cheers,
Nick.

0
sicklittlemonkey
6/8/2006 9:32:56 AM
mdj wrote:
> Michael J. Mahon wrote:

<snip>

>>I think of "strict" tools as "discipline for the undisciplined", but
>>so much of system design is outside the realm of any formal tools, that
>>there is no substitute for design discipline.  A terrible fate awaits
>>those who think that there is.
> 
> 
> It's also premanaged complexity, for those that have neither the time
> or the resources to mangage it themselves. Tools don't necessarily have
> to be strict, just work, and provide access to complex functionality
> that's already proven. This is where tool and language evolution is
> key. This complexity goes up all the time, while human discipline
> evolves slowly and has real, known limits. In order to build more
> complex systems, more complex toolsets that encapsulate that complexity
> must be employed.

Of course there is a need for higher levels of abstraction.

But much of the discussion here has been driven by "strongly typed"
and "restricted" languages and semantics vs. "weakly typed" and
unrestricted (nonportable) languages.

The presumed superiority of the former is that it either:
1) makes it harder to do bad things accidentally,
2) makes it harder to do bad things intentionally,
3) makes it easier to do good things accidentally, or
4) makes it easier to do good things intentionally.

I note that 1) and 3) (the unintentional flavors) can be readily
supported, and can be construed as support for relative newbies.

It is much more difficult to make a case for 2), since intention
knows no bounds, and I think we have all seen cases where the
finest language has been horribly abused.

It is certainly possible to write non-portable code in any sufficiently
complex system, simply by exploiting some irregular behavior--and there
will *always* be some irregular behavior to be exploited.  ;-)

It is also possible to write spaghetti code in any language, if
only by writing it as a state sequencer in a looped case statement.

Case 4) is the most interesting, since it offers the real possibility
of improvment by raising the level of abstraction.  It is worth noting,
though, that most abstractions employed in more modern languages were
developed by designers working in less restrictive languages, doing
explicitly what was later encapsulated implicitly.

Therefore, a less abstract language, far from preventing a good designer
from doing beautiful abstractions, actually provides the medium for the
abstractions to be created and prove their worth.  It remains to be seen
whether abstract languages like Java will similarly give birth to new
levels of abstraction "beyond objects".

If it were not for languages with explicit pointers, all our current
"object oriented" languages would never have come to be.  The first
such programs were written in assembly language, and were far more
versatile and efficient in their realm than comparable programs
written today.  (Sutherland's Sketchpad comes immediately to mind.)

Further, though abstraction is essential, the best designers are
characterized by a much wider "abstraction bandwidth" than is
common, and their ability to span many levels of abstraction in
their thought is what allows them to create *efficient* designs,
rather than just "correct" designs.  (BTW, designers with "high
bandwidth" are always in short supply, and much of todays software
reflects their absence.)

I have been frequently appalled to find that *system* programmers
working at the lowest levels of OS design are often almost completly
ignorant of the *machine* implications of the code that they write.

In one unfortunate example, a designer had invoked a double-precision
integer divide in the OS timer interrupt routine, because they had
decided to keep the timer queue in human time units rather than
in machine ticks.  They were completley unaware that moving this
unit conversion from the enqueuing action to the dequeuing action
would have latency and performance impact throughout the system!

In another case (same OS, slightly higher level), the designer of
the process scheduler had decided to set a timeslice timer on each
process as it was launched, so that its expiration could be used to
time out the process if it did not wait for I/O prior to expiration.
If the process waited for I/O first, the timer was cancelled.

As it happened, the time required to create and enqueue each new
timer at process launch, and the time to dequeue and cancel it when
in the overwhelming majority of cases the process waited prior to
expiration, accounted for over 80 percent of the time spent in the
process scheduler!

The fix, obvious with a little "wider bandwidth" perception of things,
was to eliminate the timers, and instead place an interval count into
each process structure that was initialized at process launch time.
The standard "heartbeat" timer would then decrement this field
regularly, and, when it went to zero, notify the process scheduler
that the active process had timed out.  This accomplishes the same
functional goal, though with less time resolution, in that very small
fraction of cases where the active process does not wait prior to
expiration of its timeslice.

This "perspective shift" on the handling of a relatively rare event
resulted in speeding up the process scheduler by more than a factor
of four, and dropped the usage of the timer facility by two orders
of magnitude!

There is *no* substitute for a low-level understanding of what is
actually going on in a system.  Unfortunately, higher level tools tend
to further obscure actual system behavior by making it more "esoteric".

>>My second software tools phase was strict typing and enforced structure.
>>My mantra was, "If you think you need a macro, then something is missing
>>from the language."  Experienced programmers chafed at the "training
>>wheels" the language forced upon them.  Some of them filled their code
>>with unstructured "workarounds", perhaps a sign of their resentment at
>>the strictures of the programming environment.  (Unstructured code can
>>be written in any language.)
> 
> 
> Been there too. Time has proven it doesn't work well, and that test
> driven development techniques provide more safety, and allow more
> flexible forms of expression in the process, easing chafing.

No argument here--test scaffolds have proven their worth many times
over, yet their adoption as a standard part of any development has
been widely rejected.  Maybe we're past that now...

>>My third software tools phase was "the only thing that matters is
>>the team".  I strove for a small team of 98th percentile people, who
>>implicitly understood the need for and benefits of discipline, and
>>who had learned this by experience.  Tools are useful, but secondary.
>>If a tool is really needed, it will be written.  (Structured code can
>>be written in any language.)
>>
>>Although I don't consider any of the three approaches ideal, there
>>is no doubt that the third worked the best, both in terms of team
>>esprit and in terms of product quality (function & reliability).
>>
>>Don't count too much on tools--it's the people that make the real
>>difference.
> 
> 
> The problem is such teams are very hard to build, and keep. And often
> the 98th percentile people are already consumed by the very companies
> that produce the technology you're trying to leverage. It's really up
> to say, the 90th percentile group to manage the complexity for the
> rest, and provide it in more accessible forms, through tools that
> support higher abstractions, allowing more to be done.
> 
> It's certainly not ideal either, and it shifts a lot of 'waste' onto
> the machines. But this is the only place you can feasibly put it,
> because the machines are cheap and get bigger all the time. The humans
> on the other hand....

You know, I fundamentally agree with your point.  But I am sobered by
the realization that 90% of the software we are talking about is code
to download music or animate the "bounce" in a cursor bar.

The fundamentally inessential and, at most, transient importance of the
vase majority of code that is written, constrasted with the much smaller
amount of truly essential, even critical, code, makes the argument for
armies of "average" coders much less relevant.

The truth is that very little code needs to be really good.  If it's
just 2% of all the code written, then it could all be done by 98th
percentile people.  And, frankly, I don't really care whether the other
98% of code is written well, or even written at all.

It reminds me of "Sturgeon's Law".  When, at a cocktail party, Theodore
Sturgeon was asked what he did, he replied, "I write science fiction."
The response was, "Science fiction!  90% of science fiction is crap!"
To which Sturgeon replied, "Sir, 90% of *everything* is crap."

So there is no real shortage of good designers, just a poor system of
allocating them to projects.  Almost 90% of them are working on crap!

It is a frequently stated goal of language designers to make bad things
harder and good things easier.  What has never been studied is whether
these tools actually improve the productivity and quality of output of
the 2% of *great* programmers, on whom we all ultimately depend.

Most programmer productivity (not to be confused with quality, but not
unrelated) studies have shown *much* greater variance (50:1!) is
attributed to individuals rather than to the tools they use.  My own
experience supports this finding.  (BTW, "programmer productivity"
has nothing to do with "lines of code" but with "problems solved".)

I can appreciate an editor that pops up the full procedure interface
for me as soon as I type a half-dozen characters of its name, but I
note that it facilitates calling the *wrong* procedure as well as the
right one.  I'm glad that it lets *me* choose.  ;-)

>>>This is the principle reason for evolving languages and tools. Improved
>>>langugages allow ideas to be expressed more concisely, support
>>>encapsulation mechanisms that allow complex modules to reused, thus
>>>allowing complexity to be more effectively managed. Sure it's
>>>idealistic to expect new tools solve all the problems, they don't. They
>>>do however mitigate some of the old issues and allow some progress to
>>>be made.
>>
>>For balance, I have to point out that they also permit *needless*
>>complexity to be more effectively managed.  When "Hello, World!"
>>executes 8 megabytes of code, you know something has gone sour.
>>(And, yes, I do include *all* the code executed, not just the code
>>in the "Hello, World!" module.)
> 
> 
> Sure. Of course, it bares pointing out that you're referring to 8mb of
> code that Hello World won't execute, but will carry around as a payload
> anyway. Runtime systems are getting larger that's true, but they also
> only have to be loaded once, thanks to copy on write memory, and much
> of the initialisation work can be cached and shared amongst running
> applications. Over time the issues bought about by this approach are
> being mitigated, and besides, it's good fun work finding ways to tune
> it out.

Actually, I was talking about the 8MB of code--most of it *not* within
the Hellow World application--that will be executed in the act of
painting "Hello, World!" on the screen.  The 8MB of libraries embedded
in a trivial application are a separate issue (to which there are well
known but seldom applied solutions).

> It's not ideal, but what's the alternative? If you don't follow this
> road, a cap is placed on the possible solutions you can build. The
> overheads introduced by high level abstraction systems is a very
> interesting field of research, and one that great inroads into managing
> has been made.

I have no problem with the upper two or three "layers" being rather
loosely bound--after all they are, or should be, in flux.

My issue is with the dozen levels beneath these, which have not changed
for a decade, and are much in need of collapsing into a much more
efficient and, yes, less portable structure.  (BTW, have you noticed
the steadily decreasing value of architectural portability?  ;-)

Code which is executed many times per day by tens of millions of people
can be justifiably optimized, since it will save *huge* amounts of human
and machine resources to do so.

> I can see a time when massive parallel computing clusters 'churn'
> through algorithms, fitting them to particular machines are problem
> domains. Programming done by the human will be not much more than
> assembling from vast libraries of prevalidated solutions. It doesn't
> take much thinking into the future to imagine a time when software
> complexity is so high that this is the only feasible solution to
> building more complex systems.

I remain radically suspicious of any approach that minimizes the
fundamental role of conscious design--unless we plan to use genetic
algorithms to evolve programs.  (I'm not entirely kidding here, but
this is clearly not "around the corner".)

> I think we're more or less on the right track, but breaking the ties to
> legacy implementations that simply cannot be scaled in this way is one
> of the biggest hurdles to moving further towards solving the current
> issues in software design.

I'm beginning to wonder what you consider the current issues in
software design to be.

This is not the same thing as identifying important problems that
computers could help solve, though we seem to be less imaginative
here than we once were.  Nor is it the same thing as figuring out
how to solve a problem using computers, though this is a *very*
significant problem.  It would have to be issues in converting a
known solution to an important problem into a program that realizes
that solution.

In this area, the fundamental limiters I see are complexity (human
limiter), resources (human and machine limiters), and performance
(machine limiter).

I expect tools to help manage complexity, as you do, but I also
require tools to manage human and machine resources, and machine
performance.  In the (related) areas of resources and performance,
tools can be used to help visualize usage so that a designer can
make better informed tradeoffs.

I am quite disappointed with the relatively poor quality of tools
to correlate system design choiced (like class structures) with
real system metrics, like memory resources and performance.  As
we move into more concurrent systems, measures of locality will
be extremely important, and remain largely unaddressed in the
current generation of tools.

In the not too distant future, we will be able to treat today's large,
"nonportable" bodies of code, together with the behavioral spec of the
systems they run on, as a "source language" from which we will be able
to compile a program with equivalent behavior on any system we choose.

The real problem with legacy applications is that we need them to
continue to behave *exactly* the same, to avoid compatibility ripples.

The best way forward has always been not to "port" legacy apps, but to
*replace* them entirely with new subsystems, supporting new functions.

The practical useful lifetime for code is measured in the cost of
human change, not machine change, so having practical portablity
may turn out to obstruct rather than expedite the move to a truly
better solution.

-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."
0
Michael
6/8/2006 5:56:52 PM
Michael wrote:
> Michael J. Mahon wrote:
> 
>>The Apple ROM was not significantly changed until the //e, where much
>>of the actual code was placed in a bank-switched area.  Much of the F8
>>region became stubs at documented entry points vectoring to the actual
>>routines.  Updating the F8 region of the ROM was known to be a minefield
>>of compatibility issues.
>>
>>The notion of defining the ROM entry points more architecturally was
>>not widespread at the time the Apple II was designed, and the impact
>>of the subsequent loss of control over ROM code became a problem.
> 
> 
> This is related to another hobby of mine -- the HP48 calculator (which
> in a lot of ways, has the same "Apple" feel.)  It had the same problem,
> all though it wasn't as bad, since there became known 'entry points' of
> the system ROM; i.e. SYSEVAL on the HP28 which exposed the problem to
> the general public.  (You know how curious engineers/geeks are when
> something has "undocumented" written all over it.  ;-)
> 
> I'll agree that it was not widespread, but it was known. The question
> is when?
> Woz did work at HP -- when did the calculator people come up with a
> solution?  And did Woz know about it?

Woz was at HP in the early days of HP calculators, but before the
programmable handheld days.

Entry point vectors were well-known since the earliest days of
computing, but tended to be used only when their benefits were
seen as justifying the cost of the vector in RAM/ROM.

Woz did not envision the widespread popularity of the Apple II, and
so did not avail himself of such protective techniques.

And, of course, it's not really "protection" if you can address
anywhere in the ROM anyway.  So he just published the entry points
he thought were useful and likely to be preserved, assuming that
fellow enthusiasts would take the information to heart.)

>>(I've always wondered how much "compatibility issues" and how much
>>"renegotiation issues" factored into the decision to never update
>>the Applesoft ROMs to fix bugs...)
>>
>>Later systems used a combination of less documentation and more
>>complexity to make calls into the middle of ROM less likely.  Still
>>not an ideal solution, but one well adapted to the Apple II.  ;-)
> 
> 
> It certainly looks like everyone was too busy writing their own code,
> since the ROM code wasn't all that usefull.

Have you tried writing 80-column scrolling?  ;-)

-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."
0
Michael
6/8/2006 6:43:36 PM
Michael J. Mahon wrote:

> Of course there is a need for higher levels of abstraction.
>
> But much of the discussion here has been driven by "strongly typed"
> and "restricted" languages and semantics vs. "weakly typed" and
> unrestricted (nonportable) languages.

And much of the argument against being that strongly typed yields
inefficiency, a point I strongly disagree with.

> The presumed superiority of the former is that it either:
> 1) makes it harder to do bad things accidentally,
> 2) makes it harder to do bad things intentionally,
> 3) makes it easier to do good things accidentally, or
> 4) makes it easier to do good things intentionally.
>
> I note that 1) and 3) (the unintentional flavors) can be readily
> supported, and can be construed as support for relative newbies.

Not just newbies, though. Plenty of good programmers have used
techniques that over time have proven to be problematic. Some of them
realise the problems and stop using the techniques, some of them don't.
It's common to end up in a heated discussion with a  fine engineer who
doesn't want to change an obviously flawed approach because they cannot
see the future benefits of doing so.

> It is much more difficult to make a case for 2), since intention
> knows no bounds, and I think we have all seen cases where the
> finest language has been horribly abused.

Can't argue with that. It's certainly possible in any environment to
exploit it horribly. It's true though that as the level of 3) goes up,
the frequency of 2) goes down. You're much less likely to try hard to
do do something that has an obvious easy way.

But then, it certainly does happen ;-)

> It is certainly possible to write non-portable code in any sufficiently
> complex system, simply by exploiting some irregular behavior--and there
> will *always* be some irregular behavior to be exploited.  ;-)

The hardest part of the problem, and one yet unsolved by language
design.

A classic source of behavoral irregularity is in module initialisation.
You frequently situations where a module is initialised according to
it's documentation, only to find out you didn't do it exactly right,
and ended up depending on some non-determined default within the
module, and later version break your system. Regardless of the level of
typing involved, this one can surface. It's a current topic of research
to figure out solutions to this issue.

> It is also possible to write spaghetti code in any language, if
> only by writing it as a state sequencer in a looped case statement.

This is actually one of the best examples of where language design
falls down, and it's often construed that you need to rely on
old-school constructs to build efficient state machines. While this is
essentially false, I'd like to see better language support for state
machines in the first place. It's odd that such a fundamental facet of
computer science has such poor abstractions in place around it.

> Case 4) is the most interesting, since it offers the real possibility
> of improvment by raising the level of abstraction.  It is worth noting,
> though, that most abstractions employed in more modern languages were
> developed by designers working in less restrictive languages, doing
> explicitly what was later encapsulated implicitly.
>
> Therefore, a less abstract language, far from preventing a good designer
> from doing beautiful abstractions, actually provides the medium for the
> abstractions to be created and prove their worth.  It remains to be seen
> whether abstract languages like Java will similarly give birth to new
> levels of abstraction "beyond objects".

Design Patterns is an excellent example post-object abstraction. While
there's a lot of hype around the concept the original text, entitled
"Design Patterns" is an interesting read. Essentially, the authors
studied the code of several large "successful" systems built in OO
languages, and discovered many recurring patterns which they distilled
into generic descriptions and templates as solutions to commonly
recurring problems.

If you've heard OO programmers uttering terms like Singleton, Facade,
Builder, Adaptor, this is where these terms come from. It's evolved
into a 'language' for developers to talk about complex design ideas.
For the moment, it's a language for humans rather than machines, but
it's only a matter of time.

> If it were not for languages with explicit pointers, all our current
> "object oriented" languages would never have come to be.  The first
> such programs were written in assembly language, and were far more
> versatile and efficient in their realm than comparable programs
> written today.  (Sutherland's Sketchpad comes immediately to mind.)

Sure. It's worth pointing out though that explicit pointers aren't
necessary to achieve efficient designs, just as, on 32 bit platforms
anyway, there's no need to write position dependant code. If you're
targetting a 6502 or even 68000, you have to make some compromises, but
those restrictions simply no longer exist, and the need for techniques
that allow for the restrictions are gone with them.

As we've discussed, it's possible to write portable code in languages
like C, provided you're *very* careful. Good designers can achieve
this, and not compromise efficiency either. The obvious point is
though, what can the good designer achieve if he doesn't have to expend
unnecessary energies being conscious of issues that can be solved by
language design?

> Further, though abstraction is essential, the best designers are
> characterized by a much wider "abstraction bandwidth" than is
> common, and their ability to span many levels of abstraction in
> their thought is what allows them to create *efficient* designs,
> rather than just "correct" designs.  (BTW, designers with "high
> bandwidth" are always in short supply, and much of todays software
> reflects their absence.)

I agree. I do believe though that such designers achieve more with
better languages and tools.

> I have been frequently appalled to find that *system* programmers
> working at the lowest levels of OS design are often almost completly
> ignorant of the *machine* implications of the code that they write.

And this is a problem that's only getting worse. You can only fit so
much teaching into a 3-4 year degree, so many core concepts are being
removed from curriculums as it's considered important for a graduate to
have current skills.

> There is *no* substitute for a low-level understanding of what is
> actually going on in a system.  Unfortunately, higher level tools tend
> to further obscure actual system behavior by making it more "esoteric".

I agree. I feel it's a problem we'll never really solve, only mitigate.
higher level tools certainly do eliminate the need for a lot of
low-level understanding, but as your example illustrates, it's when the
problems arise that low-level understanding is necessary.

One has to ask though what an inexperienced developer was doing writing
process scheduler code!

> > Been there too. Time has proven it doesn't work well, and that test
> > driven development techniques provide more safety, and allow more
> > flexible forms of expression in the process, easing chafing.
>
> No argument here--test scaffolds have proven their worth many times
> over, yet their adoption as a standard part of any development has
> been widely rejected.  Maybe we're past that now...

A couple of fairly important tools, Ant (Essentially a portable "make"
on steroids) and JUnit (A Unit testing framework) have become massively
popular in the Java development arena, along with the phrase
"continuous integration", which more or less implies having a fully
automated build/test/deploy framework, to the extent that a machine on
the network checks out the code repository with each commit, builds it,
runs the entire test harness, and emails the person responsible for
violating a test case, should that occur.

The difference that this methodology has made to system quality (not
necessarily code quality) and development time is difficult to describe
in words.

One of the nicer side effects is it tends to free developers from the
'fear' that they might break something if they decide to make
relatively major change, since they can easily validate the system.
This has given rise to a practice known as refactoring, which good
developers did anyway, but now has been formalised to the extent that a
much larger segment of the developer community have embraced it.

> You know, I fundamentally agree with your point.  But I am sobered by
> the realization that 90% of the software we are talking about is code
> to download music or animate the "bounce" in a cursor bar.
>
> The fundamentally inessential and, at most, transient importance of the
> vase majority of code that is written, constrasted with the much smaller
> amount of truly essential, even critical, code, makes the argument for
> armies of "average" coders much less relevant.

This is true. But then, the 'commercial world' or more precisely, the
world where software itself is an end product is only one segment of
our industry, and I share your disdain for it. Trash will be trash
regardless of tools.

> The truth is that very little code needs to be really good.  If it's
> just 2% of all the code written, then it could all be done by 98th
> percentile people.  And, frankly, I don't really care whether the other
> 98% of code is written well, or even written at all.

I agree for the most part, but there's still a lot of code out there I
consider essential that's utter crap. Web Browsers are a good example.

> It reminds me of "Sturgeon's Law".  When, at a cocktail party, Theodore
> Sturgeon was asked what he did, he replied, "I write science fiction."
> The response was, "Science fiction!  90% of science fiction is crap!"
> To which Sturgeon replied, "Sir, 90% of *everything* is crap."

I'm a fan of this law too :-)

> So there is no real shortage of good designers, just a poor system of
> allocating them to projects.  Almost 90% of them are working on crap!

Michael, I hope you're right :-)

> It is a frequently stated goal of language designers to make bad things
> harder and good things easier.  What has never been studied is whether
> these tools actually improve the productivity and quality of output of
> the 2% of *great* programmers, on whom we all ultimately depend.
>
> Most programmer productivity (not to be confused with quality, but not
> unrelated) studies have shown *much* greater variance (50:1!) is
> attributed to individuals rather than to the tools they use.  My own
> experience supports this finding.  (BTW, "programmer productivity"
> has nothing to do with "lines of code" but with "problems solved".)

I have but my own experience to go on, but I've observed in my own work
that using more sophisticated tools has made me more productive.
There's solutions I can build in days using something like Java that
would takes weeks in C. Would the resultant C system be any better? I'd
have to say no, not likely.

Perhaps this puts me in the category of not being a good developer, but
if that's the case so be it ;-)

> I can appreciate an editor that pops up the full procedure interface
> for me as soon as I type a half-dozen characters of its name, but I
> note that it facilitates calling the *wrong* procedure as well as the
> right one.  I'm glad that it lets *me* choose.  ;-)

Ironcally, now that I'm using Ruby more and Java less, I'm finding
myself using a good old  fashioned text editor (the language is too
dynamic to allow a lot of autocompletion). I actually don't miss the
fancy IDE all that much.

> Actually, I was talking about the 8MB of code--most of it *not* within
> the Hellow World application--that will be executed in the act of
> painting "Hello, World!" on the screen.  The 8MB of libraries embedded
> in a trivial application are a separate issue (to which there are well
> known but seldom applied solutions).

I think this is a very overstated point - I can't really comment on
exactly how much code get's executed in order for a Java program to
push Hello World out stdout, but I'm pretty sure it's a lot less than
8mb ;-)

> > It's not ideal, but what's the alternative? If you don't follow this
> > road, a cap is placed on the possible solutions you can build. The
> > overheads introduced by high level abstraction systems is a very
> > interesting field of research, and one that great inroads into managing
> > has been made.
>
> I have no problem with the upper two or three "layers" being rather
> loosely bound--after all they are, or should be, in flux.
>
> My issue is with the dozen levels beneath these, which have not changed
> for a decade, and are much in need of collapsing into a much more
> efficient and, yes, less portable structure.  (BTW, have you noticed
> the steadily decreasing value of architectural portability?  ;-)

After 5 years of Java development I've not needed to worry :-) Besides
OS portability is very important these days, and while were only really
dealing with 2 or 3 machine architectures now, it's still an issue.

A good example is Linux, which needs no 'collapsing'. I'm fond of the
KISS principle when it comes to OS design though.

> Code which is executed many times per day by tens of millions of people
> can be justifiably optimized, since it will save *huge* amounts of human
> and machine resources to do so.

Can somebody send this to the developers of Microsoft Office 2003 ? :-)

> > I can see a time when massive parallel computing clusters 'churn'
> > through algorithms, fitting them to particular machines are problem
> > domains. Programming done by the human will be not much more than
> > assembling from vast libraries of prevalidated solutions. It doesn't
> > take much thinking into the future to imagine a time when software
> > complexity is so high that this is the only feasible solution to
> > building more complex systems.
>
> I remain radically suspicious of any approach that minimizes the
> fundamental role of conscious design--unless we plan to use genetic
> algorithms to evolve programs.  (I'm not entirely kidding here, but
> this is clearly not "around the corner".)

My point is that the tools *should* allow the humans to focus on
conscious design, spending less effort on fiddly details that should be
inconsequential today. This is one of the big issues with current
languages, to lesser and greater extents depending on which one we
choose to discuss.

> In this area, the fundamental limiters I see are complexity (human
> limiter), resources (human and machine limiters), and performance
> (machine limiter).
>
> I expect tools to help manage complexity, as you do, but I also
> require tools to manage human and machine resources, and machine
> performance.  In the (related) areas of resources and performance,
> tools can be used to help visualize usage so that a designer can
> make better informed tradeoffs.
>
> I am quite disappointed with the relatively poor quality of tools
> to correlate system design choiced (like class structures) with
> real system metrics, like memory resources and performance.  As
> we move into more concurrent systems, measures of locality will
> be extremely important, and remain largely unaddressed in the
> current generation of tools.

I think for the most part we agree on these issues - the tools you
invisage are much the same as the ones I do. Going a step further, once
we have tools that can gather such metrics, it's likely that the
techniques people will use to examine them and then 'tune' will be
disciplined enough that a large degree of automation will be possible.

> In the not too distant future, we will be able to treat today's large,
> "nonportable" bodies of code, together with the behavioral spec of the
> systems they run on, as a "source language" from which we will be able
> to compile a program with equivalent behavior on any system we choose.

I agree that this will happen too, but it's far enough away that we
have to make do with intermediate solutions in the mean time. Many,
many years of compiler research stands in the way of such things.
Meanwhile people are still arguing that compiler research done in the
1960's and 70's, such as using p-code machines as intermediate forms
along the path to better optimised solutions are a bad idea! Too
inefficient they say. For the most part, this is baloney. I tire of
issues that have been solved *years* ago continually being touted as
reasons to not move forward.

> The real problem with legacy applications is that we need them to
> continue to behave *exactly* the same, to avoid compatibility ripples.
>
> The best way forward has always been not to "port" legacy apps, but to
> *replace* them entirely with new subsystems, supporting new functions.

Indeed! Which is why I advocate moving to newer systems, like VMs! It's
the 'newer' systems that encourage reuse of legacy subsystems that
should be thrown in the trash that I dislike.

> The practical useful lifetime for code is measured in the cost of
> human change, not machine change, so having practical portablity
> may turn out to obstruct rather than expedite the move to a truly
> better solution.

Hmm. A decade of industry success to Java indicates that this is
probably not the case.

I'm reminded of the early 1990's when John Carmack announced that DOOM
would be written completely in C using cross compilers (they used NeXT
workstations). He was scoffed at by industry types at the time that
believed you couldn't write a game that pushed PC hardware to it's
absolute limits without hand-tuned assembly routines in the critical
sections. DOOM came along, and a lot of people ate humble pie.

More recently, John announced that ID's next 3D engine would probably
be written in Java. Again he is scoffed. I'm personally looking forward
to the pie eating that will most likely ensue :-)

Matt