| Author |
Message |
mihai cartoaje
Guest
|
 Posted:
Thu Aug 11, 2005 8:15 am Post subject:
ISA-independent programming language |
|
|
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
I am posting it to comp.arch because google is buggy on comp.lang |
|
| Back to top |
|
 |
Peter \"Firefly\" Lund
Guest
|
| Posted:
Thu Aug 11, 2005 8:15 am Post subject:
Re: ISA-independent programming language |
|
|
On Thu, 10 Aug 2005, mihai cartoaje wrote:
| Quote: | - 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 |
|
| Back to top |
|
|
mihai cartoaje
Guest
|
| Posted:
Thu Aug 11, 2005 8:15 am Post subject:
Re: ISA-independent programming language |
|
|
I have written,
| Quote: | 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." |
|
| Back to top |
|
|
Torben Ęgidius Mogensen
Guest
|
| Posted:
Thu Aug 11, 2005 1:54 pm Post subject:
Re: ISA-independent programming language |
|
|
"mihai cartoaje" <repstsb@yahoo.ca> writes:
| Quote: | 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 |
|
| Back to top |
|
|
mihai cartoaje
Guest
|
| Posted:
Fri Aug 12, 2005 7:27 am Post subject:
Re: ISA-independent programming language |
|
|
Peter "Firefly" Lund has written,
| Quote: | 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.
| Quote: | 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?
| Quote: | 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. |
|
| Back to top |
|
|
Peter \"Firefly\" Lund
Guest
|
| Posted:
Fri Aug 12, 2005 8:15 am Post subject:
Re: ISA-independent programming language |
|
|
On Fri, 11 Aug 2005, mihai cartoaje wrote:
| Quote: | 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 ;) )
| Quote: | 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).
| Quote: | 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 |
|
| Back to top |
|
|
mihai cartoaje
Guest
|
| Posted:
Sun Aug 14, 2005 8:15 am Post subject:
Re: ISA-independent programming language |
|
|
Peter "Firefly" Lund has written,
| Quote: | 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. |
|
| Back to top |
|
|
John Savard
Guest
|
| Posted:
Sun Aug 14, 2005 8:15 am Post subject:
Re: ISA-independent programming language |
|
|
On 10 Aug 2005 23:06:16 -0700, "mihai cartoaje" <repstsb@yahoo.ca>
wrote, in part:
| Quote: | 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 |
|
| Back to top |
|
|
Peter \"Firefly\" Lund
Guest
|
| Posted:
Sun Aug 14, 2005 1:38 pm Post subject:
Re: ISA-independent programming language |
|
|
On Sun, 13 Aug 2005, mihai cartoaje wrote:
| Quote: | Peter "Firefly" Lund has written,
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.
|
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 |
|
| Back to top |
|
|
mihai cartoaje
Guest
|
| Posted:
Tue Aug 16, 2005 7:34 am Post subject:
Re: ISA-independent programming language |
|
|
Peter "Firefly" Lund has written:
| Quote: | 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. |
|
| Back to top |
|
|
Anton Ertl
Guest
|
| Posted:
Tue Aug 16, 2005 8:15 am Post subject:
Re: ISA-independent programming language |
|
|
"Hank Oredson" <horedson@earthlink.net> writes:
| Quote: | "mihai cartoaje" <repstsb@yahoo.ca> wrote in message
news:1123740376.457314.166050@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.
| 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.
|
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?
| Quote: | - 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.
| Quote: | - 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.
| Quote: | - 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.
| Quote: | - 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
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 |
|
|
Hank Oredson
Guest
|
| Posted:
Tue Aug 16, 2005 8:15 am Post subject:
Re: ISA-independent programming language |
|
|
"mihai cartoaje" <repstsb@yahoo.ca> wrote in message
news:1123740376.457314.166050@g43g2000cwa.googlegroups.com...
| Quote: | 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.
| 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.
| Quote: | - 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?
| Quote: | - 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.
| Quote: | - 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.
| Quote: | - the value of floating-point formulas is uniquely defined by the
programming language
|
Exactly, the compiler takes care of it.
| Quote: | - others I have not thought of
|
The compiler takes care of it.
That's why we have compilers (grin).
| Quote: | 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 |
|
| Back to top |
|
|
Hank Oredson
Guest
|
| Posted:
Tue Aug 16, 2005 8:15 am Post subject:
Re: ISA-independent programming language |
|
|
"mihai cartoaje" <repstsb@yahoo.ca> wrote in message
news:1123745162.734793.109360@g49g2000cwa.googlegroups.com...
| Quote: | I have written,
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."
|
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?
--
... Hank
http://home.earthlink.net/~horedson
http://home.earthlink.net/~w0rli |
|
| Back to top |
|
|
David W. Schroth
Guest
|
| Posted:
Tue Aug 16, 2005 4:15 pm Post subject:
Re: ISA-independent programming language |
|
|
Anton Ertl wrote:
| Quote: | "Hank Oredson" <horedson@earthlink.net> writes:
"mihai cartoaje" <repstsb@yahoo.ca> wrote in message
news:1123740376.457314.166050@g43g2000cwa.googlegroups.com...
snip
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.
|
|
| Back to top |
|
|
Hank Oredson
Guest
|
| Posted:
Tue Aug 16, 2005 4:15 pm Post subject:
Re: ISA-independent programming language |
|
|
"Anton Ertl" <anton@mips.complang.tuwien.ac.at> wrote in message
news:2005Aug16.075744@mips.complang.tuwien.ac.at...
| Quote: | "Hank Oredson" <horedson@earthlink.net> writes:
"mihai cartoaje" <repstsb@yahoo.ca> wrote in message
news:1123740376.457314.166050@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.
|
The language needs the correct data types for the operations
it supports. If a bitset is needed, the language should provide it.
| Quote: | 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.
| Quote: | 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?
| Quote: | - 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.
| Quote: | - 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).
| Quote: | 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.
| Quote: | 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).
--
... Hank
http://home.earthlink.net/~horedson
http://home.earthlink.net/~w0rli |
|
| Back to top |
|
|
|
|
|
|
FAQ
Memberlist
Register
Profile
Log in to check your private messages
Log in