New 68k gcc toolchain

[arti]

Hi!

Finally new gcc 4.5.4 + clib2 linux for 68k target!

I've just built hhexen-1.6.3 using it!

Ixemul and libnix build was quiting itself to workbench.
So now we have third option

You can grab it here:

http://ci.netsurf-browser.org/builds...hains/?C=M;O=D

I 'molested' netsurf devs to make it

[Thorham]

How good is the code it produces?

[arti]

I don't know.
I could compile some test program to check.

[flype]

Hi, it is good news, thank you.
I can see there is an update today.
http://ci.netsurf-browser.org/builds...4-01-36.tar.xz

Is it usable with ADE ?
http://aminet.net/package/dev/gcc/ADE

[utri007]

Chris has fixed toolchain and Netsurf and all depencies builds now. Compiled Netsurf exe even starts now but crash before it opens window

I've also spent quite a while fixing all the compiler and linker errors for the OS4 build, when passed through the 68k toolchain. It now builds and runs (don't get too excited) as far as errorneously displaying the splash window as a long thin window at the top of the screen. It then crashes, probably somewhere between initialising the DataTypes handler and initialising NetSurf.

68k source with changes are here http://git.netsurf-browser.org

He is asking help to fix remaining bugs, so NOTE: This would be officially supported build, unlike current SDL + Framebuffer Netsurf.

More about Chris's effort to get proper Netsurf for 68k Amigas here :

http://www.amiga.org/forums/showthre...t=63990&page=9

[alexh]

http://www.amiga.org/forums/showthre...t=63990&page=9

[utri007]

About Netsurf : http://www.amiga.org/forums/showthre...=63990&page=17

The font scanner appears to be working but freezes at the end, I suspect it's another NULL pointer access. Actually I'm suspecting I've done something wrong with my list access loops, which are defined like this:


Code:
node = GetHead(list);
do {
nnode = GetSucc(node);
// more code here
} while((node = nnode));This works fine on OS4, but when built for OS3 I think it's not stopping properly

GetSucc(node) is defined as node ? node->ln_Succ : NULL
It was just node->ln_Succ but I put some extra armour around it. It doesn't seem to have helped though.

GetHead is:

Code:
struct Node *GetHead(struct List *list)
{
struct Node *res = NULL;

if ((NULL != list) && (NULL != list->lh_Head->ln_Succ))
{
res = list->lh_Head;
}
return res;
}Can anybody spot anything obviously wrong?

Other than that, see if the previous two hits were fixed. You can trick it into skipping the font scan by creating a file in your user directory called FontGlyphCache, containing:
0x0000 "CGTimes"

[alkis]

Umm, isn't GetHead returning a null when there is just one element in the list?

[Alexco]

May I ask why version 4.5 and not the latest 4.x? Just curious. And on which distribution does this work?

[arti]

Maybe it was easier to patch? I don't know, you better ask Chris Young.
Anyway it is now downgraded to 3.4 for better 68k code.

I tested on Ubuntu and debian.

[matthey]

Originally Posted by alkis

Umm, isn't GetHead returning a null when there is just one element in the list?

I don't think so. Exec lists are a little different than most doubly linked lists. From page 494 of the RKRM Libraries, the following 2 ways are suggested for determining if a list is empty.

1)

if (NULL != list->lh_Head->ln_Succ)
   printf("list is empty\n");

2)

if (list->lh_TailPred == (struct Node *)list)
   printf("list is empty\n");

Neither is very pretty. Not mentioned is a macro in exec/lists.h includes which uses the 2nd method above (probably the more optimal method with most compilers) but looks better IMO.

if (IsListEmpty(list))
   printf("list is empty\n");

Substituting with the macro, we come up with the following.

struct Node *GetHead(struct List *list)
{
	struct Node *res = NULL;

