new os3.x software ?

[Gulliver]

@matthey
Thank you for your answer, that was really what i was looking for. I am waiting for a little vacation and will tinker with those a bit

I will ansiously wait for your datatypes.library and diskfont.library optimized versions.

[kolla]

I'm very curious on what kind of optimizations that has gone into c:Makedir of OS 3.9 :laughing:

[utri007]

There is something wrong with your setup, I've 060 66mhz with 66mb memory, about half of it is free after loading of amiga.org

[Gulliver]

@utri007
Now surf to http://www.yahoo.com and tell me how much free ram you have. Memory consumption is site dependant. Some web layouts require more ram than others. So check

[unusedunused]

Bounties IMO are a good idea, but how successfull they will be depends on the number of active OS3.x/M68k developers there are with sufficient time to do the coding. There are lots of OS3.x users but not many active developers.

My tuppence worth.

Weed

>Bounties IMO are a good idea, but how successfull they will be depends on the number of >active OS3.x/M68k developers there are with sufficient time to do the coding. There are >lots of OS3.x users but not many active developers.

there are a lot of 68k devs, on 68k there is the most own program software written, but because on other AOS systems there are bounties and the MOS OS4 developers do many ports, and news sites report more when a new OS4/MOS program come, then 68k is more in the background of publicity.but when look in aminet or OS4depot you can see that the same few people do most of programs (Ports) for OS4 or MOS.but there are also programmers that support all systems .They can good program and its only seen from "the Unix Software Porters" that platform independeent programs that are portable written only run on a special AOS.

[Crumb]

- SFS ported to 68000

It would be cool to be able to use SFS on plain 68000. I wouldn't mind about sourceforge's SFS being recompiled so we can use TD64 version with TD64 hd controllers from phase5, warpengine, individual computers... without the need of OS3.9 romupdates.

[DavidF215]

@DavidF215
I'm pretty sure bernd_afa's SDL uses Warp3D. It works well but it's still slow because SDL can only work in a few graphics formats. Many SDL programs also use ixemul which is also slow. These are usually coded with GCC which doesn't optimize well. Get the picture?

The picture being that Amiga dev tools are old and in need of updating? Got that pict; plus maybe skipping Amiga SDL. Is it the SDL framework/library that uses ixemul or the actual programs coded using SDL? Anyone know if Hyperion plans to update Amiga-GCC?

[fishy_fiz]

