[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: 64-bit extensions
> Mike Griebling (MG) wrote:
>
> > and Michael van Acken (MVA) wrote:
>
> MG > > It has never made much sense to not have any operations defined on
> MG > > BYTEs since they are a basic data type all computers support.
>
> Bytes are computer specific entities; *not* a data abstraction like
> the other basic types. You could, of course, argue that SHORTINT,
> LONGINT, etc. are also computer specific entities, but you have to
> strike a balance somewhere between the abstraction and the
> respresentation.
Actually bytes are no more computer specific than SHORTINTs. The true
mathematical abstraction would be an unbounded INTEGER. The current
Integers module in OOC comes closest to that ideal. Practically speaking
though, for the sake of efficiency, we designate data types which
correspond closest to actual target machine entities. This is the
abstraction I'm talking about -- not the mathematical abstraction.
From that point of view, a BYTE as an abstraction of the machine
makes sense as do SHORTINT, INTEGER, and LONGINT.
> MG > There _are_ other ways to do I/O without relying on ARRAY OF SYSTEM.BYTE.
> MG > For example in Oberon/F there is no concept of such a thing. Lowest
> MG > level I/O is done with the CHAR and ARRAY OF CHAR types. Of course,
> MG > you need the VAL() function to do the type casts.
>
> If CHAR becomes a 2-byte entity as you have suggested, then lowest
> level I/O wouldn't be done with CHAR; you'd have to use SHORTCHAR (or,
> as in Java, BYTE).
There is confusion here. I was talking about Oberon/F which uses
8-bit CHARs. The new CP uses the BYTE data type (8-bit signed
integer) in place of the CHAR in Oberon/F and the SYSTEM.BYTE
everywhere else.
> I'm confused as to why you complain about Wirth allowing "a way to
> break the type system," but then go on to say that using SYSTEM.VAL()
> is ok.
I agree that it is necessary to be able to break the type system in
selected places and the SYSTEM.VAL() has more localized effects than
a pervasive ARRAY OF SYSTEM.BYTE interface declaration. In other
words SYSTEM.VAL is a better way of breaking down types than the
ARRAY OF SYSTEM.BYTE.
> MVA > A Java back-end isn't really an option. You can't efficiently
> MVA > translate O2 to Java byte-code because there are lots of differences
> MVA > in the type and class concepts of the languages, and Java byte-code
> MVA > includes lots of Java type information.
>
> Maybe I'm reading more into this than is actually there, but I'm
> interpreting this to mean that, with OOC as it is now, implementing a
> Java byte-code backend would be very difficult. I can understand
> that.
I can't. Why is everyone saying that?
> At this point, I'd actually be more interested in a backend that
> produced Juice slim binaries. Has anyone looked into what the
> barriers to such a thing would be?
This would be next to impossible with OOC. The Juice slim binaries
are actually little more than compressed compiler syntax trees. OOC
discards all this information long before the back-end ever gets
called.
> I haven't heard much out of the Juice folks, does anyone know what
> directions they're taking? I mean, how are they dealing with Java
> compatibility?
I think they're saying that their product complements the Java
stuff. It doesn't sound like they are trying to compete. OTOH
they do show comparisons of their product with Java -- which, with
the current JIT compilers end up looking worse and worse all the
time. So, it seems they are a bit confused about what they want
to do with slim binaries.
> MG > As far as I can see the class concepts are part
> MG > of Java but have nothing to do with the Java VM.
>
> You still need class concepts for the runtime type info. Maybe
> investigation needs to be done into how type info is handled by the
> JVM, and what needs to be done to OOC to support this level of type
> info. This seems to me to be more important than name compatibility
> between basic types.
Basically the JVM uses signatures to identify types. The basic types
have preassigned signatures and other types have signature strings
built up based on known rules. I don't see anything here which
would make a OOC backend impossible or even difficult. The JVM
is just a stack-based interpreter similar to the early P-code
interpreters for Pascal. There's nothing magic here folks -- not
even anything very technologically sophisticated.
> MG > I agree it would be a nightmare and once again I stress that the
> MG > changes I was proposing would be for a different language -- it would
> MG > not be Oberon-2 anymore, obviously.
>
> Again I'm confused, what language do you want it to be? Java with
> Oberon-like syntax? Component Pascal? Or ???
I want Oberon-3. Sort of like Component Pascal except with the
extensions that I like. :-)
> MG > not "changing a single byte" there is no other solution for OOC. But you
> MG > will see the base C types make more sense since they define the SHORTINT
> MG > to be 16 bits.
>
> The *names* make more sense? Why?
Not the C names, just the correspondence to integers which is similar to
my earlier suggestion and the CP definition.
>
> MG > I believe that's why the CP designers went the way they did.
>
> I think they named the way they did so they could market as Java
> compatible.
What's wrong with that? It makes as much sense as the Wirth type
correspondences. Except Java is supporting a 64-bit integer as well.
Note: The Java address is still 32-bits.
> MVA > This isn't an extension since you are changing something that already
> MVA > exists. Adding a new character type (WCHAR, HUGECHAR, UNICHAR,
> MVA > LONGCHAR?) would be an option.
>
> I think I like LONGCHAR best, with UNICHAR a close second.
I'll go along with LONGCHAR. I just hope we won't need UTF support
in the future so we'll have to invent another entity. Since a type
inclusion thingie would have CHAR >= LONGCHAR(UNICHAR) >= UTFCHAR
we may have to introduce a HUGECHAR to support UTF.
> MG > Very well, I'm not tied to the particular name. I'm more concerned
> MG > with getting language support for an extended character range.
>
> In the current state of things, Java (the actual language) doesn't
> really do much to help, and in some cases actually hinders because
> much of what's really going on is hidden. The Java *libraries* (the
> so-called Core API) provide some cool stuff that have made my life
> easier (I'm working on a application that supports Korean Hangul
> characters). I don't see why OOC couldn't provide similar library
> support, especially if a LONGCHAR type (and related operations) is
> added.
Well, it sounds like you're intimately familiar with this stuff,
do you have any interface specifications?
> MVA > Why should we ever try to make O2 closer to the Java VM???
> MG >
> MG > Because it's designer's clearly planned for the future OSes. We
> MG > should be ready for the same. As I said, it will make a Java
> MG > byte-code back end simpler.
>
> My (perhaps paranoid) impression is that Sun intends the JVM to become
> *the* future OS. Would we even need a JVM if all Unix variants were
> binary compatible (with each other, and MS-Windows)?
JVM isn't an OS. It's a generic 70's-style stack-based processor
with no registers. Clearly a step backwards in terms of computer
hardware advancement.
> MG > > 3) OOC would be compatible (sort of) with the Component
> MG > > Pascal compiler.
> MVA >
> MVA > Why should we ever try to make O2 compatible with CP???
> MG >
> MG > Because it is the most mainstream of the Oberon-2 systems.
>
> Mainstream where? I certainly don't use it anymore. Have sales
> skyrocketed when I wasn't looking? :)
Well mainstream when compared to the other Oberon Systems which
are free and therefore have no sales at all. Is there a reason
you stopped using it?
> MG > (Ignoring the misnomer CP -- it should be called Oberon-3.)
>
> I don't agree. For one thing, it's not backwards compatible with O2,
> so it can't honestly be called Oberon-3. And besides, there are other
> Oberon variants vying for the title of Oberon-3. :)
I wasn't aware that backwards compatibility was a requirement for
the name Oberon-3. I would define Oberon-3 as a language which
fixes the problems in Oberon-2 and adds the most useful extensions.
Besides, it is backwards compatible if you supply an updated set of
libraries (and an automatic translator) for it. I know about the
other Oberon variants and they all have something to offer -- maybe
if we pick out the best of all elements. Actually, the CP docs
say that the refinements they made in CP was based on their
experience with Oberon-2.
Michael G.