Hi,
Michael Schwingen writes:
Francois LE COAT wrote:
What worries me the most, is that there's no 16bits integer type. The >>>> C language is inappropriate for 16/32bits ATARI machines.
Huh?
Of course there is - I just tried using gcc-m68k-atari-mint cross-compiler
(4.6.4) - it is called "short", just like expected.
Replacing integer type (int) by short type (short) in my 30 years old
sources from Eureka 2.12 doesn't work. GNU/GCC 3.3.6 16bits integer
type is suitable for 16/32bits machines like the ATARI ST, but GNU/GCC
4.2 and later don't have this 16bits int type. This is a cruel lack =(
Huh?
"short" *is* an integer type, so gcc has what you need. If using "short" does not work, your code is buggy in other areas and simply needs to be debugged/fixed - this is not gcc's fault.
I can accept that you don't want to do that work, but again: that is your decision and not gcc's fault.
If 16bits variants of ATARI's libraries were supplied with GNU/GCC 4.2
or later, I would appreciate de retro-compatibility with the ATARI ST.
But these 16bits versions of MiNTlib, GEMlib etc. are not still
maintained ... You would say that it is "buggy" or something else,
but it is simply 30 years old, such as the sources of my Eureka 2.12 software. The retro-compatibility with the ATARI ST is not maintained.
The problem is really with the "programmed obsolescence" with GNU/GCC 4,
and people developing the ATARI target. They forget that ATARI ST is
a 16/32bits architecture, and the "integer" type should be proposed as
a 16bits type. This is a matter of adequacy from the language with the target. A 32bits integer type is far too demanding for an ATARI 520ST
with 1Mb of RAM, like the one that was proposed 30 years ago by ATARI.
Please notice that my software Eureka 2.12 runs on the early 520ST =)
Most of the ATARI software produced today are not, you can check it.
The software generated with AHCC have more chance to run with ATARI ST.
Regards,
--
François LE COAT
Author of Eureka 2.12 (2D Graph Describer, 3D Modeller) http://eureka.atari.org/
Do you realise you're mixing gcc, mintlib and mint issues into one bag?
There's 0% chance the libraries you're using are official. 16-bit ("mshort") support had been dropped sometime in the 2000s, long before gcc 4.2.
So whoever gave you those mintlib builds, ask him to make an update with gcc 4.6.4.
I can't remember when exactly but there has been a change in FPU register handling in gcc so perhaps you can't directly use your old libs with "latest" gcc but it's worth a try.
Anyway, your blaming of developers/applications is totally off.
Francois LE COAT writes:
Michael Schwingen writes:
Francois LE COAT wrote:
What worries me the most, is that there's no 16bits integer type. The >>>>>> C language is inappropriate for 16/32bits ATARI machines.
Huh?
Of course there is - I just tried using gcc-m68k-atari-mint cross-compiler
(4.6.4) - it is called "short", just like expected.
Replacing integer type (int) by short type (short) in my 30 years old
sources from Eureka 2.12 doesn't work. GNU/GCC 3.3.6 16bits integer
type is suitable for 16/32bits machines like the ATARI ST, but GNU/GCC >>>> 4.2 and later don't have this 16bits int type. This is a cruel lack =(
Huh?
"short" *is* an integer type, so gcc has what you need. If using "short" >>> does not work, your code is buggy in other areas and simply needs to be
debugged/fixed - this is not gcc's fault.
I can accept that you don't want to do that work, but again: that is your >>> decision and not gcc's fault.
If 16bits variants of ATARI's libraries were supplied with GNU/GCC 4.2
or later, I would appreciate de retro-compatibility with the ATARI ST.
But these 16bits versions of MiNTlib, GEMlib etc. are not still
maintained ... You would say that it is "buggy" or something else,
but it is simply 30 years old, such as the sources of my Eureka 2.12
software. The retro-compatibility with the ATARI ST is not maintained.
The problem is really with the "programmed obsolescence" with GNU/GCC 4,
and people developing the ATARI target. They forget that ATARI ST is
a 16/32bits architecture, and the "integer" type should be proposed as
a 16bits type. This is a matter of adequacy from the language with the
target. A 32bits integer type is far too demanding for an ATARI 520ST
with 1Mb of RAM, like the one that was proposed 30 years ago by ATARI.
Please notice that my software Eureka 2.12 runs on the early 520ST =)
Most of the ATARI software produced today are not, you can check it.
The software generated with AHCC have more chance to run with ATARI ST.
I disagree. I always considered 16 bit integers too small for
a computer as modern as the ATARI ST having loads of ram.
(1966 mainframes are my objects of reference where ram was payed
by the kilobyte).
That's why I replaced all occurences of int in AHCC and its libraries
by short and created the sinclude folder of header files.
Still works like a charm.
Hi,
I'm currently using GNU/GCC 3.3.6 with the following configuration :
<http://eureka.atari.org/gcc3.3.6SDK.zip>
I mean, I'm using GNU/GCC 3.3.6 and building Eureka 2.12 software with
the "-mshort" option and 16bits versions of the required libraries.
The problem since 3.3.6 version of GNU/GCC and 4.2 or later, is that
the linker from GNU/GCC (ld), and the library format (.a) changed.
I don't know precisely how I could use GNU/GCC 4.6.4, with the "-mshort" compilation option, and link with my versions of the 16bits libraries ?
Can you explain ?
Thanks,
Miro Kropáček writes:
Do you realise you're mixing gcc, mintlib and mint issues into one bag?
There's 0% chance the libraries you're using are official. 16-bit ("mshort") support had been dropped sometime in the 2000s, long before gcc 4.2.
So whoever gave you those mintlib builds, ask him to make an update with gcc 4.6.4.
I can't remember when exactly but there has been a change in FPU register handling in gcc so perhaps you can't directly use your old libs with "latest" gcc but it's worth a try.
Anyway, your blaming of developers/applications is totally off.
Francois LE COAT writes:
Michael Schwingen writes:
Francois LE COAT wrote:
Huh?What worries me the most, is that there's no 16bits integer type. The >>>>>> C language is inappropriate for 16/32bits ATARI machines.
Huh?
Of course there is - I just tried using gcc-m68k-atari-mint cross-compiler
(4.6.4) - it is called "short", just like expected.
Replacing integer type (int) by short type (short) in my 30 years old >>>> sources from Eureka 2.12 doesn't work. GNU/GCC 3.3.6 16bits integer
type is suitable for 16/32bits machines like the ATARI ST, but GNU/GCC >>>> 4.2 and later don't have this 16bits int type. This is a cruel lack =( >>>
"short" *is* an integer type, so gcc has what you need. If using "short" >>> does not work, your code is buggy in other areas and simply needs to be >>> debugged/fixed - this is not gcc's fault.
I can accept that you don't want to do that work, but again: that is your >>> decision and not gcc's fault.
If 16bits variants of ATARI's libraries were supplied with GNU/GCC 4.2
or later, I would appreciate de retro-compatibility with the ATARI ST.
But these 16bits versions of MiNTlib, GEMlib etc. are not still
maintained ... You would say that it is "buggy" or something else,
but it is simply 30 years old, such as the sources of my Eureka 2.12
software. The retro-compatibility with the ATARI ST is not maintained.
The problem is really with the "programmed obsolescence" with GNU/GCC 4, >> and people developing the ATARI target. They forget that ATARI ST is
a 16/32bits architecture, and the "integer" type should be proposed as
a 16bits type. This is a matter of adequacy from the language with the
target. A 32bits integer type is far too demanding for an ATARI 520ST
with 1Mb of RAM, like the one that was proposed 30 years ago by ATARI.
Please notice that my software Eureka 2.12 runs on the early 520ST =)
Most of the ATARI software produced today are not, you can check it.
The software generated with AHCC have more chance to run with ATARI ST.
Regards,
--
François LE COAT
Author of Eureka 2.12 (2D Graph Describer, 3D Modeller) http://eureka.atari.org/
(1966 mainframes are my objects of reference where ram was payed
by the kilobyte).
That was my birth. At this period there was a Univac at the university
that was occupying an entire building, and worked with perforated cards.
Francois LE COAT wrote:
(1966 mainframes are my objects of reference where ram was payed
by the kilobyte).
That was my birth. At this period there was a Univac at the university
that was occupying an entire building, and worked with perforated cards.
Kilobytes are not gone - my current target (STM32F103) has 64kBytes of Flash and 20kBytes of RAM, and works fine using gcc (yes, with 32-bit ints).
Now you're mixing binutils and gcc. :-)
I find hard to believe the format has changed but you can always try to use old binutils (as, ld, nm, ...) with gcc 4.6.4.
Francois LE COAT writes:
I'm currently using GNU/GCC 3.3.6 with the following configuration :
<http://eureka.atari.org/gcc3.3.6SDK.zip>
I mean, I'm using GNU/GCC 3.3.6 and building Eureka 2.12 software with
the "-mshort" option and 16bits versions of the required libraries.
The problem since 3.3.6 version of GNU/GCC and 4.2 or later, is that
the linker from GNU/GCC (ld), and the library format (.a) changed.
I don't know precisely how I could use GNU/GCC 4.6.4, with the "-mshort"
compilation option, and link with my versions of the 16bits libraries ?
Can you explain ?
Miro Kropáček writes:
Do you realise you're mixing gcc, mintlib and mint issues into one bag?
There's 0% chance the libraries you're using are official. 16-bit ("mshort") support had been dropped sometime in the 2000s, long before gcc 4.2.
So whoever gave you those mintlib builds, ask him to make an update with gcc 4.6.4.
I can't remember when exactly but there has been a change in FPU register handling in gcc so perhaps you can't directly use your old libs with "latest" gcc but it's worth a try.
Anyway, your blaming of developers/applications is totally off.
Francois LE COAT writes:
Michael Schwingen writes:
Francois LE COAT wrote:
Huh?What worries me the most, is that there's no 16bits integer type. The >>>>>>>> C language is inappropriate for 16/32bits ATARI machines.
Huh?
Of course there is - I just tried using gcc-m68k-atari-mint cross-compiler
(4.6.4) - it is called "short", just like expected.
Replacing integer type (int) by short type (short) in my 30 years old >>>>>> sources from Eureka 2.12 doesn't work. GNU/GCC 3.3.6 16bits integer >>>>>> type is suitable for 16/32bits machines like the ATARI ST, but GNU/GCC >>>>>> 4.2 and later don't have this 16bits int type. This is a cruel lack =( >>>>>
"short" *is* an integer type, so gcc has what you need. If using "short" >>>>> does not work, your code is buggy in other areas and simply needs to be >>>>> debugged/fixed - this is not gcc's fault.
I can accept that you don't want to do that work, but again: that is your >>>>> decision and not gcc's fault.
If 16bits variants of ATARI's libraries were supplied with GNU/GCC 4.2 >>>> or later, I would appreciate de retro-compatibility with the ATARI ST. >>>> But these 16bits versions of MiNTlib, GEMlib etc. are not still
maintained ... You would say that it is "buggy" or something else,
but it is simply 30 years old, such as the sources of my Eureka 2.12
software. The retro-compatibility with the ATARI ST is not maintained. >>>>
The problem is really with the "programmed obsolescence" with GNU/GCC 4, >>>> and people developing the ATARI target. They forget that ATARI ST is
a 16/32bits architecture, and the "integer" type should be proposed as >>>> a 16bits type. This is a matter of adequacy from the language with the >>>> target. A 32bits integer type is far too demanding for an ATARI 520ST
with 1Mb of RAM, like the one that was proposed 30 years ago by ATARI. >>>>
Please notice that my software Eureka 2.12 runs on the early 520ST =)
Most of the ATARI software produced today are not, you can check it.
The software generated with AHCC have more chance to run with ATARI ST.
My Hades060 has 40Mb of RAM, and I can't use virtual memory because
it's only possible with 68030 processors.
Hi,
What I tested with GNU/GCC 4, is to replace `cc1.ttp` in
<http://eureka.atari.org/gcc3.3.6SDK.zip>
with the more recent one from the version 4.x. Doing that, I have
GNU/GCC 4, in a 3.3.6 environment. This works pretty good ! I still
have the same includes and libraries, but the compiler is in v.4.
There's no need to adapt includes and libraries, because it's the
same. The problem is that GNU/GCC 4 semantic is so different from
GNU/GCC 3, that the generated binary doesn't run as expected.
GNU/GCC 4.2 and later, are not convenient compile tools for 30 years
sources like mine. It's not compatible with PURE C. It doesn't have
16bits variants of the libraries, which most of the old software
like mine requires. It's only compatible with itself. No real interest.
What really miss me, is cross-tools with GNU/GCC 3.3.6. I could build
a cross-compiler, but the problem with today's libraries, is it
doesn't still support 16bits mode compilation. What should be done,
is to rework what was done by Patrice Mandin :
<http://patrice.mandin.pagesperso-orange.fr/en/howto-cross333.html>
but, with the versions of binutils, mintlibs of the same generation.
Miro Kropáček writes:
Now you're mixing binutils and gcc. :-)
I find hard to believe the format has changed but you can always try to use old binutils (as, ld, nm, ...) with gcc 4.6.4.
Francois LE COAT writes:
I'm currently using GNU/GCC 3.3.6 with the following configuration :
<http://eureka.atari.org/gcc3.3.6SDK.zip>
I mean, I'm using GNU/GCC 3.3.6 and building Eureka 2.12 software with
the "-mshort" option and 16bits versions of the required libraries.
The problem since 3.3.6 version of GNU/GCC and 4.2 or later, is that
the linker from GNU/GCC (ld), and the library format (.a) changed.
I don't know precisely how I could use GNU/GCC 4.6.4, with the "-mshort" >> compilation option, and link with my versions of the 16bits libraries ?
Can you explain ?
Miro Kropáček writes:
Do you realise you're mixing gcc, mintlib and mint issues into one bag? >>>
There's 0% chance the libraries you're using are official. 16-bit ("mshort") support had been dropped sometime in the 2000s, long before gcc 4.2.
So whoever gave you those mintlib builds, ask him to make an update with gcc 4.6.4.
I can't remember when exactly but there has been a change in FPU register handling in gcc so perhaps you can't directly use your old libs with "latest" gcc but it's worth a try.
Anyway, your blaming of developers/applications is totally off.
Francois LE COAT writes:
Michael Schwingen writes:
Francois LE COAT wrote:
Huh?What worries me the most, is that there's no 16bits integer type. The
C language is inappropriate for 16/32bits ATARI machines.
Huh?
Of course there is - I just tried using gcc-m68k-atari-mint cross-compiler
(4.6.4) - it is called "short", just like expected.
Replacing integer type (int) by short type (short) in my 30 years old >>>>>> sources from Eureka 2.12 doesn't work. GNU/GCC 3.3.6 16bits integer >>>>>> type is suitable for 16/32bits machines like the ATARI ST, but GNU/GCC >>>>>> 4.2 and later don't have this 16bits int type. This is a cruel lack =( >>>>>
"short" *is* an integer type, so gcc has what you need. If using "short"
does not work, your code is buggy in other areas and simply needs to be >>>>> debugged/fixed - this is not gcc's fault.
I can accept that you don't want to do that work, but again: that is your
decision and not gcc's fault.
If 16bits variants of ATARI's libraries were supplied with GNU/GCC 4.2 >>>> or later, I would appreciate de retro-compatibility with the ATARI ST. >>>> But these 16bits versions of MiNTlib, GEMlib etc. are not still
maintained ... You would say that it is "buggy" or something else,
but it is simply 30 years old, such as the sources of my Eureka 2.12 >>>> software. The retro-compatibility with the ATARI ST is not maintained. >>>>
The problem is really with the "programmed obsolescence" with GNU/GCC 4, >>>> and people developing the ATARI target. They forget that ATARI ST is >>>> a 16/32bits architecture, and the "integer" type should be proposed as >>>> a 16bits type. This is a matter of adequacy from the language with the >>>> target. A 32bits integer type is far too demanding for an ATARI 520ST >>>> with 1Mb of RAM, like the one that was proposed 30 years ago by ATARI. >>>>
Please notice that my software Eureka 2.12 runs on the early 520ST =) >>>> Most of the ATARI software produced today are not, you can check it. >>>> The software generated with AHCC have more chance to run with ATARI ST.
Regards,
--
François LE COAT
Author of Eureka 2.12 (2D Graph Describer, 3D Modeller) http://eureka.atari.org/
My Hades060 has 40Mb of RAM, and I can't use virtual memory because
it's only possible with 68030 processors.
I don't know who told you that but I assure you FreeMiNT does support memory protection on 040/060 for ages.
You're a lost cause, François. Please re-read this thread again, perhaps it will help. You're constantly mixing unrelated things together and mark them as "gcc problems".
Francois LE COAT writes:
What I tested with GNU/GCC 4, is to replace `cc1.ttp` in
<http://eureka.atari.org/gcc3.3.6SDK.zip>
with the more recent one from the version 4.x. Doing that, I have
GNU/GCC 4, in a 3.3.6 environment. This works pretty good ! I still
have the same includes and libraries, but the compiler is in v.4.
There's no need to adapt includes and libraries, because it's the
same. The problem is that GNU/GCC 4 semantic is so different from
GNU/GCC 3, that the generated binary doesn't run as expected.
GNU/GCC 4.2 and later, are not convenient compile tools for 30 years
sources like mine. It's not compatible with PURE C. It doesn't have
16bits variants of the libraries, which most of the old software
like mine requires. It's only compatible with itself. No real interest.
What really miss me, is cross-tools with GNU/GCC 3.3.6. I could build
a cross-compiler, but the problem with today's libraries, is it
doesn't still support 16bits mode compilation. What should be done,
is to rework what was done by Patrice Mandin :
<http://patrice.mandin.pagesperso-orange.fr/en/howto-cross333.html>
but, with the versions of binutils, mintlibs of the same generation.
Miro Kropáček writes:
Now you're mixing binutils and gcc. :-)
I find hard to believe the format has changed but you can always try to use old binutils (as, ld, nm, ...) with gcc 4.6.4.
Francois LE COAT writes:
I'm currently using GNU/GCC 3.3.6 with the following configuration :
<http://eureka.atari.org/gcc3.3.6SDK.zip>
I mean, I'm using GNU/GCC 3.3.6 and building Eureka 2.12 software with >>>> the "-mshort" option and 16bits versions of the required libraries.
The problem since 3.3.6 version of GNU/GCC and 4.2 or later, is that
the linker from GNU/GCC (ld), and the library format (.a) changed.
I don't know precisely how I could use GNU/GCC 4.6.4, with the "-mshort" >>>> compilation option, and link with my versions of the 16bits libraries ? >>>>
Can you explain ?
Miro Kropáček writes:
Do you realise you're mixing gcc, mintlib and mint issues into one bag? >>>>>
There's 0% chance the libraries you're using are official. 16-bit ("mshort") support had been dropped sometime in the 2000s, long before gcc 4.2.
So whoever gave you those mintlib builds, ask him to make an update with gcc 4.6.4.
I can't remember when exactly but there has been a change in FPU register handling in gcc so perhaps you can't directly use your old libs with "latest" gcc but it's worth a try.
Anyway, your blaming of developers/applications is totally off.
Francois LE COAT writes:
Michael Schwingen writes:
Francois LE COAT wrote:
Huh?What worries me the most, is that there's no 16bits integer type. The
C language is inappropriate for 16/32bits ATARI machines.
Huh?
Of course there is - I just tried using gcc-m68k-atari-mint cross-compiler
(4.6.4) - it is called "short", just like expected.
Replacing integer type (int) by short type (short) in my 30 years old >>>>>>>> sources from Eureka 2.12 doesn't work. GNU/GCC 3.3.6 16bits integer >>>>>>>> type is suitable for 16/32bits machines like the ATARI ST, but GNU/GCC >>>>>>>> 4.2 and later don't have this 16bits int type. This is a cruel lack =( >>>>>>>
"short" *is* an integer type, so gcc has what you need. If using "short"
does not work, your code is buggy in other areas and simply needs to be >>>>>>> debugged/fixed - this is not gcc's fault.
I can accept that you don't want to do that work, but again: that is your
decision and not gcc's fault.
If 16bits variants of ATARI's libraries were supplied with GNU/GCC 4.2 >>>>>> or later, I would appreciate de retro-compatibility with the ATARI ST. >>>>>> But these 16bits versions of MiNTlib, GEMlib etc. are not still
maintained ... You would say that it is "buggy" or something else, >>>>>> but it is simply 30 years old, such as the sources of my Eureka 2.12 >>>>>> software. The retro-compatibility with the ATARI ST is not maintained. >>>>>>
The problem is really with the "programmed obsolescence" with GNU/GCC 4, >>>>>> and people developing the ATARI target. They forget that ATARI ST is >>>>>> a 16/32bits architecture, and the "integer" type should be proposed as >>>>>> a 16bits type. This is a matter of adequacy from the language with the >>>>>> target. A 32bits integer type is far too demanding for an ATARI 520ST >>>>>> with 1Mb of RAM, like the one that was proposed 30 years ago by ATARI. >>>>>>
Please notice that my software Eureka 2.12 runs on the early 520ST =) >>>>>> Most of the ATARI software produced today are not, you can check it. >>>>>> The software generated with AHCC have more chance to run with ATARI ST.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 296 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 61:51:02 |
| Calls: | 6,654 |
| Files: | 12,200 |
| Messages: | 5,331,620 |