Eureka 2.12 is 30 years old

[Francois LE COAT]

Hi,

The principal software that I'm developing since 1987, is 30 this year.

30 years ago, Michael Jackson releases his hit album "Bad" etc. I had an
ATARI 1040STf, followed by a MegaSTe4 (91), a Falcon030 (93) and a
Hades060 (96) that was the first in France - I still have the 2 latest -
I mainly used those computers for developing since 2003, when I had a
PowerMac G4, because I'm concerned by the ARAnyM GNU/GPL developments
to continue my activities.

Nowadays, the evolution of ATARI developers' world, implies that I can't
continue programming, because GNU/GCC 4.2 for ATARI is inappropriate for
old sources in C language. The hope will come from the AHCC compiler,
thanks to its PURE C compatibility, and Coldfire code generation ...

In order to really understand that, the ATARI company is 45 years old.
ATARI begun to sell computers that we know, only 30 years ago. I
started programming 35 years ago, because I first have a Sinclair.
I bought an ATARI ST knowing the personal information technologies.

I still have it <http://www.flickr.com/photos/le_coat/6412802499/>

Because Eureka 2.12 was germinating on my former ZX81. It was the
very beginning of individual information technologies. The amount
of very different computer models was really vast. We only have
one computer today, that was promoted by the richest man on Earth =(
Can somebody be fully satisfied with this evolution ? I'm not really.

Do you still run ATARIs ? I do it, even for professional usage =)

Best regards,

[Miro Kropáček]

Post by Francois LE COAT
Nowadays, the evolution of ATARI developers' world, implies that I can't
continue programming, because GNU/GCC 4.2 for ATARI is inappropriate for
old sources in C language.

