ISA-independent programming language
mihai cartoaje
and the property that the result of programs is independent of ISA.
Starting from C, modifications would include,
- arithmetic is two's complement
- the sizes of variables are uniquely defined by the programming
language
- variables are stored in memory in little-endian format
- the size of pointers is programmer-selectable
- the value of floating-point formulas is uniquely defined by the
programming language
- others I have not thought of
I am posting it to comp.arch because google is buggy on comp.lang
Peter "Firefly" Lund
> - variables are stored in memory in little-endian format
> - the size of pointers is programmer-selectable
Why not work on making the size of the pointers and the endianness of
variables less visible?
How would a C-like language look if you couldn't use sizeof? Start with
memmove/memcpy, malloc, and memset.
You could also declare that pointers and integers not have such a close
relationshiip -- a pointer would be compatible with intptr_t but everyting
else would require lots of swearing (casting -- perhaps even
syntactically special casting).
Get inspiration from Modula-2 if you need examples of how to do it.
You could also make the casting system safer: change it from (desired
type) to (current type -> desired type).
-Peter
mihai cartoaje
> I believe it is possible for a programming language to have pointers,
> and the property that the result of programs is independent of ISA.
I have forgotten to add, "if the program is not reading itself."
Torben Ægidius Mogensen
> I believe it is possible for a programming language to have pointers,
> and the property that the result of programs is independent of ISA.
>
> Starting from C, modifications would include,
>
> - arithmetic is two's complement
> - the sizes of variables are uniquely defined by the programming
> language
> - variables are stored in memory in little-endian format
> - the size of pointers is programmer-selectable
> - the value of floating-point formulas is uniquely defined by the
> programming language
> - others I have not thought of
Many languages are (mostly) defined independent of a particular ISA or
machine, i.e, there are no or only a few "implementation dependent" or
"unspecified" parts in the specification of the language. Integers
are either unbounded or explicitly bounded with least and largest
elements (like Pascal without the machine-specific "integer" and
"maxint") words. Pointers can only be compared for equality, so you
can't see which of two pointers are higher in memory. Floating point
is defined to be a specific standard, e.g., IEEE or a
language-specified special format. And so on.
Scheme is one example of such a language. I'm not entirely sure about
floating point numbers, but I believe the rest is not dependent on
implementation. Integers are unbounded, for example.
Torben
mihai cartoaje
Peter "Firefly" Lund has written,
> Why not work on making the size of the pointers and the endianness of
> variables less visible?
>
> How would a C-like language look if you couldn't use sizeof? Start with
In C, the size of a structure can be calculated with pointer
arithmetic.
> You could also declare that pointers and integers not have such a close
> relationshiip -- a pointer would be compatible with intptr_t but everyting
> else would require lots of swearing (casting -- perhaps even
> syntactically special casting).
I don't understand. Is intptr_t a pointer to an integer or an union of
a pointer and an integer?
> Get inspiration from Modula-2 if you need examples of how to do it.
I shall look it up next time I pass by the university library.
Peter "Firefly" Lund
> In C, the size of a structure can be calculated with pointer
> arithmetic.
And what would C look like if you couldn't get at the structure size
through that loophole? (hey, I'm trying to make you think! Don't evade
the issue ;) )
> I don't understand. Is intptr_t a pointer to an integer or an union of
> a pointer and an integer?
It's a standard C type. It's an int that is big enough to hold any
pointer (C pointers to different types don't have to be the same size).
>> Get inspiration from Modula-2 if you need examples of how to do it.
>
> I shall look it up next time I pass by the university library.
Google?
-Peter
mihai cartoaje
> And what would C look like if you couldn't get at the structure size
> through that loophole? (hey, I'm trying to make you think! Don't evade
> the issue ;) )
If we could not ask for the size of a structure or calculate it
ourselves, it would not be possible to allocate memory for a structure
in the linux kernel using kmalloc.
John Savard
wrote, in part:
>I am posting it to comp.arch because google is buggy on comp.lang
Try comp.lang.misc; comp.lang isn't a real group, but people can post to
it because other news servers have bugs. Similarly with
rec.arts.sf.starwars; the real group is rec.arts.sf.starwars.misc.
John Savard
http://www.quadibloc.com/index.html
_________________________________________
Usenet Zone Free Binaries Usenet Server
More than 120,000 groups
Unlimited download
http://www.usenetzone.com to open account
Peter "Firefly" Lund
Nope. You are wrong. Take a look at Modula-2 for inspiration.
Here's a hint: why do /you/, the programmer have to know the size? Isn't
it enough thatg the compiler can figure it out?
Anyway, the alternative you seem to advocate is to use the same sizes on
all platforms. Do you want to restrict yourself to 32-bit pointers on
64-bit machines or do you want to pad 32-bit pointers on 32-bit machines
just so they can have the same size as on 64-bit machines?
-Peter
mihai cartoaje
> Anyway, the alternative you seem to advocate is to use the same sizes on
> all platforms. Do you want to restrict yourself to 32-bit pointers on
> 64-bit machines or do you want to pad 32-bit pointers on 32-bit machines
> just so they can have the same size as on 64-bit machines?
A solution is 64 bit pointers by default and a "addresssize n" compiler
directive. When in a source file, "addresssize n" signals the compiler
that pointers are n bits.
Hank Oredson
news:1123740376.4...@g43g2000cwa.googlegroups.com...
>I believe it is possible for a programming language to have pointers,
> and the property that the result of programs is independent of ISA.
>
> Starting from C, modifications would include,
Perhaps not a good idea to start from C if you want ISA independence.
> - arithmetic is two's complement
It doesn't matter, the compiler takes care of it.
A number is a number.
It must have a defined range, whether there are one
or two representations for zero should not matter to me.
> - the sizes of variables are uniquely defined by the programming
> language
It doesn't matter, the compiler takes care of it.
Why should I care what size they are?
> - variables are stored in memory in little-endian format
It doesn't matter, the compiler takes care of it.
The compiler should not allow you to see this detail.
The use of aliases, casts and unions to expose such details
should be avoided.
> - the size of pointers is programmer-selectable
It doesn't matter, the compiler takes care of it.
That is, if the language needs pointers.
Perhaps it should use indices instead.
> - the value of floating-point formulas is uniquely defined by the
> programming language
Exactly, the compiler takes care of it.
> - others I have not thought of
The compiler takes care of it.
That's why we have compilers (grin).
> I am posting it to comp.arch because google is buggy on comp.lang
--
... Hank
http://home.earthlink.net/~horedson
http://home.earthlink.net/~w0rli
Hank Oredson
It cannot do so, the program lives in I space, the concept of
"reading" lives in D space. The compiler will take care of this.
Perhaps you did not attend Harvard?
Anton Ertl
>"mihai cartoaje" <rep...@yahoo.ca> wrote in message
>news:1123740376.4...@g43g2000cwa.googlegroups.com...
>>I believe it is possible for a programming language to have pointers,
>> and the property that the result of programs is independent of ISA.
>>
>> Starting from C, modifications would include,
>
>Perhaps not a good idea to start from C if you want ISA independence.
In my experience, C is the worst in this respect.
Forth is the counterexamble to the ideas of the OP (few things are
fixed), as well as to those you and others have suggested (nothing is
hidden), yet in my experience has a very high portability between
different architectures; I generally don't test for portability
between 32-bit and 64-bit, big-endian and little-endian machines, it
just works. There were only one or two portability bugs in my Forth
code in the last fifteen years (and probably hundreds in my C code).
Most of the portability bugs I have in C come from its large zoo of
integer types, so you may want to avoid that when designing a new
language.
I remember one architecture portability bug a program of mine had on a
Forth system 16 years ago: in C terms, on one machine characters were
signed, and on another they were unsigned. On a standard Forth
system, they are unsigned, so this bug could not happen on a standard
system (or rather, it would be a bug of the system, not the program).
Hmm, thinking about it, that Forth system was written in C, so it
probably actually was a portability bug in the C program for Forth
system, not in my Forth program.
>> - arithmetic is two's complement
>
>It doesn't matter, the compiler takes care of it.
>A number is a number.
>It must have a defined range, whether there are one
>or two representations for zero should not matter to me.
It does, if the language supports bitwise operations on integers.
You could get rid of the question of signed-number representation by
supporting bitwise operations only on unsigned numbers, where there's
only one binary representation; of course, if your language should
also support the decimal machines of the 1950s, then you should not
allow bitwise operations on unsigned numbers, either.
While we are catering for obsolete architectures, are there still
machines around with non-2s-complement signed integer representations?
>> - the sizes of variables are uniquely defined by the programming
>> language
>
>It doesn't matter, the compiler takes care of it.
>Why should I care what size they are?
If the programming language supports asking for the size, the language
designer has to think about it.
>> - variables are stored in memory in little-endian format
>
>It doesn't matter, the compiler takes care of it.
>The compiler should not allow you to see this detail.
The compiler should allow what the language allows.
>> - the size of pointers is programmer-selectable
>
>It doesn't matter, the compiler takes care of it.
>That is, if the language needs pointers.
>Perhaps it should use indices instead.
Back to Fortran-77?
A good example of a language where the size of pointers is completely
transparent is Java. They can be 32 bits, the can be 64 bits,
whatever, the programmer has no way of determining that. There are
many other such languages, but I find it remarkable in Java, because
a) that property extends to the JVM, and b) Java nails down all the
other sizes down to the bit, the way the OP suggested.
>> - the value of floating-point formulas is uniquely defined by the
>> programming language
>
>Exactly, the compiler takes care of it.
That's extremely tough (probably impossible) if you care for FP
performance at all.
Java tried decreeing that, but from postings by David Chase I got the
impression that it did not work out well. The problems are:
- Differences in the basic operations in FP hardware; if you cater for
non-2s-complement architectures, you should certainly cater for (the
much more widely available) non-IEEE-754 FP.
Even the almost-IEEE-754 80387 has problems here: it always uses a
16-bit exponent, even when the rounding mode is single-precision or
double-precision. This results in differences when there is an fp
overflow or (gradual) underflow, unless you store and reload the
result of every FP operation. Well, maybe this is better with SSE2
(does that support gradual underflow?), but there are still a lot of
Pentium IIIs and Athlon XPs around that don't have SSE2.
- For transcendental operations, that would require locking down the
algorithm for computing them; if faster or more accurate algorithms
were available (maybe in hardware, as on the 80387), they could not be
used.
- anton
--
M. Anton Ertl Some things have to be seen to be believed
an...@mips.complang.tuwien.ac.at Most things have to be believed to be seen
http://www.complang.tuwien.ac.at/anton/home.html
Peter "Firefly" Lund
> A solution is 64 bit pointers by default and a "addresssize n" compiler
> directive. When in a source file, "addresssize n" signals the compiler
> that pointers are n bits.
The addresssize directive will give you portability problems -- large
projects combine codes from many places. What if one piece depends on a
32-bit addresssize and other pieces depend on a size of 64 bits?
-Peter
Hank Oredson
news:2005Aug1...@mips.complang.tuwien.ac.at...
The language needs the correct data types for the operations
it supports. If a bitset is needed, the language should provide it.
> You could get rid of the question of signed-number representation by
> supporting bitwise operations only on unsigned numbers, where there's
> only one binary representation; of course, if your language should
> also support the decimal machines of the 1950s, then you should not
> allow bitwise operations on unsigned numbers, either.
I still think this is a language and compiler issue only.
The underlying representation should not be visible.
> While we are catering for obsolete architectures, are there still
> machines around with non-2s-complement signed integer representations?
>
>>> - the sizes of variables are uniquely defined by the programming
>>> language
>>
>>It doesn't matter, the compiler takes care of it.
>>Why should I care what size they are?
>
> If the programming language supports asking for the size, the language
> designer has to think about it.
That was my point.
The language should not support such a construct.
What does "size of a pointer" mean, and why should I care?
>>> - variables are stored in memory in little-endian format
>>
>>It doesn't matter, the compiler takes care of it.
>>The compiler should not allow you to see this detail.
>
> The compiler should allow what the language allows.
The language should not expose the underlying representation.
Assignment of a pointer value to an interger (for example)
should simply not be possible.
>>> - the size of pointers is programmer-selectable
>>
>>It doesn't matter, the compiler takes care of it.
>>That is, if the language needs pointers.
>>Perhaps it should use indices instead.
>
> Back to Fortran-77?
Ah, you got it (grin).
> A good example of a language where the size of pointers is completely
> transparent is Java. They can be 32 bits, the can be 64 bits,
> whatever, the programmer has no way of determining that. There are
> many other such languages, but I find it remarkable in Java, because
> a) that property extends to the JVM, and b) Java nails down all the
> other sizes down to the bit, the way the OP suggested.
>
>>> - the value of floating-point formulas is uniquely defined by the
>>> programming language
>>
>>Exactly, the compiler takes care of it.
>
> That's extremely tough (probably impossible) if you care for FP
> performance at all.
It just has some implications for the design of the language.
Certainly the language might support various floating point
value types, with different behavior wrt NAN, denormals, etc.
> Java tried decreeing that, but from postings by David Chase I got the
> impression that it did not work out well. The problems are:
>
> - Differences in the basic operations in FP hardware; if you cater for
> non-2s-complement architectures, you should certainly cater for (the
> much more widely available) non-IEEE-754 FP.
>
> Even the almost-IEEE-754 80387 has problems here: it always uses a
> 16-bit exponent, even when the rounding mode is single-precision or
> double-precision. This results in differences when there is an fp
> overflow or (gradual) underflow, unless you store and reload the
> result of every FP operation. Well, maybe this is better with SSE2
> (does that support gradual underflow?), but there are still a lot of
> Pentium IIIs and Athlon XPs around that don't have SSE2.
>
> - For transcendental operations, that would require locking down the
> algorithm for computing them; if faster or more accurate algorithms
> were available (maybe in hardware, as on the 80387), they could not be
> used.
I would say "providing appropriate algorithms and data types."
As soon as the camel can get it's nose into the tent (by allowing
any visibility of underlying representation) programmers will
figure out how to pull the whole beasty inside. Thus my other
comments about aliases and unions and other ways of trying
to convince the compiler to treat, e.g., a pointer as a bitset
or a fixed point number.
Of course my tongue is in my cheek as usual, and I personally
would find such a language useless. But I'm willing to write the
underlying "stuff" like FP operations and ISRs for each hardware
I encounter, and do that in assembler. But I'm a hardware person
first and a software person second (smile).
David W. Schroth
> "Hank Oredson" <hore...@earthlink.net> writes:
>
>>"mihai cartoaje" <rep...@yahoo.ca> wrote in message
>>news:1123740376.4...@g43g2000cwa.googlegroups.com...
>>
>
>
> It does, if the language supports bitwise operations on integers.
>
> You could get rid of the question of signed-number representation by
> supporting bitwise operations only on unsigned numbers, where there's
> only one binary representation; of course, if your language should
> also support the decimal machines of the 1950s, then you should not
> allow bitwise operations on unsigned numbers, either.
>
> While we are catering for obsolete architectures, are there still
> machines around with non-2s-complement signed integer representations?
>
Yes, there are.
>
<snip>
> - anton
Dan Koren
news:ddt12v$2138$1...@si05.rsvl.unisys.com...
> Anton Ertl wrote:
>>
>> While we are catering for obsolete architectures, are there still
>> machines around with non-2s-complement signed integer representations?
>
> Yes, there are.
>
Which?
dk
Michel Hack
Hank Oredson wrote:
> > - arithmetic is two's complement
>
> It doesn't matter, the compiler takes care of it.
> A number is a number.
> It must have a defined range, whether there are one
> or two representations for zero should not matter to me.
>
> > - the sizes of variables are uniquely defined by the programming
> > language
>
> It doesn't matter, the compiler takes care of it.
> Why should I care what size they are?
>
> > - variables are stored in memory in little-endian format
>
> It doesn't matter, the compiler takes care of it.
> The compiler should not allow you to see this detail.
> The use of aliases, casts and unions to expose such details
> should be avoided.
[etc.]
Interesting discussion of desirable properties for a CLOSED
ENVIRONMENT.
If this environment is to communicate with the outside world, it also
needs a mechanism to define an external format for its data, one where
the representation is of course of critical importance.
Even if the environment only wanted to communicate with itself, it
would
need some defined external storage representation, if only to support
one
version to talk to the next one. But who wants a programming language
that cannot communicate with the outside world? Surely you want users
to
provide input data or files, and the only way a program can document
what
values it accepts is for the language to give it access to the relevant
constraints. Sometimes the only constraint is physical resources, and
if
those are exhausted, the program is allowed simply to die, or to report
that
it ran out of resources and could not handle a request. Many languages
with
a-priori unbounded integer or rational precision, or with symbolic
evaluation
capabilities, can be like that. Most programming languages have
constrained
datum types however, and in that case the constraints must be explicit.
A totally different paradigm presents itself when the purpose of the
program
is to communicate with somebody else -- e.g. when one wants to program
that
interface to an external format. In this case one wants
fully-specified
types, and compiler warnings if those types are unavailable or
uneconomical
on a particular platform.
Languages that try to do both experience a severe tension between
conflicting
type requirements -- witness the horrible zoo of C integer types, and
the
tension between implicit types like "int", "short", "long" and explicit
types
like int_32 -- and this does not even address issues like Endianness or
bit
fields.
For my part, I prefer to code in assembler -- true WYSIWYG programming,
at
least for the platforms I use. (I know that there are "smart"
assemblers out
there that can be just as pernicious as High-Level language compilers.)
Michel.
Andrew Reilly
> "Anton Ertl" <an...@mips.complang.tuwien.ac.at> wrote in message
> news:2005Aug1...@mips.complang.tuwien.ac.at...
>> "Hank Oredson" <hore...@earthlink.net> writes:
>>>It doesn't matter, the compiler takes care of it.
>>>A number is a number.
>>>It must have a defined range, whether there are one
>>>or two representations for zero should not matter to me.
>>
>> It does, if the language supports bitwise operations on integers.
>
> The language needs the correct data types for the operations
> it supports. If a bitset is needed, the language should provide it.
This is a foolish position to hold, in my opinion. Bitwise operators are
fundamentally mathematical, and sensibly operate on integers (mostly
unsigned, but there are uses on signed integers, if you can assume the
representation, 2-s complement being the most common.)
Do you suggest that evenness be tested by actual division and
multiplication, rather than masking off the LSB?
Sure, lots of the sorts of operations that result in "arithmetic" and
"logical" operations being mixed in expressions can alternatively be
written in terms of multiplication, division and modulo operations. You
even get to use arbitrary length buffers and intervals. However in real
systems efficiency matters. One can recognise that by making one's
modulo arithmetic based on powers of two, many of these operations
simplify to bit-wise operations, and a dramatic reduction in execution
cost can be achieved, in some circumstances.
It is concievable that many of the common patterns of use could be
recognised by compilers as peep-hole optimisations, and the efficient
bit-wise operations made where arithmetic operations are specified.
Frankly, I don't want to have to rely on that sort of algorithm selection
behind my back. If the language advocates are going to rely on that sort
of thing, then those transformations must be part of the language
specification so that they can be relied on by programmers.
Or, more simply, just allow intermixing of arithmetic and logical
operations.
> Of course my tongue is in my cheek as usual, and I personally
> would find such a language useless. But I'm willing to write the
> underlying "stuff" like FP operations and ISRs for each hardware
> I encounter, and do that in assembler. But I'm a hardware person
> first and a software person second (smile).
I wonder whether it is indeed possible to design a language that is
simultaneously "safe", or "portable", or whatever the original poster was
looking for, and also useful. I'll choose sharp and useful, myself, as a
general rule, but I do find myself mixing Matlab, Python, Scheme and Java
into my C and assembler these days. Safe and easy are useful benefits in
situations where speed isn't important. Many things that wait for a human
come into that category.
Cheers,
--
Andrew
Hank Oredson
news:pan.2005.08.16....@areilly.bpc-users.org...
> On Tue, 16 Aug 2005 15:35:18 +0000, Hank Oredson wrote:
>
>> "Anton Ertl" <an...@mips.complang.tuwien.ac.at> wrote in message
>> news:2005Aug1...@mips.complang.tuwien.ac.at...
>>> "Hank Oredson" <hore...@earthlink.net> writes:
>>>>It doesn't matter, the compiler takes care of it.
>>>>A number is a number.
>>>>It must have a defined range, whether there are one
>>>>or two representations for zero should not matter to me.
>>>
>>> It does, if the language supports bitwise operations on integers.
>>
>> The language needs the correct data types for the operations
>> it supports. If a bitset is needed, the language should provide it.
>
> This is a foolish position to hold, in my opinion. Bitwise operators are
> fundamentally mathematical, and sensibly operate on integers (mostly
> unsigned, but there are uses on signed integers, if you can assume the
> representation, 2-s complement being the most common.)
Um ... what is foolish about suggesting the language provide
the features needed? How else would they be provided?
> Do you suggest that evenness be tested by actual division and
> multiplication, rather than masking off the LSB?
I suggested no such thing. I suggested the language provide the
features needed. If you need the ability to know if a given number
is even or odd, the language must provide such a construct.
> Sure, lots of the sorts of operations that result in "arithmetic" and
> "logical" operations being mixed in expressions can alternatively be
> written in terms of multiplication, division and modulo operations. You
> even get to use arbitrary length buffers and intervals. However in real
> systems efficiency matters. One can recognise that by making one's
> modulo arithmetic based on powers of two, many of these operations
> simplify to bit-wise operations, and a dramatic reduction in execution
> cost can be achieved, in some circumstances.
Thus the language must provide what you need.
How else would they be provided?
> It is concievable that many of the common patterns of use could be
> recognised by compilers as peep-hole optimisations, and the efficient
> bit-wise operations made where arithmetic operations are specified.
> Frankly, I don't want to have to rely on that sort of algorithm selection
> behind my back. If the language advocates are going to rely on that sort
> of thing, then those transformations must be part of the language
> specification so that they can be relied on by programmers.
Like I said above.
> Or, more simply, just allow intermixing of arithmetic and logical
> operations.
How have I suggested these things might be NOT allowed?
>> Of course my tongue is in my cheek as usual, and I personally
>> would find such a language useless. But I'm willing to write the
>> underlying "stuff" like FP operations and ISRs for each hardware
>> I encounter, and do that in assembler. But I'm a hardware person
>> first and a software person second (smile).
>
> I wonder whether it is indeed possible to design a language that is
> simultaneously "safe", or "portable", or whatever the original poster was
> looking for, and also useful. I'll choose sharp and useful, myself, as a
> general rule, but I do find myself mixing Matlab, Python, Scheme and Java
> into my C and assembler these days. Safe and easy are useful benefits in
> situations where speed isn't important. Many things that wait for a human
> come into that category.
The original poster was looking for a language that had pointers,
and was also ISA indepenent. This is really pretty simple. Just a
small matter of language definition and compiler construction.
The question is really about compilers and libraries, nothing more.
The other questions, such as efficiency, speed of execution,
complexity of writing programs, are just obfuscation.
The answer to his question is an unqualified "yes".
All the rest is implementation detail.
Hank Oredson
news:1124218524....@z14g2000cwz.googlegroups.com...
>
> Hank Oredson wrote:
>
>> > - arithmetic is two's complement
>>
>> It doesn't matter, the compiler takes care of it.
>> A number is a number.
>> It must have a defined range, whether there are one
>> or two representations for zero should not matter to me.
>>
>> > - the sizes of variables are uniquely defined by the programming
>> > language
>>
>> It doesn't matter, the compiler takes care of it.
>> Why should I care what size they are?
>>
>> > - variables are stored in memory in little-endian format
>>
>> It doesn't matter, the compiler takes care of it.
>> The compiler should not allow you to see this detail.
>> The use of aliases, casts and unions to expose such details
>> should be avoided.
>
> [etc.]
>
> Interesting discussion of desirable properties for a CLOSED
> ENVIRONMENT.
Any language is a "CLOSED ENVIRONMENT."
> If this environment is to communicate with the outside world, it also
> needs a mechanism to define an external format for its data, one where
> the representation is of course of critical importance.
Of course. The compiler must deal with this.
> Even if the environment only wanted to communicate with itself, it
> would
> need some defined external storage representation, if only to support
> one
> version to talk to the next one. But who wants a programming language
> that cannot communicate with the outside world? Surely you want users
> to
> provide input data or files, and the only way a program can document
> what
> values it accepts is for the language to give it access to the relevant
> constraints. Sometimes the only constraint is physical resources, and
> if
> those are exhausted, the program is allowed simply to die, or to report
> that
> it ran out of resources and could not handle a request. Many languages
> with
> a-priori unbounded integer or rational precision, or with symbolic
> evaluation
> capabilities, can be like that. Most programming languages have
> constrained
> datum types however, and in that case the constraints must be explicit.
You state the obvious requirements on the language.
> A totally different paradigm presents itself when the purpose of the
> program
> is to communicate with somebody else -- e.g. when one wants to program
> that
> interface to an external format. In this case one wants
> fully-specified
> types, and compiler warnings if those types are unavailable or
> uneconomical
> on a particular platform.
Again, you state the obvious.
> Languages that try to do both experience a severe tension between
> conflicting
> type requirements -- witness the horrible zoo of C integer types, and
> the
> tension between implicit types like "int", "short", "long" and explicit
> types
> like int_32 -- and this does not even address issues like Endianness or
> bit
> fields.
Oh my. Life is hard. The language in question is not C.
> For my part, I prefer to code in assembler -- true WYSIWYG programming,
> at
> least for the platforms I use. (I know that there are "smart"
> assemblers out
> there that can be just as pernicious as High-Level language compilers.)
So you agree ... such a language is possible: pointers and ISA independent.
You might not use it, I might not use it, but creating one is simple.
Andrew Reilly
> "Andrew Reilly" <andrew-...@areilly.bpc-users.org> wrote in message
> news:pan.2005.08.16....@areilly.bpc-users.org...
>> On Tue, 16 Aug 2005 15:35:18 +0000, Hank Oredson wrote:
>>
>>> "Anton Ertl" <an...@mips.complang.tuwien.ac.at> wrote in message
>>> news:2005Aug1...@mips.complang.tuwien.ac.at...
>>>> "Hank Oredson" <hore...@earthlink.net> writes:
>>>>>It doesn't matter, the compiler takes care of it.
>>>>>A number is a number.
>>>>>It must have a defined range, whether there are one
>>>>>or two representations for zero should not matter to me.
>>>>
>>>> It does, if the language supports bitwise operations on integers.
>>>
>>> The language needs the correct data types for the operations
>>> it supports. If a bitset is needed, the language should provide it.
>>
>> This is a foolish position to hold, in my opinion. Bitwise operators are
>> fundamentally mathematical, and sensibly operate on integers (mostly
>> unsigned, but there are uses on signed integers, if you can assume the
>> representation, 2-s complement being the most common.)
>
> Um ... what is foolish about suggesting the language provide
> the features needed? How else would they be provided?
I'm sorry. Misunderstanding on my part. When you interjected that the
lagnuage should provide bitsets when needed, I assumed that you were
suggesting that only bitsets, and not integers, should be able to
participate in bitwise logical operations. It's a common enough assertion
among language designers (and C-haters). For example, Eiffel started out
that way, but has recently been revised to allow bitwise operations on
integers (and more than one INTEGER) type, too.
Cheers,
--
Andrew
Anton Ertl
[Using arithmetic instead of bitwise operations]
>It is concievable that many of the common patterns of use could be
>recognised by compilers as peep-hole optimisations, and the efficient
>bit-wise operations made where arithmetic operations are specified.
>Frankly, I don't want to have to rely on that sort of algorithm selection
>behind my back. If the language advocates are going to rely on that sort
>of thing, then those transformations must be part of the language
>specification so that they can be relied on by programmers.
One example where the compiler typcially cannot optimize it as well as
the programmer is n/2 in C99, where n is a signed variable and the
programmer knows that n>=0. The programmer can optimize this to n>>1,
but the compiler usually has to cater for the possibility of negative
n, and make sure that a proper symmertric division is performed. Ok,
in this case a workaround for the programmer would be to write
(signed)(((unsigned)n)/2), but I find n>>1 more readable; also,
typically the programmer won't think about the resulting inefficiency
and won't use this workaround.
It's even worse if the programmer actually wanted a floored division
by 2, not a symmetrical one; he could just have written n>>1, but if
he is required to use arithmetic operations, it becomes much more
complex, and I doubt that the compiler will undo the resulting mess
and actually turn it into n>>1.
Anton Ertl
>"Andrew Reilly" <andrew-...@areilly.bpc-users.org> wrote in message
>news:pan.2005.08.16....@areilly.bpc-users.org...
>> On Tue, 16 Aug 2005 15:35:18 +0000, Hank Oredson wrote:
>>
>>> "Anton Ertl" <an...@mips.complang.tuwien.ac.at> wrote in message
>>> news:2005Aug1...@mips.complang.tuwien.ac.at...
>>>> "Hank Oredson" <hore...@earthlink.net> writes:
>>>>>It doesn't matter, the compiler takes care of it.
>>>>>A number is a number.
>>>>>It must have a defined range, whether there are one
>>>>>or two representations for zero should not matter to me.
>>>>
>>>> It does, if the language supports bitwise operations on integers.
>>>
>>> The language needs the correct data types for the operations
>>> it supports. If a bitset is needed, the language should provide it.
>I suggested no such thing. I suggested the language provide the
>features needed.
Well, if bitwise operations on integers are needed, and the language
provides them, the language also has to specify what they mean, e.g.,
by specifying the binary representation of unsigned and signed
integers. Then a number is not just a number, it's also a sequence of
bits.
Andrew Reilly
> It's even worse if the programmer actually wanted a floored division
> by 2, not a symmetrical one; he could just have written n>>1, but if
> he is required to use arithmetic operations, it becomes much more
> complex, and I doubt that the compiler will undo the resulting mess
> and actually turn it into n>>1.
Exactly. I find that I require floored division (in support of
round-to-nearest) far more often than symmetrical (round to zero)
division, and so signed shifting is really what I'm after in the first
place.
--
Andrew
Hank Oredson
Yes, I was suggesting that the language provide whatever is needed.
That includes bitwise operations on integers.
I also suggest that there might be more than one flavor of integer
provided, that conversions between flavors should be provided,
etc. etc. Whatever is needed. But all those operations should not
expose the underlying representation to the programmer.
i.e. the language construct "integer" is not the same thing as the
hardware construct "integer". It is the job of the compiler to
take care of the details of that mapping.
Hank Oredson
news:2005Aug1...@mips.complang.tuwien.ac.at...
> "Hank Oredson" <hore...@earthlink.net> writes:
>>"Andrew Reilly" <andrew-...@areilly.bpc-users.org> wrote in message
>>news:pan.2005.08.16....@areilly.bpc-users.org...
>>> On Tue, 16 Aug 2005 15:35:18 +0000, Hank Oredson wrote:
>>>
>>>> "Anton Ertl" <an...@mips.complang.tuwien.ac.at> wrote in message
>>>> news:2005Aug1...@mips.complang.tuwien.ac.at...
>>>>> "Hank Oredson" <hore...@earthlink.net> writes:
>>>>>>It doesn't matter, the compiler takes care of it.
>>>>>>A number is a number.
>>>>>>It must have a defined range, whether there are one
>>>>>>or two representations for zero should not matter to me.
>>>>>
>>>>> It does, if the language supports bitwise operations on integers.
>>>>
>>>> The language needs the correct data types for the operations
>>>> it supports. If a bitset is needed, the language should provide it.
> ...
>>I suggested no such thing. I suggested the language provide the
>>features needed.
>
> Well, if bitwise operations on integers are needed, and the language
> provides them, the language also has to specify what they mean, e.g.,
> by specifying the binary representation of unsigned and signed
> integers. Then a number is not just a number, it's also a sequence of
> bits.
Exactly.
One might want more than one flavor of integer.
However this is all a diversion from the topic of the thread,
which was a language with pointers that was ISA independent.
Seongbae Park
...
> One example where the compiler typcially cannot optimize it as well as
> the programmer is n/2 in C99, where n is a signed variable and the
> programmer knows that n>=0. The programmer can optimize this to n>>1,
> but the compiler usually has to cater for the possibility of negative
> n, and make sure that a proper symmertric division is performed. Ok,
> in this case a workaround for the programmer would be to write
> (signed)(((unsigned)n)/2), but I find n>>1 more readable; also,
> typically the programmer won't think about the resulting inefficiency
> and won't use this workaround.
n/2 of "int n" is not complicated.
In SPARC assembly:
! %r1 == n
! %r2 == n/2
srl %r1,31,%r3 ! srl = shift-right-logical
add %r1,%r3,%r3
sra %r3,1,%r2 ! sra = shift-right-arithmetic
Any divide by 2^C can be handled in a similar manner.
--
#pragma ident "Seongbae Park, compiler, http://blogs.sun.com/seongbae/"
Terje Mathisen
> n/2 of "int n" is not complicated.
>
> In SPARC assembly:
> ! %r1 == n
> ! %r2 == n/2
> srl %r1,31,%r3 ! srl = shift-right-logical
> add %r1,%r3,%r3
> sra %r3,1,%r2 ! sra = shift-right-arithmetic
I.e. n/2 = (n - sign_bit(n)) >> 1
>
> Any divide by 2^C can be handled in a similar manner.
Right.
Terje
--
- <Terje.M...@hda.hydro.com>
"almost all programming can be viewed as an exercise in caching"
mihai cartoaje
Hank Oredson wrote:
> It doesn't matter, the compiler takes care of it.
> Why should I care what size they are?
If I had posted on comp.lang.misc, I would have written about a
isa-independent and compiler-independent programming language. I left
out the compiler-independent part to post to comp.arch. If different C
compilers have a different range for int, it is possible for a program
to know what compiler it is on by testing it.
For a real world application, the PCI configuration space contains
32-bit data. To read it, svgalib uses "long int".
mihai cartoaje
Linux on the 970 runs 32 and 64 bits programs. Maybe they have an idea
how to mix the two.
Ken Hagan
>
> Do you suggest that evenness be tested by actual division and
> multiplication, rather than masking off the LSB?
Well I'd *define* evenness as "x%2==0".
Since that happens to be valid syntax, I'd be sorely tempted to
write exactly that and I'd expect the compiler to sort it out.
I also have a modest preference for making casts and truncating
conversions explicit, so I suppose that marks me out as one who
prefers to express intent rather than implementation, even when
it is at the cost of (source code) verbosity.
I also have an irrational hatred of "unsigned integers", which I
regard as an oxymoron. (I say irrational, since even if others
believe that they can justify their venom, and they do, I don't
believe that I can justify mine.)
To take up a later remark; yes, this does require a peephole
optimisation but in my experience compilers are pretty good at
those (and would certainly be good at *that* one if the language
didn't support shifting on integers).
Hank Oredson
news:de1rbu$fi8$1$8302...@news.demon.co.uk...
> Andrew Reilly wrote:
>>
>> Do you suggest that evenness be tested by actual division and
>> multiplication, rather than masking off the LSB?
>
> Well I'd *define* evenness as "x%2==0".
>
> Since that happens to be valid syntax, I'd be sorely tempted to
> write exactly that and I'd expect the compiler to sort it out.
>
> I also have a modest preference for making casts and truncating
> conversions explicit, so I suppose that marks me out as one who
> prefers to express intent rather than implementation, even when
> it is at the cost of (source code) verbosity.
>
> I also have an irrational hatred of "unsigned integers", which I
> regard as an oxymoron. (I say irrational, since even if others
> believe that they can justify their venom, and they do, I don't
> believe that I can justify mine.)
Would it help if they were called "counting number" or "indices"?
> To take up a later remark; yes, this does require a peephole
> optimisation but in my experience compilers are pretty good at
> those (and would certainly be good at *that* one if the language
> didn't support shifting on integers).
Hank Oredson
But some (or all? don't have spec handy) of the 32 bit values are unsigned.
Del Cecchi
language. With pointers and all that.
del
--
Del Cecchi
"This post is my own and doesn’t necessarily represent IBM’s positions,
strategies or opinions.”
Anton Ertl
>Andrew Reilly wrote:
>>
>> Do you suggest that evenness be tested by actual division and
>> multiplication, rather than masking off the LSB?
>
>Well I'd *define* evenness as "x%2==0".
Let's see:
[b1:~/tmp:1916] cat xxx.c
int foo(int x)
{
return x%2==0;
}
[b1:~/tmp:1914] ccc -c -O5 xxx.c
[b1:~/tmp:1915] objdump -d xxx.o
xxx.o: file format elf64-alpha
Disassembly of section .text:
0000000000000000 <foo>:
0: 10 00 f0 43 sextl a0,a0
4: 02 30 00 46 and a0,0x1,t1
8: 05 00 00 ea blt a0,20 <foo+0x20>
c: a0 15 40 40 cmpeq t1,0,v0
10: 01 80 fa 6b ret zero,(ra),0x1
14: 00 00 fe 2f unop
18: 00 00 fe 2f unop
1c: 00 00 fe 2f unop
20: fa ff 5f e4 beq t1,c <foo+0xc>
24: fe ff 42 20 lda t1,-2(t1)
28: a0 15 40 40 cmpeq t1,0,v0
2c: 00 00 fe 2f unop
30: 01 80 fa 6b ret zero,(ra),0x1
[b1:~/tmp:1920] ccc -V
Compaq C V6.4-005 on Linux 2.4.18-4.1nhdcustom alpha
Hmm, I think there are better ways to implement this. Let's see if
gcc does better:
[b1:~/tmp:1917] gcc -c -O3 xxx.c
[b1:~/tmp:1918] objdump -d xxx.o
xxx.o: file format elf64-alpha
Disassembly of section .text:
0000000000000000 <foo>:
0: 00 30 00 46 and a0,0x1,v0
4: 00 38 00 44 xor v0,0x1,v0
8: 01 80 fa 6b ret zero,(ra),0x1
[b1:~/tmp:1921] gcc -v
...
gcc version 2.95.2 19991024 (release)
Ok, that looks optimal to me.
>Since that happens to be valid syntax, I'd be sorely tempted to
>write exactly that and I'd expect the compiler to sort it out.
Sometimes compilers surprise me by how good they are, and sometimes by
how bad they are. If I want performance, I have learned that trying
to get the compiler to optimize higher-level code leads to much
wasting of time and to brittle performance (i.e., the next compiler or
even a different version of the same compiler could fail to optimize
what worked well on the version I tried).
Of course, that has to be balanced against cases where doing an
optimization by hand blocks other optimizations by the compiler, but
I don't think that this problem arises in the case of x%2 vs. x&1.
Terje Mathisen
> "Ken Hagan" <K.H...@thermoteknix.co.uk> wrote in message
>>I also have an irrational hatred of "unsigned integers", which I
>>regard as an oxymoron. (I say irrational, since even if others
>>believe that they can justify their venom, and they do, I don't
>>believe that I can justify mine.)
> >
> Would it help if they were called "counting number" or "indices"?
Modula-2 CARDINAL anyone?
Nick Maclaren
Terje Mathisen <terje.m...@hda.hydro.com> wrote:
>Hank Oredson wrote:
>
>> "Ken Hagan" <K.H...@thermoteknix.co.uk> wrote in message
>>>I also have an irrational hatred of "unsigned integers", which I
>>>regard as an oxymoron. (I say irrational, since even if others
>>>believe that they can justify their venom, and they do, I don't
>>>believe that I can justify mine.)
>> >
>> Would it help if they were called "counting number" or "indices"?
>
>Modula-2 CARDINAL anyone?
Well, since I never found a specification of any of the Modulas that
was even as precise as that of Fortran II, I have no idea whether
that is an adequate idea or a disaster. Wirth didn't believe in
specifications and his followers, er, followed :-(
The reasons that modern 'unsigned integers' are a disaster are that
they mix up various mathematical concepts and omit all checking of
when one breaks down and turns into another.
Addition, subtraction and multiplication are performed modulo N,
and left shifting is analogous.
Division and remaindering are performed as if in Z, with truncation,
and right shifting is analogous.
Logical operations are performed as if in Z, with the number represented
in binary.
Ordering is also performed as if in Z.
That's a mess, and the mess leads to errors. Undetectable errors.
Regards,
Nick Maclaren.
Peter "Firefly" Lund
>> I also have an irrational hatred of "unsigned integers", which I
>> regard as an oxymoron. (I say irrational, since even if others
>> believe that they can justify their venom, and they do, I don't
>> believe that I can justify mine.)
>
> Would it help if they were called "counting number" or "indices"?
Or "cardinal"?
Modula-2 really is a nice language.
-Peter
wclo...@lanl.gov
Nick Maclaren wrote:
> <snip>
>
> Well, since I never found a specification of any of the Modulas that
> was even as precise as that of Fortran II, I have no idea whether
> that is an adequate idea or a disaster. Wirth didn't believe in
> specifications and his followers, er, followed :-(
Then you never looked at the ISO standard for Modula 2? The standard
uses VDM to provide a very detailed specification. However, the use of
VDM and the definition of a (overly large) library resulted in a
standard an order of magnitude larger than what Wirth considered
necessary. It was a shock to followers of Wirth when his ~50 page
description expanded to 700+ pages when standardized. It was a
disappointment to them that standardization took so long that Modula 2
was no longer in significant use upon completion (94?).
Nick Maclaren
<wclo...@lanl.gov> wrote:
>Nick Maclaren wrote:
>>
>> Well, since I never found a specification of any of the Modulas that
>> was even as precise as that of Fortran II, I have no idea whether
>> that is an adequate idea or a disaster. Wirth didn't believe in
>> specifications and his followers, er, followed :-(
>>
No. For reasons that you describe.
>The standard
>uses VDM to provide a very detailed specification. However, the use of
>VDM and the definition of a (overly large) library resulted in a
>standard an order of magnitude larger than what Wirth considered
>necessary. It was a shock to followers of Wirth when his ~50 page
>description expanded to 700+ pages when standardized. It was a
>disappointment to them that standardization took so long that Modula 2
>was no longer in significant use upon completion (94?).
As with Pascal!
And how compatible was the standard with the Modula 2 that Wirth
exposed to the world?
Fortran and C++ managed to steer between the Scylla of a hopelessly
ambiguous and incomplete language and the Charybdis of missing the
boat, but most attempts to standardise a hacked-together language
have foundered on one or the other. There is no substitute for
starting with a clean design.
Regards,
Nick Maclaren.
Peter "Firefly" Lund
> have foundered on one or the other. There is no substitute for
> starting with a clean design.
I guess that's why Perl works so well.
-Peter
mihai cartoaje
Nick Maclaren
Never confuse popularity with technical quality.
Regards,
Nick Maclaren.
Torben Ægidius Mogensen
> Fortran and C++ managed to steer between the Scylla of a hopelessly
> ambiguous and incomplete language and the Charybdis of missing the
> boat,
I'm not sure C++ has avoided being ambiguous and incomplete. I'm
willing to accept that it avoided incompleteness, but it is voefully
ambiguous.
> but most attempts to standardise a hacked-together language have
> foundered on one or the other.
Including that of C++.
> There is no substitute for starting with a clean design.
Very true, but C++ didn't.
Torben
Nick Maclaren
In article <7zwtmis...@tyr.diku.dk>,
tor...@tyr.diku.dk (=?iso-8859-1?q?Torben_=C6gidius_Mogensen?=) writes:
|>
|> > Fortran and C++ managed to steer between the Scylla of a hopelessly
|> > ambiguous and incomplete language and the Charybdis of missing the
|> > boat,
|>
|> I'm not sure C++ has avoided being ambiguous and incomplete. I'm
|> willing to accept that it avoided incompleteness, but it is voefully
|> ambiguous.
Not by comparison with C99 :-(
I agree that it is not a shining example (Fortran is better, but
still not good), but it isn't actually unusable. C99, many aspects
of C90, and a large proportion of POSIX really are unusable.
|> > but most attempts to standardise a hacked-together language have
|> > foundered on one or the other.
|>
|> Including that of C++.
Hmm. Would you describe it as actually unusable?
Regards,
Nick Maclaren.
Torben Ægidius Mogensen
No, it was the satement about lack of ambiguity I objected to. While
C++ is nominally standardized, the standard is so complex that (to my
knowledge) no C++ compiler conforms exactly to the standard.
Additionally, the behaviour is in many cases unspecified or
imlementation dependent.
Torben
Nick Maclaren
In article <7zr7cq0...@tyr.diku.dk>,
tor...@tyr.diku.dk (=?iso-8859-1?q?Torben_=C6gidius_Mogensen?=) writes:
|>
|> > |> > but most attempts to standardise a hacked-together language have
|> > |> > foundered on one or the other.
|> > |>
|> > |> Including that of C++.
|> >
|> > Hmm. Would you describe it as actually unusable?
|>
|> No, it was the satement about lack of ambiguity I objected to. While
|> C++ is nominally standardized, the standard is so complex that (to my
|> knowledge) no C++ compiler conforms exactly to the standard.
|> Additionally, the behaviour is in many cases unspecified or
|> imlementation dependent.
I can assure you that C99 and, to a great extent, POSIX are orders
of magnitude worse. There are large and critical areas where nobody
has a clue even what the intent of the standard is - and I mean in
principle, not just in detail.
C++ has at least made an ATTEMPT to distinguish constraints on the
program from constraints on the implementation. Can you imagine a
standard where there is DELIBERATE ambiguity over whether the
implementor or programmer is required to ensure that something does
or doesn't happen? Well, such standards exist - and it is part of
my job to be a link between the users and the vendors :-(
C++ may be bad, but it hasn't foundered in the way that Algol 68,
Modula 2 and C99 have. It is probably marginally more successful
than POSIX, which isn't exactly an accolade.
Regards,
Nick Maclaren.
wclo...@lanl.gov
Nick Maclaren wrote:
> In article <1124392489....@z14g2000cwz.googlegroups.com>,
> <wclo...@lanl.gov> wrote:
>
> >The standard
> >uses VDM to provide a very detailed specification. However, the use of
> >VDM and the definition of a (overly large) library resulted in a
> >standard an order of magnitude larger than what Wirth considered
> >necessary. It was a shock to followers of Wirth when his ~50 page
> >description expanded to 700+ pages when standardized. It was a
> >disappointment to them that standardization took so long that Modula 2
> >was no longer in significant use upon completion (94?).
>
> As with Pascal!
Pascal was still popular. Its problem was that it was only a slight
improvement on Wirth's initial description, and hence was severly
limited in its usefulness. Extended Pascal was not only late, but not
as clearly defined as some other languages, and incompatible with many
extensions to Pascal.
>
> And how compatible was the standard with the Modula 2 that Wirth
> exposed to the world?
In theory I believe it was highly compatible with Wirth's description.
However I suspect it was not very compatible with real world Modula 2
code. Much of the problem I suspect would be duee to Wirth's failure to
define a standard library for Modula 2 (his libraries developed in
"Software Engineering(?)" were suposedly inconsistent from edition to
editon, were never claimed to be standard, and were insufficent for
widespread portability.). Other code may have relied on compiler
specific interpretations of Wirth's description. Reliance on compiler
specific aspects for 1% of the code causes problems for code more than
100 lines long.
> <snip>
Nick Maclaren
<wclo...@lanl.gov> wrote:
>
>> >... It was a
>> >disappointment to them that standardization took so long that Modula 2
>> >was no longer in significant use upon completion (94?).
>>
>> As with Pascal!
>
>Not really. The first Pascal standard came out in the late 70's, while
>Pascal was still popular. Its problem was that it was only a slight
>improvement on Wirth's initial description, and hence was severly
>limited in its usefulness. Extended Pascal was not only late, but not
>as clearly defined as some other languages, and incompatible with many
>extensions to Pascal.
Eh? I have just checked up to remind myself, and ISO Pascal was only
STARTED about 1977 and wasn't delivered until 1982. By then, it was
essentially just an IBM PC language and the control of the language
had been, er, taken over by Borland. Outside that community, it was
more-or-less defunct.
To make things worse, ISO sorted out the array problems, which
prevented it from being useful for numeric code, but ANSI demanded
a standard without that.
>> And how compatible was the standard with the Modula 2 that Wirth
>> exposed to the world?
>
>In theory I believe it was highly compatible with Wirth's description.
>However I suspect it was not very compatible with real world Modula 2
>code. Much of the problem I suspect would be duee to Wirth's failure to
>define a standard library for Modula 2 (his libraries developed in
>"Software Engineering(?)" were suposedly inconsistent from edition to
>editon, were never claimed to be standard, and were insufficent for
>widespread portability.). Other code may have relied on compiler
>specific interpretations of Wirth's description. Reliance on compiler
>specific aspects for 1% of the code causes problems for code more than
>100 lines long.
Right. And it is not the only language to make that mistake.
Regards,
Nick Maclaren.
Anne & Lynn Wheeler
nm...@cus.cam.ac.uk (Nick Maclaren) writes:
> Eh? I have just checked up to remind myself, and ISO Pascal was only
> STARTED about 1977 and wasn't delivered until 1982. By then, it was
> essentially just an IBM PC language and the control of the language
> had been, er, taken over by Borland. Outside that community, it was
> more-or-less defunct.
in the 70s, one of the vlsi tools group did a pascal for the
mainframe, which was then used to develop some number of internal vlsi
design tools. it was also released (in late 70s) as a mainframe
product (pascal/vs)and later ported to the rs/6000 (big motivation was
ths internal tools). one of the (external) product guys did sit on the
iso committee.
in the early/mid 90s ... some number of the vlsi tools were spun off
to outside companies (that specialized in vlsi design tools) .. and a
lot of these tools had to be ported to other (primarily workstation)
platforms.
the mainframe/rs6000 pascal had quite a bit of work done on it
supporting the major (vlsi design tool) production
applications.
trying to get production applications that were possibly 50k-60k lines
of pascal to some of these other platforms ... was a major
undertaking; especially since these pascals appear to have never been
used for anything other than student jobs (and in at least one case,
the organization had outsourced its pascal support, the organization
was maybe 30 minute drive, depending on traffic conditions ... but the
actual support organization was 12 time zones away).
minor past references:
http://www.garlic.com/~lynn/2004d.html#71 What terminology reflects the "first" computer language ?
http://www.garlic.com/~lynn/2004q.html#35 [Lit.] Buffer overruns
http://www.garlic.com/~lynn/2005e.html#0 [Lit.] Buffer overruns
http://www.garlic.com/~lynn/2005e.html#1 [Lit.] Buffer overruns
--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
Nick Maclaren
Anne & Lynn Wheeler <ly...@garlic.com> wrote:
>
>nm...@cus.cam.ac.uk (Nick Maclaren) writes:
>> Eh? I have just checked up to remind myself, and ISO Pascal was only
>> STARTED about 1977 and wasn't delivered until 1982. By then, it was
>> essentially just an IBM PC language and the control of the language
>> had been, er, taken over by Borland. Outside that community, it was
>> more-or-less defunct.
>
>in the 70s, one of the vlsi tools group did a pascal for the
>mainframe, which was then used to develop some number of internal vlsi
>design tools. it was also released (in late 70s) as a mainframe
>product (pascal/vs)and later ported to the rs/6000 (big motivation was
>ths internal tools). one of the (external) product guys did sit on the
>iso committee.
Yes. I was the relevant project manager in SEAS/SHARE Europe/GSE
a bit later. I can assure you that customer interest in that product
was somewhat limited :-)
>in the early/mid 90s ... some number of the vlsi tools were spun off
>to outside companies (that specialized in vlsi design tools) .. and a
>lot of these tools had to be ported to other (primarily workstation)
>platforms.
>
>the mainframe/rs6000 pascal had quite a bit of work done on it
>supporting the major (vlsi design tool) production
>applications.
>
>trying to get production applications that were possibly 50k-60k lines
>of pascal to some of these other platforms ... was a major
>undertaking; especially since these pascals appear to have never been
>used for anything other than student jobs (and in at least one case,
>the organization had outsourced its pascal support, the organization
>was maybe 30 minute drive, depending on traffic conditions ... but the
>actual support organization was 12 time zones away).
Quite. I had to port a line-truncated ICL 1900 Algol 60 program
to IBM (Delft) Algol in 1987, which was an interestingly bizarre
exercise. My boss did not realise what a fluke it was that I
knew both dialects - hands up other readers of this group who
can say the same :-)
And Let's stay off Cobol F ....
Regards,
Nick Maclaren.
Stephen Fuld
"Dan Koren" <dank...@yahoo.com> wrote in message
news:43020f5e$1...@news.meer.net...
> "David W. Schroth" <David....@unisys.com> wrote in message
> news:ddt12v$2138$1...@si05.rsvl.unisys.com...
>> Anton Ertl wrote:
>>>
>>> While we are catering for obsolete architectures, are there still
>>> machines around with non-2s-complement signed integer representations?
>>
>> Yes, there are.
The descendants of the Univac 1100 Series (under newer names) are still
being sold and used productivly by many big customers. They use 1s
compliment integers.
There may be others.
--
- Stephen Fuld
e-mail address disguised to prevent spam
mihai cartoaje
>> If the programming language supports asking for the size, the language
>> designer has to think about it.
> That was my point.
> The language should not support such a construct.
> What does "size of a pointer" mean, and why should I care?
"size of a pointer" means the number of bytes a pointer occupies in
memory.
By "have pointers", I meant being able to read or write anywhere in
address space, as if a program is in physical address mode and writes
to a video card's memory aperture after reading it's address from the
PCI configuration space.
Some programs do their own memory management, like Quake or the linux
kernel. I know of no way this can be done without the size of pointers
becoming visible.
Hank Oredson
> Hank Oredson has written,
>
>>> If the programming language supports asking for the size, the language
>>> designer has to think about it.
>
>> That was my point.
>> The language should not support such a construct.
>> What does "size of a pointer" mean, and why should I care?
>
> "size of a pointer" means the number of bytes a pointer occupies in
> memory.
Assuming pointers "occupy bytes", but again, why should I care?
> By "have pointers", I meant being able to read or write anywhere in
> address space, as if a program is in physical address mode and writes
> to a video card's memory aperture after reading it's address from the
> PCI configuration space.
That is a much different definition of "pointer" than I'm used to.
> Some programs do their own memory management, like Quake or the linux
> kernel. I know of no way this can be done without the size of pointers
> becoming visible.
Oh. Never mind.
You seem to have "pointer" confused with "memory address."
We were talking about very different things.
John Savard
<hore...@earthlink.net> wrote, in part:
>"mihai cartoaje" <rep...@yahoo.ca> wrote in message
>news:1124569541....@f14g2000cwb.googlegroups.com...
>> Hank Oredson has written,
>>> That was my point.
>>> The language should not support such a construct.
>>> What does "size of a pointer" mean, and why should I care?
>> "size of a pointer" means the number of bytes a pointer occupies in
>> memory.
>Assuming pointers "occupy bytes", but again, why should I care?
All things in memory occupy memory. And memory is usually made up of
octets.
>> Some programs do their own memory management, like Quake or the linux
>> kernel. I know of no way this can be done without the size of pointers
>> becoming visible.
>Oh. Never mind.
>You seem to have "pointer" confused with "memory address."
>We were talking about very different things.
A pointer is usually implemented as a memory address. Even if, in a
language independent of the underlying architecture, the use of pointers
is so restricted as to prevent their being manipulated in ways that
disclose this.
Presumably pointers cannot even be temporarily saved to a file, if their
size is concealed from the programmer.
John Savard
http://www.quadibloc.com/index.html
_________________________________________
Usenet Zone Free Binaries Usenet Server
More than 140,000 groups
Unlimited download
http://www.usenetzone.com to open account
John Savard
<s.f...@PleaseRemove.att.net> wrote, in part:
>The descendants of the Univac 1100 Series (under newer names) are still
>being sold and used productivly by many big customers. They use 1s
>compliment integers.
>There may be others.
Except for obscure machines used by the military, it is very likely
there are no others, since for virtually all purposes these days,
microprocessors are used for computing.
Although some of the Control Data machines also used one's complement
integers, building on the Univac experience of their engineers, this was
not true of any Cray machine, for example.
John Savard
<hore...@earthlink.net> wrote, in part:
>The underlying representation should not be visible.
That's true for what you and I would think of as a programming language
independent of instruction set architecture.
But apparently the original poster had some very different ideas.
Perhaps he simply means a dialect of C that would run equally well on an
x86, a DEC Alpha, a PowerPC running in little-endian mode, an Itanium
running in little-endian mode... while allowing you to do all the nasty
tricks provided by the C language.
Thus, all the hardware features _common_ to those architectures are
assumed to be true, and exposed to the programmer. Those that differ are
smoothed over.
Hank Oredson
news:4308839...@news.usenetzone.com...
> On Sat, 20 Aug 2005 21:52:02 GMT, "Hank Oredson"
> <hore...@earthlink.net> wrote, in part:
>>"mihai cartoaje" <rep...@yahoo.ca> wrote in message
>>news:1124569541....@f14g2000cwb.googlegroups.com...
>>> Hank Oredson has written,
>
>>>> That was my point.
>>>> The language should not support such a construct.
>>>> What does "size of a pointer" mean, and why should I care?
>
>>> "size of a pointer" means the number of bytes a pointer occupies in
>>> memory.
>
>>Assuming pointers "occupy bytes", but again, why should I care?
>
> All things in memory occupy memory. And memory is usually made up of
> octets.
Um ... well ... Univac 1100 / 2200 memory is made of words.
Same for many other machines.
It's that "usually" thing ;-)
>>> Some programs do their own memory management, like Quake or the linux
>>> kernel. I know of no way this can be done without the size of pointers
>>> becoming visible.
>
>>Oh. Never mind.
>>You seem to have "pointer" confused with "memory address."
>>We were talking about very different things.
>
> A pointer is usually implemented as a memory address. Even if, in a
> language independent of the underlying architecture, the use of pointers
> is so restricted as to prevent their being manipulated in ways that
> disclose this.
Yes, my point exactly. An ISA independent language with
pointers will have to hide such things, or will have to provide
mechanisms for discovering such things as the size of a
pointer. I am still curious why anyone might care.
> Presumably pointers cannot even be temporarily saved to a file, if their
> size is concealed from the programmer.
Yes, exactly.
They might not be in a memory space known to the programmer.
There are many different ways a pointer might be implemented.
My point was that "pointer" is a language abstraction.
Saving one to a file is meaningless, unless the language specifies a
meaning for that operation.
Not all the world is C, Unix and byte addressable memory.
Hank Oredson
> On Tue, 16 Aug 2005 15:35:18 GMT, "Hank Oredson"
> <hore...@earthlink.net> wrote, in part:
>
>>The underlying representation should not be visible.
>
> That's true for what you and I would think of as a programming language
> independent of instruction set architecture.
Grin.
> But apparently the original poster had some very different ideas.
Indeed.
> Perhaps he simply means a dialect of C that would run equally well on an
> x86, a DEC Alpha, a PowerPC running in little-endian mode, an Itanium
> running in little-endian mode... while allowing you to do all the nasty
> tricks provided by the C language.
Perhaps C++ or C# or ...
> Thus, all the hardware features _common_ to those architectures are
> assumed to be true, and exposed to the programmer. Those that differ are
> smoothed over.
And thus we do not have an ISA independent language.
Exactly what I've been giggling about ...
Anne & Lynn Wheeler
the mainframe tcp/ip product was also implemented in pascal/vs.
there were some issues with its thruput ... getting 44kbytes/sec
consuming nearly full 3090 cpu.
i did the product modifications for rfc 1044 support and in some
testing at cray research between a cray and a 4341-clone ... it was
peaking at the channel interface speed using only modest amount cpu
(about 1mbyte/sec using maybe 200-300kips).
past rfc 1044 posts
http://www.garlic.com/~lynn/subnetwork.html#1044
that testing trip sticks in my mind ... we were on nw flight sitting
on the runway at sfo taking off nearly 20 minutes late (for
minneapolis). part way thru the flight, i noticed a number of people
congregated in the back of the plane. i went back to find out what all
the interest was about ... and it turns out they were discussing the
big quake that hit very shortly after we left the ground.
Terje Mathisen
> the mainframe tcp/ip product was also implemented in pascal/vs.
>
> there were some issues with its thruput ... getting 44kbytes/sec
> consuming nearly full 3090 cpu.
Ouch!
I used the same Pascal compiler to implement/hack Kermit, with
modifications to allow it to work effectively across terminal protocol
emulators.
This mostly consisted of code to implement large packets (2K instead of
79 chars) and to get rid of VT100 cursor escape sequences.
I got about the same throughput as IBM's 3270 PC/AT got over the same
lines, using (afair) less host cpu.
> i did the product modifications for rfc 1044 support and in some
> testing at cray research between a cray and a 4341-clone ... it was
> peaking at the channel interface speed using only modest amount cpu
> (about 1mbyte/sec using maybe 200-300kips).
:-)
> that testing trip sticks in my mind ... we were on nw flight sitting
> on the runway at sfo taking off nearly 20 minutes late (for
> minneapolis). part way thru the flight, i noticed a number of people
> congregated in the back of the plane. i went back to find out what all
> the interest was about ... and it turns out they were discussing the
> big quake that hit very shortly after we left the ground.
That would indeed make it memorable. :-(
Jan Vorbrüggen
> on the runway at sfo taking off nearly 20 minutes late (for
> minneapolis). part way thru the flight, i noticed a number of people
> congregated in the back of the plane. i went back to find out what all
> the interest was about ... and it turns out they were discussing the
> big quake that hit very shortly after we left the ground.
Ah, _that_ day! I was on a very much delayed Eastern Flight, which made
it to Atlanta just after the last possible connecting flight had depar-
ted, and they shoved us into a hotel after midnight without any dinner
and only a vending machine selling soft drinks on the floor. Watching
CNN, after 25 minutes of every half hour was spent on the San Francisco
quake, there was 5 minutes of world news, including about 30 seconds
on Honecker being thrown out of office. The California governor, who
strangely enough was travelling in Germany at the time, got more air
time 8-|. Bizarre.
Jan
mihai cartoaje
---------------------------------------------------------------
It might be possible for a programming language to allow programs to
read and write anywhere in their memory address space, and to have the
property that the result of any program is independent of the isa and
of the compiler, if the program is not reading or timing itself.
Starting from C, modifications would include,
- arithmetic is two's complement
- the sizes of variables are uniquely defined by the programming
language
- variables are stored in memory in little-endian format
- the size of pointers is programmer-selectable
- the value of floating-point formulas is uniquely defined by the
programming language
- others I have not thought of
Nick Maclaren
In article <1124709615.4...@g49g2000cwa.googlegroups.com>,
"mihai cartoaje" <rep...@yahoo.ca> writes:
|>
|> It might be possible for a programming language to allow programs to
|> read and write anywhere in their memory address space, and to have the
|> property that the result of any program is independent of the isa and
|> of the compiler, if the program is not reading or timing itself.
And is not optimised (including most parallelisation) etc.
|> Starting from C, modifications would include,
|>
|> - arithmetic is two's complement
|> - the sizes of variables are uniquely defined by the programming
|> language
|> - variables are stored in memory in little-endian format
|> - the size of pointers is programmer-selectable
|> - the value of floating-point formulas is uniquely defined by the
|> programming language
|> - others I have not thought of
Indeed. Too many others to describe in a posting.
If you are going there, which is a pretty ghastly idea anyway,
don't start from C. Anyway, if you think that is a desirable
objective, what's wrong with Java?
Regards,
Nick Maclaren.
Stephen Fuld
Or you could take a different approach -
Start from Fortran IV
Done!
David Gay
"Hank Oredson" <hore...@earthlink.net> writes:
> > By "have pointers", I meant being able to read or write anywhere in
> > address space, as if a program is in physical address mode and writes
> > to a video card's memory aperture after reading it's address from the
> > PCI configuration space.
>
> That is a much different definition of "pointer" than I'm used to.
>
> > Some programs do their own memory management, like Quake or the linux
> > kernel. I know of no way this can be done without the size of pointers
> > becoming visible.
>
> Oh. Never mind.
> You seem to have "pointer" confused with "memory address."
> We were talking about very different things.
To be fair, many people seem to claim that pointer != reference. I assume
that perspective comes from a "pointer = memory address" perspective
(I'm unclear what the difference would be otherwise, except possibly
pointer = reference+offset).
--
David Gay
dg...@acm.org
Nick Maclaren
In article <s71zmra...@beryl.CS.Berkeley.EDU>,
David Gay <dg...@beryl.CS.Berkeley.EDU> writes:
|> "Hank Oredson" <hore...@earthlink.net> writes:
|> > > By "have pointers", I meant being able to read or write anywhere in
|> > > address space, as if a program is in physical address mode and writes
|> > > to a video card's memory aperture after reading it's address from the
|> > > PCI configuration space.
|> >
|> > That is a much different definition of "pointer" than I'm used to.
Indeed.
|> > > Some programs do their own memory management, like Quake or the linux
|> > > kernel. I know of no way this can be done without the size of pointers
|> > > becoming visible.
I do, but it's decidedly non-trivial. It is much easier to specify
a Unix-like memory model.
|> > Oh. Never mind.
|> > You seem to have "pointer" confused with "memory address."
|> > We were talking about very different things.
|>
|> To be fair, many people seem to claim that pointer != reference. I assume
|> that perspective comes from a "pointer = memory address" perspective
|> (I'm unclear what the difference would be otherwise, except possibly
|> pointer = reference+offset).
pointer = capability
pointer = token (for fetching/storing data)
and so on ...
Regards,
Nick Maclaren.
David Gay
nm...@cus.cam.ac.uk (Nick Maclaren) writes:
Those sound like what might be meant by reference too ;-) The question
wasn't how to define pointer, but a comment that a belief that
"pointer = memory address" might be why some people think that
"pointer != reference".
--
David Gay
dg...@acm.org
glen herrmannsfeldt
> "mihai cartoaje" <rep...@yahoo.ca> wrote in message
> news:1124709615.4...@g49g2000cwa.googlegroups.com...
(snip)
>>Starting from C, modifications would include,
>>- arithmetic is two's complement
>>- the sizes of variables are uniquely defined by the programming
>>language
>>- variables are stored in memory in little-endian format
>>- the size of pointers is programmer-selectable
>>- the value of floating-point formulas is uniquely defined by the
>>programming language
>>- others I have not thought of
> Or you could take a different approach -
> Start from Fortran IV
I don't believe that any Fortran version has those requirements.
Java comes pretty close, though.
-- glen
Stephen Fuld
"glen herrmannsfeldt" <g...@ugcs.caltech.edu> wrote in message
news:05Cdnel9yMu...@comcast.com...
If you mean the "required" changes to C listed above, I certainly agree, but
I don't think that was the original question. That was, could you implement
a programming language that was independent of ISA, and later an added
requirement that was independent of the length of a pointer. I take that
operationally to mean that no source code changes would be required to port
the protram to a computer with a different ISA or different size of
pointers.
I was trying to point out that, rather than starting from C and making
modifications, you could start froma different place, namely Fortran IV and
then you wouldn't need any of the kinds of modifications listed above. It
was a (perhaps lame) attempt to try to broaden the OPs perspective that C
was the be all and end all of programming languages.
> Java comes pretty close, though.
Yes, agreed.
mihai cartoaje
requirement for a program result to be independent of the compiler. I
added it afterward.
The length of a pointer being user-selectable is part of my solution.
Hank Oredson
news:s71vf1x...@beryl.CS.Berkeley.EDU...
Babble-mode on.
Actually, the point I was getting at was that "pointer" is a
language abstraction, which might or might not map in some
way to one or more memory addresses, while "memory
address" is an ISA specific construct. e.g. a "memory
address" might refer to an octet, or maybe a "word" or
perhaps something else depending on the physical
arrangment of memory bits in the particular ISA.
For the case of C, there is that befuddlement about "an integer
of some flavor can hold a pointer value". Some languages have
pointers that don't "have a value", but are (as Nick points
out) a way to access or make visible a "something" which
might be a value or a record or a capability or the result of
triggering an SQL query (never mind, that is a "cursor")
or ... all those interesting issues surrounding the confusion
between the thing, the location of the thing, the name of
the thing, etc.. Cue Lewis Carroll here ...
So perhaps "reference" is ok, in it's generic sense, but I
personally kinda like "token" since it does not have the
C like association with "dereference". "Detoken" ???
Perhaps we need a new term. I will suggest "setter" for
that thing which is like a "pointer" but should go through
a different door ... (Where is /BAH anyway?).
Oh, wait, this is not afc ... sorry ...
Babble-mode off now.
Hank Oredson
> When I have written the first post in this thread, I left out the
> requirement for a program result to be independent of the compiler. I
> added it afterward.
That is simply a requirement on the compiler.
> The length of a pointer being user-selectable is part of my solution.
Why should a pointer have a "length"?
glen herrmannsfeldt
(snip)
>>>Or you could take a different approach -
>>>Start from Fortran IV
>>I don't believe that any Fortran version has those requirements.
> If you mean the "required" changes to C listed above, I certainly agree, but
> I don't think that was the original question. That was, could you implement
> a programming language that was independent of ISA, and later an added
> requirement that was independent of the length of a pointer. I take that
> operationally to mean that no source code changes would be required to port
> the protram to a computer with a different ISA or different size of
> pointers.
> I was trying to point out that, rather than starting from C and making
> modifications, you could start froma different place, namely Fortran IV and
> then you wouldn't need any of the kinds of modifications listed above. It
> was a (perhaps lame) attempt to try to broaden the OPs perspective that C
> was the be all and end all of programming languages.
Well, for properly written code you shouldn't need most of those
for C either. It is reasonably often posted to comp.lang.c that
a certain piece of code won't work for other than twos complement
machines, though it is usually only slightly harder to write the
correct code. As I understand it, Unisys still sells ones complement
machines.
Both C and Fortran can alias variables of different types and
non-portably detect endian problems. Variable size can be
exactly specified in PL/I, but it is normally expected that the
compiler will choose the next convenient size.
-- glen
Jan Vorbrüggen
> expected that the compiler will choose the next convenient size.
Fortran 90 et seq. have exactly the same model.
Jan
Jan Vorbrüggen
> that perspective comes from a "pointer = memory address" perspective
> (I'm unclear what the difference would be otherwise, except possibly
> pointer = reference+offset).
Oh, a pointer can be much more than that. In Fortran 90 et seq., you could
define, by way of example,
Real :: Array (1:10, -5:5, 0:9)
Real, Pointer :: P
and then set
P = Array (1:10:2, 5:-5:-1, (/0,8,2,6,4/))
and then do
Call Do_Something (P)
which will operate on an array of dimension (5, 11, 5) that seems to be
virtually contiguous, but accesses the specified array elements in the
order specified. It is the compiler's responsibility to build a data
structure that can deliver this transparently, but to the programmer this
pointer is just an opaque data structure that he passes around and that
he knows will get the work done.
Jan
mihai cartoaje
You mean starting with java and adding pointers? I have not thought
about how to do it. Maybe someone else can take the challenge.
mihai cartoaje
Patricia Shanahan
Adding pointers to Java is trivial, because it already has them. Every
non-null Java reference is a pointer.
See the Java Language Specification: "The reference values (often just
references) are pointers to these objects, and a special null reference,
which refers to no object."
[4.3.1 Objects,
http://java.sun.com/docs/books/jls/second_edition/html/typesValues.doc.html#12028]
Patricia
Nick Maclaren
Really? You clearly haven't looked at it carefully enough. Please
do so before posting such statements again.
Regards,
Nick Maclaren.
glen herrmannsfeldt
In the context of the discussion, defined widths for data
types, defined twos complement, defined big endian external
representation, pointer size is invisible to the program,
defined IEEE floating point.
I do agree that there are things that could have been
done better, but within those requirements it seems to
me that Java satisfies them all.
Now, consider C: There are minimum widths for data types,
but no maximum. Ones complement or signed magnitude are
allowed for signed data. One must be careful with endianness
when data might transfer to another machine. Many people
get lazy when only working on one machine and don't consider
possible non-portability of their code.
-- glen
Nick Maclaren
glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote:
>Nick Maclaren wrote:
>
>> In article <1124852733.1...@g47g2000cwa.googlegroups.com>,
>> mihai cartoaje <rep...@yahoo.ca> wrote:
>
>>>Nothing is wrong with java.
>
>> Really? You clearly haven't looked at it carefully enough.
>> Please do so before posting such statements again.
>
>In the context of the discussion, defined widths for data
>types, defined twos complement, defined big endian external
>representation, pointer size is invisible to the program,
>defined IEEE floating point.
And, specifically, none of scalability, portability to new paradigms,
performance or high RAS matter worth a damn. Er, yes, if that is
your target, I suppose Java IS flawless.
The flat statement "Nothing is wrong with Java" is, at best,
misleading.
Regards,
Nick Maclaren.
glen herrmannsfeldt
PL/I has a slightly different model. One can specify the width
in either binary bits or decimal digits. Some, but not all,
implementations used BCD arithmetic for FIXED DECIMAL.
For fixed point, PL/I allows one to specify the number of
bits or decimal digits after the binary point or decimal point,
respectively (even negative or more than the width).
Proper scaling will be applied when operations are performed
on data with different scale factors.
Floating point data can also be specified in terms of bits
or decimal digits. Systems that I know of use binary arithmetic
for both, but on a machine allowing both binary and decimal floating
point one might expect FLOAT DECIMAL to use decimal floating
point.
Fortran allows for some, but not all, of those features.
-- glen
mihai cartoaje
an int.
mihai
--
a wip windowing program for svgalib at,
http://sourceforge.net/projects/svgalib-windows