Hi all,
It looks like "binbuf_addv()", which gets called many places in Pd to save objects' state, expects integer arguments of type "t_int". This is fine except on systems (athlon64 for instance) where t_int is bigger than int. In lots of the calls the int args aren't cast to t_int but are just integers.
I think I should change binbuf_addv() so that integer arguments are simply "int", not "t_int". Can I do this without causing a lot of headaches for extern writers? (I think it should be OK since Pd doesn't work at all on athlon64 as it is...)
The alternative would be to use (t_int) casts everywhere, but really, the "int" argument is intended as a convenience; the data gets converted to a float anyway...
cheers Miller
On Wed, 25 Aug 2004, Miller Puckette wrote:
It looks like "binbuf_addv()", which gets called many places in Pd to save objects' state, expects integer arguments of type "t_int". This is fine except on systems (athlon64 for instance) where t_int is bigger than int. In lots of the calls the int args aren't cast to t_int but are just integers.
"long" is usually the same size as a pointer, if that's what you want. That's what the comment says in m_pd.h.
The Ruby headers do it that way. So if that's your intent, I think t_int should be defined as "long" pretty much everywhere, and then "%ld" used instead of "%d".
Is there any code that really depends on sizeof(t_int)==sizeof(void*) ? Is that comment in m_pd.h still relevant?
________________________________________________________________ Mathieu Bouchard http://artengine.ca/matju
I'm not sure if any code is left now using integers that have to be as big as pointers. The "t_int" typedef shows up a lot though, and having only a 32-bit machine at the moment, I'm nervous about getting rid of them all. I'd also be nervous just calling them "long" - there's no guarantee that can hold a pointer either.
cheers Miller
On Wed, Aug 25, 2004 at 02:35:07PM -0400, Mathieu Bouchard wrote:
On Wed, 25 Aug 2004, Miller Puckette wrote:
It looks like "binbuf_addv()", which gets called many places in Pd to save objects' state, expects integer arguments of type "t_int". This is fine except on systems (athlon64 for instance) where t_int is bigger than int. In lots of the calls the int args aren't cast to t_int but are just integers.
"long" is usually the same size as a pointer, if that's what you want. That's what the comment says in m_pd.h.
The Ruby headers do it that way. So if that's your intent, I think t_int should be defined as "long" pretty much everywhere, and then "%ld" used instead of "%d".
Is there any code that really depends on sizeof(t_int)==sizeof(void*) ? Is that comment in m_pd.h still relevant?
Mathieu Bouchard http://artengine.ca/matju
On Wed, 25 Aug 2004, Miller Puckette wrote:
I'm not sure if any code is left now using integers that have to be as big as pointers. The "t_int" typedef shows up a lot though, and having only a 32-bit machine at the moment, I'm nervous about getting rid of them all. I'd also be nervous just calling them "long" - there's no guarantee that can hold a pointer either.
From the FAQ :
Ruby is developed under Linux, and is written in fairly straightforward C. It runs under UNIX, DOS, Windows 95/98/NT/2000, Mac OS X, BeOS, Amiga, Acorn Risc OS, and OS/2.
May I add that Ruby is available for many, many CPUs, and still, ruby.h reads (version 1.9.0 cvs) :
#if SIZEOF_LONG != SIZEOF_VOIDP # error ---->> ruby requires sizeof(void*) == sizeof(long) to be compiled. <<--- - #endif typedef unsigned long VALUE; typedef unsigned long ID;
is my argument convincing?
________________________________________________________________ Mathieu Bouchard http://artengine.ca/matju
Those are all computers. I'm thinking about mobile phones, PDAs, DSPs, embedded processors, etc. Anyway, it's better to have a name for an integer you might later cast to pointer - makes it more readable.
cheers Miller
On Wed, Aug 25, 2004 at 03:21:20PM -0400, Mathieu Bouchard wrote:
On Wed, 25 Aug 2004, Miller Puckette wrote:
I'm not sure if any code is left now using integers that have to be as big as pointers. The "t_int" typedef shows up a lot though, and having only a 32-bit machine at the moment, I'm nervous about getting rid of them all. I'd also be nervous just calling them "long" - there's no guarantee that can hold a pointer either.
From the FAQ :
Ruby is developed under Linux, and is written in fairly straightforward C. It runs under UNIX, DOS, Windows 95/98/NT/2000, Mac OS X, BeOS, Amiga, Acorn Risc OS, and OS/2.
May I add that Ruby is available for many, many CPUs, and still, ruby.h reads (version 1.9.0 cvs) :
#if SIZEOF_LONG != SIZEOF_VOIDP # error ---->> ruby requires sizeof(void*) == sizeof(long) to be compiled. <<---
#endif typedef unsigned long VALUE; typedef unsigned long ID;
is my argument convincing?
Mathieu Bouchard http://artengine.ca/matju
On Wed, 25 Aug 2004, Miller Puckette wrote:
Those are all computers. I'm thinking about mobile phones, PDAs, DSPs, embedded processors, etc.
You know, those mobile phones and PDAs and embedded processors, they tend to be rather similar to regular computers. What's the point of your distinction?
I run Ruby/Pd/GridFlow on a NetWinder computer, which is a *very* small "desktop" box containing roughly the same kind of processor (StrongARM V4L at 166 MHz) you find in an iPaq or a Zaurus.
go on http://linuxdevices.com/articles/AT8728350077.html and count how many of them use StrongARM or MIPS or PPC.
Anyway, it's better to have a name for an integer you might later cast to pointer - makes it more readable.
What does that mean??? We're not debating that. We're debating whether that should be sometimes an int, sometimes a long, or whether it should be always a long.
________________________________________________________________ Mathieu Bouchard http://artengine.ca/matju
On Wed, Aug 25, 2004 at 03:21:20PM -0400, Mathieu Bouchard wrote:
On Wed, 25 Aug 2004, Miller Puckette wrote:
I'm not sure if any code is left now using integers that have to be as big as pointers. The "t_int" typedef shows up a lot though, and having only a 32-bit machine at the moment, I'm nervous about getting rid of them all. I'd also be nervous just calling them "long" - there's no guarantee that can hold a pointer either.
From the FAQ :
Ruby is developed under Linux, and is written in fairly straightforward C. It runs under UNIX, DOS, Windows 95/98/NT/2000, Mac OS X, BeOS, Amiga, Acorn Risc OS, and OS/2.
May I add that Ruby is available for many, many CPUs, and still, ruby.h reads (version 1.9.0 cvs) :
#if SIZEOF_LONG != SIZEOF_VOIDP # error ---->> ruby requires sizeof(void*) == sizeof(long) to be compiled. <<---
#endif typedef unsigned long VALUE; typedef unsigned long ID;
is my argument convincing?
I find the argument "this technique is used in a large scale open source project so it must be good" quite flaccid myself. Who knows how compilers, hardware, etc. will change in the future? Don't you think it's better to keep it as portable as possible?
Chris. ------------------- chris@mccormick.cx http://mccormick.cx
On Thu, 26 Aug 2004, Chris McCormick wrote:
I find the argument "this technique is used in a large scale open source project so it must be good" quite flaccid myself. Who knows how compilers, hardware, etc. will change in the future? Don't you think it's better to keep it as portable as possible?
pick your poison:
* JAVA VM on a chip * 36-bit LISP machine * Scheme compiled to VHDL then to reconfigurable logic gates * Turing machine with a high-density rewritable laser tape * Quantum computer programmed in Perl * Trinary computer * Babbage's Analytic Machine using carbon nanogears * Hydraulic abacus * Paper and pencil * Transhumanity / Extropism / Staring into the singularity
________________________________________________________________ Mathieu Bouchard http://artengine.ca/matju
Ha. Way to be completely unreasonable. :P
Chris.
On Thu, Aug 26, 2004 at 02:33:55AM -0400, Mathieu Bouchard wrote:
On Thu, 26 Aug 2004, Chris McCormick wrote:
I find the argument "this technique is used in a large scale open source project so it must be good" quite flaccid myself. Who knows how compilers, hardware, etc. will change in the future? Don't you think it's better to keep it as portable as possible?
pick your poison:
- JAVA VM on a chip
- 36-bit LISP machine
- Scheme compiled to VHDL then to reconfigurable logic gates
- Turing machine with a high-density rewritable laser tape
- Quantum computer programmed in Perl
- Trinary computer
- Babbage's Analytic Machine using carbon nanogears
- Hydraulic abacus
- Paper and pencil
- Transhumanity / Extropism / Staring into the singularity
Mathieu Bouchard http://artengine.ca/matju
------------------- chris@mccormick.cx http://mccormick.cx
Hi all, i think that binbuf_addv should expect int, not t_int. I don't think there are too many (t_int) casts in existing code, and the externals will have to be checked for 64-portability anyhow....
best greetings, Thomas
It looks like "binbuf_addv()", which gets called many places in Pd to save objects' state, expects integer arguments of type "t_int". This is fine except on systems (athlon64 for instance) where t_int is bigger than int. In lots of the calls the int args aren't cast to t_int but are just integers.
I think I should change binbuf_addv() so that integer arguments are simply "int", not "t_int". Can I do this without causing a lot of headaches for extern writers? (I think it should be OK since Pd doesn't work at all on athlon64 as it is...)
The alternative would be to use (t_int) casts everywhere, but really, the "int" argument is intended as a convenience; the data gets converted to a float anyway...
cheers Miller
PD-dev mailing list PD-dev@iem.at http://iem.at/cgi-bin/mailman/listinfo/pd-dev
On Wed, 25 Aug 2004, Miller Puckette wrote:
It looks like "binbuf_addv()", which gets called many places in Pd to save objects' state, expects integer arguments of type "t_int". This is fine except on systems (athlon64 for instance) where t_int is bigger than int. In lots of the calls the int args aren't cast to t_int but are just integers.
I do not understand the problem here. It would be worse if binbuf_addv() would expect smaller integers. If it expects bigger ones, they are correctly converted.
I have been using pd for some years on a 64 bit machine, and it worked without problems. I do not know how much code was added since then, especially the gui stuff might cause problems, but fixing this should not be too much of an headache. Again, I offer to send a patch, I bet that what runs on the alpha runs on the athlon too.
Guenter
I think I should change binbuf_addv() so that integer arguments are simply "int", not "t_int". Can I do this without causing a lot of headaches for extern writers? (I think it should be OK since Pd doesn't work at all on athlon64 as it is...)
The alternative would be to use (t_int) casts everywhere, but really, the "int" argument is intended as a convenience; the data gets converted to a float anyway...
cheers Miller
PD-dev mailing list PD-dev@iem.at http://iem.at/cgi-bin/mailman/listinfo/pd-dev
On Fri, 27 Aug 2004, guenter geiger wrote:
I do not understand the problem here. It would be worse if binbuf_addv() would expect smaller integers. If it expects bigger ones, they are correctly converted.
oops, sorry, forgot that binbuf_addv() is an elipse function. Still wondering why it actually worked on the alpha then.
In fact, it seems the places where int's are actually passed as parameters are the gui's coordinates mainly.
Guenter
I have been using pd for some years on a 64 bit machine, and it worked without problems. I do not know how much code was added since then, especially the gui stuff might cause problems, but fixing this should not be too much of an headache. Again, I offer to send a patch, I bet that what runs on the alpha runs on the athlon too.
Guenter
I think I should change binbuf_addv() so that integer arguments are simply "int", not "t_int". Can I do this without causing a lot of headaches for extern writers? (I think it should be OK since Pd doesn't work at all on athlon64 as it is...)
The alternative would be to use (t_int) casts everywhere, but really, the "int" argument is intended as a convenience; the data gets converted to a float anyway...
cheers Miller
PD-dev mailing list PD-dev@iem.at http://iem.at/cgi-bin/mailman/listinfo/pd-dev
PD-dev mailing list PD-dev@iem.at http://iem.at/cgi-bin/mailman/listinfo/pd-dev
-
Chris McCormick -
guenter geiger -
Mathieu Bouchard -
Miller Puckette -
Thomas Grill