OS3.x native devtools are maybe a little outdated (maybe not, but it's hard to find definitie answers about where it stands, let alone binaries) for people wanting to port *nix software, but Im under the impression cross compilers are more up to date. OS4.x GCC if Im not mistaken is based on 4.1.x, so it's not too out of date. Having said though though, being that it's still an actively developed commercial product I'd be surprised if it didnt receive at least semi regular updates still.

[matthey]

@DavidF215 & fishy_fiz
GCC for PPC code generation is not nearly as bad as 68k. The newest 4.x versions of GCC still does not generate optimized code for 68k. Some of the newer versions are worse. GCC 2.9.5 may generate the best 68k code. VBCC and SAS/C generate better code in most cases. VBCC is still being updated with Amiga support which includes an awesome optimizing assembler. Frank Wille has some other developing tools he is supporting as well. Thomas Richter is actively supporting his Mu (mmu) tools. I am making a much improved version of the ADis disassembler that is already very useful. We have some of the low level tools but some of the high level tools are very sophisticated and require a lot of time and skill to perfect. Making a cross platform C compiler which supports most CPU's is a huge project much like these multi platform web browsers that we don't have. I think we are gaining some momentum and users back. If we could get a fpga solution like Natami or MiniMig+ with AGA and 020+, we might have something.

[DavidF215]

@DavidF215 & fishy_fiz
GCC for PPC code generation is not nearly as bad as 68k. The newest 4.x versions of GCC still does not generate optimized code for 68k. Some of the newer versions are worse.

What type of impact does this lack of optimization cause? I've read a little about it, but haven't read its impact. Impacting graphics performance, I/O performance, data processing performance, etc? For example, a game--what is significantlly impacted such as blitting, game logic, sound, network and at what processor level is it seen? What processor level, if any, would no longer notice the performance hit?

GCC 2.9.5 may generate the best 68k code. VBCC and SAS/C generate better code in most cases. VBCC is still being updated with Amiga support which includes an awesome optimizing assembler. Frank Wille has some other developing tools he is supporting as well. Thomas Richter is actively supporting his Mu (mmu) tools.

I have SAS/C, I think. I was using StormC3 for a while instead.

I am making a much improved version of the ADis disassembler that is already very useful. We have some of the low level tools but some of the high level tools are very sophisticated and require a lot of time and skill to perfect.

I stopped at C/C++. Tried to learn assembly but decided it was too much work.

Making a cross platform C compiler which supports most CPU's is a huge project much like these multi platform web browsers that we don't have.

Yes, I've experienced the cross platfom development can be a pain, especially deciding what dev tools to use.

I think we are gaining some momentum and users back. If we could get a fpga solution like Natami or MiniMig+ with AGA and 020+, we might have something.

This is what I'm watching, too. If a MiniMig+ with AGA (RTG maybe?) hits I might buy one to replace my aging A1200.

I've been wondering if developing for 68k would be adequate enough for most Amiga systems. It's emulated on faster machines and native on 68k hardware, so it seems a decent fit for all. Graphics seem to the the sticking point.

[fishy_fiz]

What type of impact does this lack of optimization cause? I've read a little about it, but haven't read its impact. Impacting graphics performance, I/O performance, data processing performance, etc? For example, a game--what is significantlly impacted such as blitting, game logic, sound, network and at what processor level is it seen? What processor level, if any, would no longer notice the performance hit?

Do you mean in regads to the level of support "compiler x" has ?  The code generated by a heavily optimised compiler  vs. a more generically compiled compiler can be pretty big actually. Depending on the software it's probably not impossible to achieve something around %50 faster (and more in certain cases) on a heavily optimised compiler. As for using compiler optimisations vs none using the same compiler, there's probably not a massive differerence, unless there's supporting code for "cpu x".  At the end of the day though, worse case scenario for a binary generated can be a lot worse than best case scenario depending on compilers and optimisations used.
Hope this answers what you was asking ?

[DavidF215]

Do you mean in regads to the level of support "compiler x" has ?  The code generated by a heavily optimised compiler  vs. a more generically compiled compiler can be pretty big actually. Depending on the software it's probably not impossible to achieve something around %50 faster (and more in certain cases) on a heavily optimised compiler. As for using compiler optimisations vs none using the same compiler, there's probably not a massive differerence, unless there's supporting code for "cpu x".  At the end of the day though, worse case scenario for a binary generated can be a lot worse than best case scenario depending on compilers and optimisations used.
Hope this answers what you was asking ?

Well, let's take the old game "Payback" as an example. On a 68020, would game play responsiveness and performance be noticably slower if the code was compiled with GCC (not optimized compiler) as opposed to SAS/C (optimized compiler)?

[SamuraiCrow]

@DavidF215

Actually, Payback is pretty CPU bound since it is a 3D game.  Having a better compiler would make a HUGE difference.  As for GCC vs. SAS/C, they both optimize code but neither produces near-perfect code so comparing those two might not be the best idea.  The main advantage of SAS/C is its top-notch debugger.

If somebody would offer a bounty for porting LLVM and its associated versions of GCC and the Clang C compiler to OS 3.x, I'd gladly take it.  It doesn't have a decent source-level debugger yet but that can be left for a later bounty.

[DavidF215]

@SamuraiCrow
@fishy_fiz
@matthey

So you're saying (and by what I've read) (1) that there was (is) no well optimized C++ compiler for Amiga68k but GCC 2.9.5 and SAS/C are the better options, and (2) that it doesn't really matter if one uses GCC 2.9.5 or SAS/C for 68k because none are optimized enough to make a noticable difference?

[matthey]

Well, let's take the old game "Payback" as an example. On a 68020, would game play responsiveness and performance be noticably slower if the code was compiled with GCC (not optimized compiler) as opposed to SAS/C (optimized compiler)?

GCC is more commonly thought of as a optimizing compiler than SAS/C but the 68k code generator has been so bad on some versions that it completely sabotages any effort toward optimizing. SAS/C didn't do anything complicated but did most of the simple things right. There is still room for improvement with SAS/C. It's register management is not so good but I can find very few simple (peephole) optimizations. GCC has tons. VBCC is the best at peephole optimizations because vasm, it's assembler, optimizes many of them. These small optimizations can really add up too. The Warp3D W3D_AvengerLE.library I recently edited went from 282,312 bytes to 236,908 bytes with primarily 3 optimizations (plus what vasm makes) and dead code removal. I deleted approximately 4600 useless NOP instructions alone. One test showed a 14% increase in speed on the 68060 but that would vary. The Warp3D.library is even worse optimized and one of the worst optimized libraries I have ever seen. It's kind of funny looking at who wrote Warp3D that they didn't see this. I would guess that these libraries would be 20%-50% faster and smaller if they had used SAS/C. It may be possible for Payback to be up to twice as fast if Warp3D and Payback were compiled with a good 68k optimizing compiler (doesn't exist yet) and minor optimizing algorithm changes were done.

[guest7146]

Cammy that is a work of art. I too like many it seems have decided that running OS3.1 is better overall than 3.9 . Just bought the developer cd 2.1 so I should be coding soon for the Amiga myself. I do a little php etc, so "how hard can it be??!?!"

I'm in a similar boat.  I've also just bought the developer CD, and my background is embedded programming (C, assembly), plus I know a bit of Windows application programming in C++ (though I'm not well practiced in this respect).

I'm also looking to get into Amiga programming over the Summer.

Apple_Hammer