Native 68k Netsurf

[wawrzon]

ive uploaded the source as well as libs and includes sent me by artur here:

http://www.daten-transport.de/?id=F3g3e2eayzcD

since ive ended up using not exactly the same libs and includes as him ive uploaded what differs in files marked with wawa. it must be only libcurl and libxml2 related.
devcpp project included is meant for testing the particular sources.
you will have to edit or create makefile.config ive initially removed all plugins from the build.

hope nothing has been messed up while upload. im sitting on a bad mobile connection here.

[wawrzon]

btw, i always comment my changes to whatever sources with //wawa, so its easy to find. in this particular case i only remember to have made one or two.
in case of problems or further requests please come back to me. also if any include is missing, my whole folder is multiple mb, i just cant upload it from here.

[wawrzon]

lets give it a try, none here is contributing to netsurf sdl so no time wasted, and netsurf dev team is critical baout doing plane sdl ports, so an native port would fit their agenda. also sdl not being slow in itself, netsurfs sdl plotters might be not as optimal since they do not get much attention from netsurf team. i think its good to have a netsurf port across amiga platforms, as it coule be debugged better. i just wish chris had chosen mui 3.x rather than reaction which would make this more portable (mos and aros in my mind)

[wawrzon]

Artus should send you complete archive, only you need do is make and all compile.I have no actual version

but its important that you not use GCC 3.4.0.use GCC4, because GCC 3 give you only buggy code, when you enable optimizer.

hubbub is compiling fine now. gcc4.5.0 problem does still apply.

[wawrzon]

that xinvaders 3d work with amiga port of x11 was a pure luck, i have not been able to compile any other x application for 68k.

and i dont have any os4 installation anymore. sorry.

[wawrzon]

aminet seems to be down atm, otherwise i would point you to a few simple sdl game ports i ve done. it was always my priority to have it working on classic at acceptable (if not always at full) speed.

[wawrzon]

hmm. i wasnt into this for a week, but maybe really given as bernd says that the x11 game i ve compiled was quite snappy on my a4k, maybe it would be interesting to update the x11 68k port as far as possible. i suspect though it was just due to its pure line vector gfx.

[wawrzon]

if c2p only costs 10% then it would advocate to include support for it it into sdl or netsurf.

[wawrzon]

please guys, bernd is not trolling even if it looks like that. given his record of engagement for 68k, even if he is an uae-guy, he just tries to be reasonable about what can be done given current ressources. lets be honest, it doesnt look like we have any magick coders around any more.
i personally am all for trying to get netsurf with a native frontend and see if this helps, but im a noob who isnt even able to do it even if i would like. artur at least did a sdl port with bernds and itix help, which is an achivement we should be grateful of. and bernd considers netsurf easier to maintain without too much amiga-code in it. thats his point. thats it.

and now back to topic, did anyone got any further with it in the meantime? i pass for the time being, sorry.

[wawrzon]

dont see any monkey frontend here  to compile for..
i think the build system is set up ok. just to reprogram the amiga frontend is a little too much one could expect from me..

[wawrzon]

have you seen what dependencies that demands? wxwidgets port would be a major task i suppose. why to propose such a complicated thing if even mauch simpler doesnt get done?

[wawrzon]

the benchmarks should be made loading a page saved locally to a harddrive, displayed in same resolution in the same screen depth. if done like that they are meaningful.

This is a completely bogus/meaningless comparison.  Firstly, a 100MHz
68060 and a 100MHz PPC440 aren't going to be running at the same
speed.  Even a 100MHz 68060 and a 100MHz 68040 aren't the same speed.
Secondly, the code they are running is completely different, compiled
for a different target and by a different compiler, with different
frontend code.  Moreover, one of the processors is CISC and the other
is RISC - RISC processors have to execute more code by their very
nature of having a smaller instruction set.  The display resolution of
the test machines is also different, the OS4 ones having to do more
rendering (unless screen res or window size was adjusted to
800x600x16, which I doubt, and would also impact the figures
negatively as there is a known slowness issue with 16-bit in the OS4
frontend)

i dont know but it is perfectly possible that resolution of netsurf on a classic was set to 800x600x16, there is no pages on internet that you can watch comfortably in a lower resolution and every amiga gfx card is capable to display this and more. i myself was setting netsurf 68k window on my a4k to about 1000x1000 when i was using it.

besides for the end user who doesnt care about processors instruction set, compile options and the gui frontend used but if application works and how fast, the comparison between os4 implementation and 68k port is perfectly sane. you, chris, should be interested yourself to identify bottlenecks, in case the comparison was fair.

äh, edit:
in particular:

Moreover, one of the processors is CISC and the other
is RISC - RISC processors have to execute more code by their very
nature of having a smaller instruction set.

might be that risc ppc processors are actually by default slower per clock than cisc 68k counterparts, as they were invented to allow them to run at for that time technology otherwise unreachable higher clocks, but then it remains an argument, because people usually count cpu speed in mhz, as in 660mhz sam440 vs amiga060/50. why argue with that?

[wawrzon]

Only if compiled and running on the same CPU too.

if i get you right, you mean you dont want to compare two things at a time: architecture and the software implementation. otherwise the result of comparing something to itself on the same cpu should be always 1:1. the problem is sometimes architecture implies the implementation, like for instance ppc/os4>reaction. generally i think you may compare everythyng to anything as soon as you have set a single benchmark. in this case its netsurf engine. of course the benchmark becomes increasingly meaningful when narrowing test categories, but one has to start somewhere.

To clarify, this is the reported resolution on classic in Bernd's orignal email.  I was doubting that the OS4 machines had been set to this (although 16-bit creates a bottleneck on NetSurf-OS4 anyway, so I'd rather any tests were done in 32-bit mode)

wasnt then the testcase in favour of ppc/os4 anyway? i thought 32bit was choosen there.

That would be fine if it was a fair comparison, but it isn't.  It may as well have been comparing NetSurf OS4 to Lynx running on Mac OSX for the amount of useful data it generated.

i would call it a fair testcase if we were comparing different browsers on different architectures. we wonder why amiga (68k) sdl and os4 reaction netsurf ports are so slow in comparison to native risc os 68k implementation. this implementation differs as much from both as os4 differs from 68k, you dont find it a question worth examinating, do you? just being comfortable that it runs on os4 at all since the cpu is fast enough?

See also:
http://vlists.pepperfish.net/pipermail/netsurf-dev-netsurf-browser.org/2011-July/002523.html
http://wiki.answers.com/Q/What_is_a_controlled_experiment

Chris

will check this out as soon i can.