Re: APL - Alive and Well!

On May 14, 3:49=A0pm, "David Liebtag" <DavidLieb...@[EMAIL PROTECTED]
>
wrote:
> > I thought that since APL2 runs under Linux that Linux would take care
> > of the hardware issues.
>
> Conceptually, operating systems are standardized sets of services for
doin=
g
> system level things like reading and writing files and registering and
> waiting for types of events. =A0Some of these things are hardware
related =
and
> Linux does indeed handle them identically on all hardware platforms.
>
> However, CPU instructions are at a lower level than the operating
system.
> For example, most CPUs sup****t some kind of instruction for copying
bytes
> from one location to another. =A0But, the actual instructions processed
by=

> different CPUs may be different binary values. =A0As a made-up example,
on=
 one
> system the copy-bytes instruction may be four bytes containing the value
> 0x12345678 followed by 2 four byte addresses followed by a four byte
lengt=
h.
> On another system the copy-bytes instruction may be eight bytes
containing=

> the value 0x8765432112345678 followed by 2 eight byte addresses followed
b=
y
> an eight byte length. =A0The compiler is responsible for converting the
ca=
ll
> to the C runtime library's memcpy routine into the binary instruction
that=

> is appropriate for the target system. =A0If you compile on the system
that=

> uses the two byte 0x5734 instruction, the resulting binary module will
not=

> run on the system that expects to see the four byte 0x34126756
instruction=
..
>
> At a real world level, the biggest difference between Linux on Intel PCs
a=
nd
> Linux on z/VM is that Intel machines use ASCII and z/VM uses EBCDIC.
=A0Th=
is
> means that they use different byte values to encode characters. =A0For
> example, in ASCII, blank characters are encoded as the binary value
0x20; =
in
> EBCDIC blanks are 0x40. =A0I'm pretty sure you can run Linux in ASCII
mode=
 on
> z/VM. =A0But, since many files on z/VM already contain EBCDIC data, it
may=
 be
> more useful to run it in EBCDIC mode. =A0So, if you compile a program,
lik=
e
> APL2, to run on Intel PCs and to use ASCII, if you tried to run it on
z/VM=

> in EBCDIC mode (which you can't because the intrsuction sets are
different=
)
> the program would almost certainly get very confused because all the
input=

> data that it is written to accept in ASCII would arrive in EBCDIC.
=A0Thes=
e
> are the kinds of issues that one has to consider when ****ting to various
> hardware platforms.
>
> Don't you love being an APLer so you don't have to worry about this
crap?
> :-)
>
> David Liebtag
> IBM APL Products and Services

So one of the biggest obstacle (ASCII vs EBCDIC) should be eliminated
once everything is Unicode - right?

It is not just APL that has(/had?) characterset problems.

I have been fighting codepages/characters/fonts kind of problem for a
very long time and have been/am looking forward for Unicode to solve
them for decades now.

I do not know how many utilities I have to change codes between
codepages.

J, Dialog and APL2 all have sup****t for Unicode so the APL community
is yet again long way ahead of everyone else.