Welcome, Guest. Please login or register.

Author Topic: Should we really crack IBrowse 2.4???  (Read 85513 times)

Description:

0 Members and 1 Guest are viewing this topic.

Offline matthey

  • Hero Member
  • *****
  • Join Date: Aug 2007
  • Posts: 1294
    • Show all replies
Re: Should we really crack IBrowse 2.4???
« on: October 13, 2012, 05:49:48 PM »
@wawrzon
The latest AmigaOS 4 version of AWeb APL 3.5.10 from Andy Broad includes the sources to compile for AmigaOS 3.x. It's available on OS4Depot.

http://os4depot.net/index.php?function=showfile&file=network/browser/aweb.lha

I tried to compile it with GCC 3.4.0 but the complicated make script file had problems. I used to get older versions of AWeb APL to compile most of the way through in AmigaOS 3.x. Let me know if you can figure out how to fix the compile problems. I might have to help out if you get it fixed up to compiling again ;).
 

Offline matthey

  • Hero Member
  • *****
  • Join Date: Aug 2007
  • Posts: 1294
    • Show all replies
Re: Should we really crack IBrowse 2.4???
« Reply #1 on: October 13, 2012, 11:05:29 PM »
Quote from: itix

FPU instructions can generate slightly different results due to differences in 68k and PPC FPU

Quote from: ChaosLord;711312
Is the same thing true with WinUAE, UAE, etc?

I am wondering how careful I must be when using floats.


Most 68k FPU "emulations" and probably even new 68k fpga/ASIC FPU's will use a 64 bit double (.D) float instead of the 80 bit FPU register/96 bit load and save extended (.X) format. The 68k FPU was an improvement of the x86 FPU which also used a higher precision than double float extended format. Almost no other modern mainstream CPU supports more than double float for speed. The extended precision bits beyond a double (and some rounding bits) are left off in the register while extended precision format is supported for immediates and an . It's usually not a problem unless assumptions are made about the least significant bits in a floating point register which isn't a good idea anyway. It's best to avoid extended precision immediates (trapped on 68060) and extended precision format for loading/saving except for FMOVEM.X to load/save registers. In general:

1) extended precision in a register is ok and means modify the whole register
2) extended precision immediates and format for an mean let's be slow and we are going to lose any extra precision past a double float anyway ;).
 

Offline matthey

  • Hero Member
  • *****
  • Join Date: Aug 2007
  • Posts: 1294
    • Show all replies
Re: Should we really crack IBrowse 2.4???
« Reply #2 on: January 25, 2013, 12:42:26 AM »
Quote from: NovaCoder;723887
Well you always have to cross compile when coding for Amiga on any modern projects because the only modern compiler we have is gcc (UNIX).

Vbbc isn't modern? Ouch!

Quote from: NovaCoder;723887
With NetSurf you have to setup your own UNIX cross compiler environment (eg using Cygwin) and then manually edit the various makefiles to try and get it to build a 68k executable.    This is not something I'm very familiar with or something that I'd enjoy learning how to do.

I thought C was supposed to be portable. I should be able to take the project from GCC and compile it with any other modern compiler, right? What other compilers are portable and modern? Clang?
 

Offline matthey

  • Hero Member
  • *****
  • Join Date: Aug 2007
  • Posts: 1294
    • Show all replies
Re: Should we really crack IBrowse 2.4???
« Reply #3 on: January 25, 2013, 03:03:59 AM »
Quote from: NovaCoder;723897
I've tried to build a few big projects using vbcc with CubicIDE and I could never get it to produce a reliable exe.    After coding for a few years now for Amiga 68k the only ones I've used to do anything with are StormC V4 (gcc mode) and AmiDevCpp.

Vbcc is a lot better with the last version but is developing slowly. There are newer versions of the vbcc assembler vasm that can be compiled to fix some bugs and add more optimizations. Vasm has been actively developed and is a mature product for the 68k. I wish GCC used it and a great project would be to try and retrofit it to GCC as it's supposed to be compatible with GAS. Anyway, vbbc does need some development. It's become more GCC like and more stable but it's still slow to compile and buggy on higher optimization levels. It does generate pretty good code on the low optimization levels which is good.

Quote from: wawrzon;723908
i think porting software you can forget about anything else than gcc. if you roll off your own project you can tailor it for something else.

You hit the nail on the head. Most software uses GCC and is customized for GCC. Porting with anything else is more difficult.