Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.sys.atari.st > #1553

Re: Eureka 2.12 is 30 years old

Show all headers | View raw

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.

Miro Kropáček writes:
> 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:
>>>>>>>>>> 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/

Back to comp.sys.atari.st | Previous | Next — Previous in thread | Next in thread | Find similar

Thread

Eureka 2.12 is 30 years old Francois LE COAT <lecoat@atari.org> - 2017-02-17 23:00 +0100
  Re: Eureka 2.12 is 30 years old Miro Kropáček <miro.kropacek@gmail.com> - 2017-02-22 14:40 -0800
    Re: Eureka 2.12 is 30 years old Francois LE COAT <lecoat@atari.org> - 2017-02-23 00:21 +0100
      Re: Eureka 2.12 is 30 years old Michael Schwingen <news-1457978346@discworld.dascon.de> - 2017-02-26 12:18 +0000
        Re: Eureka 2.12 is 30 years old Francois LE COAT <lecoat@atari.org> - 2017-02-26 13:47 +0100
          Re: Eureka 2.12 is 30 years old Michael Schwingen <news-1457978346@discworld.dascon.de> - 2017-02-26 15:18 +0000
            Re: Eureka 2.12 is 30 years old Francois LE COAT <lecoat@atari.org> - 2017-02-26 17:00 +0100
              Re: Eureka 2.12 is 30 years old Miro Kropáček <miro.kropacek@gmail.com> - 2017-02-26 14:22 -0800
                Re: Eureka 2.12 is 30 years old Francois LE COAT <lecoat@atari.org> - 2017-02-27 00:00 +0100
                Re: Eureka 2.12 is 30 years old Miro Kropáček <miro.kropacek@gmail.com> - 2017-02-27 14:14 -0800
                Re: Eureka 2.12 is 30 years old Francois LE COAT <lecoat@atari.org> - 2017-02-28 23:43 +0100
                Re: Eureka 2.12 is 30 years old Miro Kropáček <miro.kropacek@gmail.com> - 2017-03-01 14:12 -0800
                Re: Eureka 2.12 is 30 years old Francois LE COAT <lecoat@atari.org> - 2017-03-04 21:51 +0100
              Re: Eureka 2.12 is 30 years old Henk Robbers <h.robbers@chello.nl> - 2017-02-26 23:49 +0100
                Re: Eureka 2.12 is 30 years old Francois LE COAT <lecoat@atari.org> - 2017-02-27 18:18 +0100
                Re: Eureka 2.12 is 30 years old Michael Schwingen <news-1457978346@discworld.dascon.de> - 2017-02-27 21:31 +0000
                Re: Eureka 2.12 is 30 years old Francois LE COAT <lecoat@atari.org> - 2017-02-28 22:40 +0100
                Re: Eureka 2.12 is 30 years old Miro Kropáček <miro.kropacek@gmail.com> - 2017-03-01 14:10 -0800
                Re: Eureka 2.12 is 30 years old Francois LE COAT <lecoat@atari.org> - 2017-03-02 21:47 +0100

csiph-web