| Author |
Message |
Peter \"Firefly\" Lund
Guest
|
 Posted:
Tue Aug 16, 2005 4:15 pm Post subject:
Re: ISA-independent programming language |
|
|
On Tue, 15 Aug 2005, mihai cartoaje wrote:
| Quote: | 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 |
|
| Back to top |
|
 |
Dan Koren
Guest
|
| Posted:
Tue Aug 16, 2005 4:15 pm Post subject:
Re: ISA-independent programming language |
|
|
"David W. Schroth" <David.Schroth@unisys.com> wrote in message
news:ddt12v$2138$1@si05.rsvl.unisys.com...
| Quote: | 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 |
|
| Back to top |
|
|
Michel Hack
Guest
|
| Posted:
Tue Aug 16, 2005 11:55 pm Post subject:
Re: ISA-independent programming language |
|
|
Hank Oredson wrote:
| Quote: | - 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. |
|
| Back to top |
|
|
Andrew Reilly
Guest
|
| Posted:
Wed Aug 17, 2005 12:15 am Post subject:
Re: ISA-independent programming language |
|
|
On Tue, 16 Aug 2005 15:35:18 +0000, Hank Oredson wrote:
| Quote: | "Anton Ertl" <anton@mips.complang.tuwien.ac.at> wrote in message
news:2005Aug16.075744@mips.complang.tuwien.ac.at...
"Hank Oredson" <horedson@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.
| Quote: | 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 |
|
| Back to top |
|
|
Andrew Reilly
Guest
|
| Posted:
Wed Aug 17, 2005 8:15 am Post subject:
Re: ISA-independent programming language |
|
|
On Wed, 17 Aug 2005 07:27:04 +0000, Anton Ertl wrote:
| Quote: | 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 |
|
| Back to top |
|
|
Anton Ertl
Guest
|
| Posted:
Wed Aug 17, 2005 8:15 am Post subject:
Re: ISA-independent programming language |
|
|
"Hank Oredson" <horedson@earthlink.net> writes:
| Quote: | "Andrew Reilly" <andrew-newspost@areilly.bpc-users.org> wrote in message
news:pan.2005.08.16.23.17.23.275987@areilly.bpc-users.org...
On Tue, 16 Aug 2005 15:35:18 +0000, Hank Oredson wrote:
"Anton Ertl" <anton@mips.complang.tuwien.ac.at> wrote in message
news:2005Aug16.075744@mips.complang.tuwien.ac.at...
"Hank Oredson" <horedson@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.
- anton
--
M. Anton Ertl Some things have to be seen to be believed
anton@mips.complang.tuwien.ac.at Most things have to be believed to be seen
http://www.complang.tuwien.ac.at/anton/home.html |
|
| Back to top |
|
|
Anton Ertl
Guest
|
| Posted:
Wed Aug 17, 2005 8:15 am Post subject:
Re: ISA-independent programming language |
|
|
Andrew Reilly <andrew-newspost@areilly.bpc-users.org> writes:
[Using arithmetic instead of bitwise operations]
| Quote: | 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
--
M. Anton Ertl Some things have to be seen to be believed
anton@mips.complang.tuwien.ac.at Most things have to be believed to be seen
http://www.complang.tuwien.ac.at/anton/home.html |
|
| Back to top |
|
|
Andrew Reilly
Guest
|
| Posted:
Wed Aug 17, 2005 8:15 am Post subject:
Re: ISA-independent programming language |
|
|
On Wed, 17 Aug 2005 03:57:46 +0000, Hank Oredson wrote:
| Quote: | "Andrew Reilly" <andrew-newspost@areilly.bpc-users.org> wrote in message
news:pan.2005.08.16.23.17.23.275987@areilly.bpc-users.org...
On Tue, 16 Aug 2005 15:35:18 +0000, Hank Oredson wrote:
"Anton Ertl" <anton@mips.complang.tuwien.ac.at> wrote in message
news:2005Aug16.075744@mips.complang.tuwien.ac.at...
"Hank Oredson" <horedson@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 |
|
| Back to top |
|
|
Hank Oredson
Guest
|
| Posted:
Wed Aug 17, 2005 8:15 am Post subject:
Re: ISA-independent programming language |
|
|
"Michel Hack" <hack@watson.ibm.com> wrote in message
news:1124218524.621766.99450@z14g2000cwz.googlegroups.com...
| Quote: |
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."
| Quote: | 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.
| Quote: | 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.
| Quote: | 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.
| Quote: | 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.
| Quote: | 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.
--
... Hank
http://home.earthlink.net/~horedson
http://home.earthlink.net/~w0rli |
|
| Back to top |
|
|
Hank Oredson
Guest
|
| Posted:
Wed Aug 17, 2005 8:15 am Post subject:
Re: ISA-independent programming language |
|
|
"Andrew Reilly" <andrew-newspost@areilly.bpc-users.org> wrote in message
news:pan.2005.08.16.23.17.23.275987@areilly.bpc-users.org...
| Quote: | On Tue, 16 Aug 2005 15:35:18 +0000, Hank Oredson wrote:
"Anton Ertl" <anton@mips.complang.tuwien.ac.at> wrote in message
news:2005Aug16.075744@mips.complang.tuwien.ac.at...
"Hank Oredson" <horedson@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?
| Quote: | 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.
| Quote: | 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?
| Quote: | 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.
| Quote: | Or, more simply, just allow intermixing of arithmetic and logical
operations.
|
How have I suggested these things might be NOT allowed?
| Quote: | 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
http://home.earthlink.net/~horedson
http://home.earthlink.net/~w0rli |
|
| Back to top |
|
|
Hank Oredson
Guest
|
| Posted:
Wed Aug 17, 2005 4:15 pm Post subject:
Re: ISA-independent programming language |
|
|
"Andrew Reilly" <andrew-newspost@areilly.bpc-users.org> wrote in message
news:pan.2005.08.17.04.42.19.156097@areilly.bpc-users.org...
| Quote: | On Wed, 17 Aug 2005 03:57:46 +0000, Hank Oredson wrote:
"Andrew Reilly" <andrew-newspost@areilly.bpc-users.org> wrote in message
news:pan.2005.08.16.23.17.23.275987@areilly.bpc-users.org...
On Tue, 16 Aug 2005 15:35:18 +0000, Hank Oredson wrote:
"Anton Ertl" <anton@mips.complang.tuwien.ac.at> wrote in message
news:2005Aug16.075744@mips.complang.tuwien.ac.at...
"Hank Oredson" <horedson@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.
|
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
http://home.earthlink.net/~horedson
http://home.earthlink.net/~w0rli |
|
| Back to top |
|
|
Hank Oredson
Guest
|
| Posted:
Wed Aug 17, 2005 4:15 pm Post subject:
Re: ISA-independent programming language |
|
|
"Anton Ertl" <anton@mips.complang.tuwien.ac.at> wrote in message
news:2005Aug17.093909@mips.complang.tuwien.ac.at...
| Quote: | "Hank Oredson" <horedson@earthlink.net> writes:
"Andrew Reilly" <andrew-newspost@areilly.bpc-users.org> wrote in message
news:pan.2005.08.16.23.17.23.275987@areilly.bpc-users.org...
On Tue, 16 Aug 2005 15:35:18 +0000, Hank Oredson wrote:
"Anton Ertl" <anton@mips.complang.tuwien.ac.at> wrote in message
news:2005Aug16.075744@mips.complang.tuwien.ac.at...
"Hank Oredson" <horedson@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.
--
... Hank
http://home.earthlink.net/~horedson
http://home.earthlink.net/~w0rli |
|
| Back to top |
|
|
Seongbae Park
Guest
|
| Posted:
Wed Aug 17, 2005 9:29 pm Post subject:
Re: ISA-independent programming language |
|
|
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
....
| Quote: | 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/" |
|
| Back to top |
|
|
Terje Mathisen
Guest
|
| Posted:
Thu Aug 18, 2005 3:01 pm Post subject:
Re: ISA-independent programming language |
|
|
Seongbae Park wrote:
| Quote: | 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
| Quote: |
Any divide by 2^C can be handled in a similar manner.
|
Right.
Terje
--
- <Terje.Mathisen@hda.hydro.com>
"almost all programming can be viewed as an exercise in caching" |
|
| Back to top |
|
|
mihai cartoaje
Guest
|
| Posted:
Thu Aug 18, 2005 3:56 pm Post subject:
Re: ISA-independent programming language |
|
|
Hank Oredson wrote:
| Quote: | 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". |
|
| Back to top |
|
|
|
|
|
|
FAQ
Memberlist
Register
Profile
Log in to check your private messages
Log in