	if ((NULL != list) && (!IsListEmpty(list))
	{
		res = list->lh_Head;
	}
	return res;
}

Does that look better and correct? If we know the list is at least properly initialized, the (NULL != list) can be dropped also.

Originally Posted by arti

Maybe it was easier to patch? I don't know, you better ask Chris Young.
Anyway it is now downgraded to 3.4 for better 68k code.

I thought I was using GCC 3.4 for a long time but it was only GCC 3.3 because of an install problem. When I fixed my install so I was using GCC 3.4, the executables were noticeably larger and the compiler noticeably slower. GCC 3.3 had a few bugs but it was usable for my smaller projects. It was pretty close overall to GCC 2.95.3 in 68k code generation.

Originally Posted by arti

Is it possible to use vbcc math .lib in gcc ?

It would not be easy. GCC uses its own static link library format. I believe vbcc uses a format similar to what SAS/C used. A static or dynamic library could be created with the vbcc vclib math library code using different names. For example, the C= mathieeexxx.library math libraries can be called from GCC even if there is not a compiler option to use them implicitly. The C= libraries do not provide a complete c99 implementation though. It may be easier to fix up vbcc's integer code generation. The basic vbcc integer code generation is not bad just too simple. NetSurf is only written in C (no C++) but does require c99 in recent versions. Vbcc received some c99 updates including c99 include files like inttypes.h (Frank Wille should be able to send you updates). Have you tried to compile NetSurf with vbcc? If so, what was lacking?

[arti]

Originally Posted by matthey

Have you tried to compile NetSurf with vbcc? If so, what was lacking?

Not yet, but I imagine it would be too much work.
Just got NetSurf working with libnix. It works better than clib2, no problem with events and slowdown after loading 4th page.
It is only lacking %zd, %llu in printf functions.
Maybe it can be enabled like in clib2 by putting -lc before -lm ?

Do you know this?

[matthey]

Originally Posted by arti

Not yet, but I imagine it would be too much work.
Just got NetSurf working with libnix. It works better than clib2, no problem with events and slowdown after loading 4th page.
It is only lacking %zd, %llu in printf functions.
Maybe it can be enabled like in clib2 by putting -lc before -lm ?

Do you know this?

Libnix is very well written but it is old and not updated. Long long (64 bit integers) were not at all common back in the day. GCC supported them before they became standard in C so maybe libnix didn't fully support them? I don't see any mention in the libnix.guide but I would have expected %llu to be supported. The %zd is C99 which I believe came after libnix.

It looks like vbcc should support %zd and %llu from looking at the vclib vfprintf() source. Vbcc does *not* currently support the uncommon C99 floating point %a hex notation. Vbcc is strict for whatever version of C is selected and will often generate many warnings and errors by default. GCC uses its own non-conforming sloppy version of C by default and is quiet about many warnings and errors. The sloppiness of GCC is less overwhelming for porting projects but vbcc has its advantages of making sure the code is more C compliant and portable. They are different beasts and vbcc has its own learning curve.

[arti]

Libnix was updated to version 3.0 by Diego Casorran.
https://github.com/diegocr/libnix

Does any of this flags make anything better?
-D__USE_BASETYPE__ -D__USE_INLINE__ -U__STRICT_ANSI__ -DSTMATH

[matthey]

Originally Posted by arti

Libnix was updated to version 3.0 by Diego Casorran.
https://github.com/diegocr/libnix

I didn't know libnix was updated. Thanks for the link.

Looking at libnix/stdio/vfprintf.c (used by printf), I don't see any support of %zd or 64 bit integers. I doubt changing switches or variables will solve this. Have you tried contacting Diego Casorran with your questions and needs?

[arti]

Yes, he didn't answer, but I managed to compile libnix myself so I can now add anything I need.

[arti]

Looks like libnix version is working fast and stable.
It could be faster with some asm optimisations.
@matthey are you interested ?

[matthey]

Originally Posted by arti

Yes, he didn't answer, but I managed to compile libnix myself so I can now add anything I need.

It is good that you can compile the project but it would be better to have someone familiar with the code cooperating.

Originally Posted by arti

Looks like libnix version is working fast and stable.
It could be faster with some asm optimisations.
@matthey are you interested ?

The assembler code in libnix/math/mul64.c is already from me. Assembler inlines for libnix/misc/bcopy.c and libnix/misc/bzero.c could be advantageous. Most of the code should probably remain in C (some of it needs updating for 64 bit integer support) although some C optimizations are still possible.

It looks like the glibc (GNU library) source for vfprintf.c has changed significantly.

https://fossies.org/dox/glibc-2.21/v...8c_source.html

The source code of the new version of vfprintf() is huge. You could try adapting it for libnix but I wouldn't be surprised if resulting executables are also significantly larger. Maybe an older version of vfprintf() could be found that has 64 bit integer support but before the rewrite. The vbcc vclib source is similar to the old vfprintf() but has support for %llu and %zd. The libnix source has the following line.

if (*ptr=='h' || *ptr=='l' || *ptr=='L')

While the similar vclib code has the following.

if (*ptr=='h' || *ptr=='l' || *ptr=='L' || *ptr=='j' || *ptr=='z' || *ptr== 't')

It may not be too difficult to adapt the vclib vfprintf() for what you need. Of course, vfscanf() and others should be updated for consistency. What seems like small changes can end up being a lot of work. This kind of work needs to be organized and documented so problems can be rolled back and so the whole project doesn't become a mess.