You do understand that Atari/FreeMiNT has nothing to do with this and versions past 4.6.4 (I guess this is the version you're referring to) are even more strict, to make more issues visible, right?

Either fix your code or use the older gcc versions, you're free to continue your programming. ;)

[Francois LE COAT]

Hi,

Post by Miro Kropáček

Post by Francois LE COAT
Nowadays, the evolution of ATARI developers' world, implies that I can't
continue programming, because GNU/GCC 4.2 for ATARI is inappropriate for
old sources in C language.

You do understand that Atari/FreeMiNT has nothing to do with this and versions past 4.6.4 (I guess this is the version you're referring to) are even more strict, to make more issues visible, right?
Either fix your code or use the older gcc versions, you're free to continue your programming. ;)

What worries me the most, is that there's no 16bits integer type. The
C language is inappropriate for 16/32bits ATARI machines. It would have
been convenient if Motorola had maintained the 68k processors series,
but it was abandoned. There's no need to renew the C semantic, because
the machines didn't evolved. I don't want to put all my code up-side-
down because it's 30 years old, and I began learning Kernighan and
Ritchie in 1987.

So, of course I will continue using GNU/GCC 3.3.6, but it's not
maintained for ATARI old sources like mine. There's no cross-tools.

The situation where I'm arrived has a name : programmed obsolescence.
That means that all is done for the younger generation to forget what
was done before them. The information technology has no history, no
memory, no past !

Regards,

[Michael Schwingen]

Post by Francois LE COAT

Post by Miro Kropáček
You do understand that Atari/FreeMiNT has nothing to do with this and versions past 4.6.4 (I guess this is the version you're referring to) are even more strict, to make more issues visible, right?
Either fix your code or use the older gcc versions, you're free to continue your programming. ;)

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.

cu
Michael

[Francois LE COAT]

Hi,

Post by Michael Schwingen

Post by Francois LE COAT

Post by Miro Kropáček
You do understand that Atari/FreeMiNT has nothing to do with this and versions past 4.6.4 (I guess this is the version you're referring to) are even more strict, to make more issues visible, right?
Either fix your code or use the older gcc versions, you're free to continue your programming. ;)

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 =(

Regards,

[Michael Schwingen]

Post by Francois LE COAT

Post by Michael Schwingen

Post by Francois LE COAT
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.

cu
Michael

[Francois LE COAT]

Hi,

Post by Michael Schwingen

Post by Francois LE COAT

Post by Michael Schwingen

Post by Francois LE COAT
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,

[Miro Kropáček]

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.

Post by Francois LE COAT
Hi,

Post by Michael Schwingen

Post by Francois LE COAT

Post by Michael Schwingen

Post by Francois LE COAT
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/

[Francois LE COAT]

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,

Post by Miro Kropáček
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.

Post by Francois LE COAT

Post by Michael Schwingen

Post by Francois LE COAT

Post by Michael Schwingen

Post by Francois LE COAT
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,

[Miro Kropáček]

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.

Post by Francois LE COAT
Hi,
<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,

Post by Miro Kropáček
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.

Post by Francois LE COAT

Post by Michael Schwingen

Post by Francois LE COAT

Post by Michael Schwingen

Post by Francois LE COAT
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/

[Francois LE COAT]

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.

Post by Miro Kropáček
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.

Post by Francois LE COAT
<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 ?

Post by Miro Kropáček
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.

Post by Francois LE COAT

Post by Michael Schwingen

Post by Francois LE COAT

Post by Michael Schwingen

Post by Francois LE COAT
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,

[Miro Kropáček]

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".

Post by Francois LE COAT
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,
<http://patrice.mandin.pagesperso-orange.fr/en/howto-cross333.html>
but, with the versions of binutils, mintlibs of the same generation.

Post by Miro Kropáček
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.

Post by Francois LE COAT
<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 ?

Post by Miro Kropáček
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.

Post by Francois LE COAT

Post by Michael Schwingen

Post by Francois LE COAT

Post by Michael Schwingen

Post by Francois LE COAT
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/

[Francois LE COAT]

Hi,

Please consider that I'm concerned by ATARI (old) applications. I'm
not a "system" developer, I've never been, like you are. Some of the
historical applications like Calamus, Cubase, Chrystal ATARI
Browser (CAB), Papyrus, Photoline, Rainbow Painter, XnView are
really famous today. freeMiNT doesn't have the fame of GNU/Linux.
I've always been shocked by the supremacy taken by OSes in
peoples' mind. Sorry, I'm not an expert from freeMiNT mailing list.

Post by Miro Kropáček
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".

Post by Francois LE COAT
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,
<http://patrice.mandin.pagesperso-orange.fr/en/howto-cross333.html>
but, with the versions of binutils, mintlibs of the same generation.

Post by Miro Kropáček
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.

Post by Francois LE COAT
<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 ?

Post by Miro Kropáček
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.

Post by Francois LE COAT

Post by Michael Schwingen

Post by Francois LE COAT

Post by Michael Schwingen

Post by Francois LE COAT
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,

[Henk Robbers]

Post by Francois LE COAT
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.

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.

[Francois LE COAT]

Hi,

Post by Henk Robbers
I disagree. I always considered 16 bit integers too small for
a computer as modern as the ATARI ST having loads of ram.

Well, nowadays the Mathematica application on my computer is
4785606192 bytes. That makes me curious, because Eureka 2.12
is contained in a 720kb floppy, and runs entirely in 1Mb of RAM.

Post by Henk Robbers
(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.

Post by Henk Robbers
That's why I replaced all occurences of int in AHCC and its libraries
by short and created the sinclude folder of header files.

That's how I use AHCC, with short includes compatible with PURE C.

Post by Henk Robbers
Still works like a charm.

For the moment, I can entirely build Eureka 2.12 with AHCC 5.5. But
it is not working exactly as expected. That gives me hope !

Best regards,

[Michael Schwingen]

Post by Francois LE COAT

Post by Henk Robbers
(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).

cu
Michael

[Francois LE COAT]

Hi,

Post by Michael Schwingen

Post by Francois LE COAT

Post by Henk Robbers
(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).

My Hades060 has 40Mb of RAM, and I can't use virtual memory because
it's only possible with 68030 processors. I use GNU/GCC 3.3.6 with it.
This amount of memory is just enough to build Persistence Of Vision.
POV-Ray in its 3.1g version is very large C language sources, and it
requires a lot of memory to be built. It's the largest software I
ever built with an ATARI machine. POV-Ray doesn't require so much
memory to launch it, but GNU/GCC does because it's very big sources.
At the period when I built it, I had no cross-compiler. I had to
use the native GNU/GCC. All is simpler when you cross-compile, today.
I still don't have GNU/GCC 3.3.6 cross-compiler, that _really_ miss !

[Miro Kropáček]

Post by Francois LE COAT
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.

[Francois LE COAT]

Hi,

Post by Miro Kropáček

Post by Francois LE COAT
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.

freeMiNT abandoned the support of virtual memory since a very long time.
The only solution remaining is Outside from Uwe Seimet, only for 68030.
I wasn't speaking of memory protection, but about "virtual memory".