Roadshow for 68K -Needs your support!

[Fab]

@olsen

I believe roadshow (at least for OS4) got rid of the following two limitations of other amiga TCP stacks:
- bsdsocketbase couldn't be shared, and bsdsocket.library had to be opened in each process.
- sockets couldn't be shared across threads.

First, is it right?
Second, as I have no idea if it also needs special support on the OS side itself, would the 68k version of roadshow also provide this?

[olsen]

Why would need it for MorphOS anyway, we have already got a stack

I only mentioned it because the question did come up before, and there was a demand for a TCP/IP stack. Given that Roadshow outperformed AmiTCP under identical circumstances it wasn't hard to expect that it could have done the same under MorphOS.

[Piru]

Don't hate me, but contractual obligations prevent me from releasing a MorphOS version, even if I were able to make one.

Interesting contract.

[olsen]

@utri007

good thought! How about it Olaf? Is it something you can do about it or is it something the whdload developers should fix?

I don't know why WHDLoad does not permit a TCP/IP stack to be active while it runs. Since both AmiTCP and Miami are apparently not supported, it might well be that the mere presence of a TCP/IP stack would be an issue. But then I do not know the technical background or justification behind this.

[olsen]

Interesting contract.

*Tactically* interesting contract, actually.

[olsen]

@olsen

I believe roadshow (at least for OS4) got rid of the following two limitations of other amiga TCP stacks:
- bsdsocketbase couldn't be shared, and bsdsocket.library had to be opened in each process.
- sockets couldn't be shared across threads.

First, is it right?

These limitations came out of the design of the original AmiTCP implementation. In Roadshow I found a way to avoid these specific limitations, but by default Roadshow still keeps enforcing them.

Client software can disable these limitations through API functionality quite easily, and this is what, for example, newlib.library on OS4 will do by default. The reason for keeping the limitations enabled is that I wanted to maintain backwards compatibility with how AmiTCP and Miami behaved when sockets and the library base were shared by different Processes. Roadshow consistently flags any such attempts as errors. But if the client software knows what it's doing, it can override this "protection".

Second, as I have no idea if it also needs special support on the OS side itself, would the 68k version of roadshow also provide this?

This is purely a feature of the TCP/IP stack implementation, or rather a side-effect, and is not rooted in operating system features.

[Piru]

I don't know why WHDLoad does not permit a TCP/IP stack to be active while it runs. Since both AmiTCP and Miami are apparently not supported, it might well be that the mere presence of a TCP/IP stack would be an issue. But then I do not know the technical background or justification behind this.

The interrupts generated by the network hardware I believe.

[Piru]

*Tactically* interesting contract, actually.

Much like the Directory Opus Magellan deal, except this one worked.. ;-)

[matthey]

It may, but as you know it is totally irrelevant for something as I/O bound as TCP/IP stack.

The performance difference I've seen between 020 and 060 optimized code has always been insignificant. This was, however, before gcc3/gcc4 so perhaps things have improved since then.

A 68060 version should be better than a 68020 version for the 68060 if the compiler can...

1) schedule instructions for the 68060
2) avoid missing trapped instructions (64 bit integer instructions only if no fp)
3) prefer instructions that work in both integer units of 68060

Most compilers generating 68060 code will do better with 1 & 2 while few understand 3 even though it can speed code by up to 2x alone. I would say a 68060 version is still justified for reasons 1 and 2. Separate 68000, 68020, 68040 and 68060 versions would be nice for stable major releases.

@olsen
GCC3 and GCC4 generate worse code than SAS/C. Switching to any other compiler for a 68k only release would be a waste of time IMHO.

I'm somewhat interested in RoadShow but I'm wary of orphaned programs with no bug fixes or source code available. Although you are a great Amiga stalwart, I would like some kind of future plan for the continuation of the product with or without you. I like the idea of a more reasonable price as a download from a website with a PayPal buy it now link. It's not that difficult to do anymore. I would buy the newest CED if it was distributed this way and was 1/2 the cost also.

[Piru]

A 68060 version should be better than a 68020 version for the 68060 if the compiler can...

1) schedule instructions for the 68060
2) avoid missing trapped instructions (64 bit integer instructions only if no fp)
3) prefer instructions that work in both integer units of 68060

Most compilers generating 68060 code will do better with 1 & 2 while few understand 3 even though it can speed code by up to 2x alone. I would say a 68060 version is still justified for reasons 1 and 2. Separate 68000, 68020, 68040 and 68060 versions would be nice for stable major releases.

This is the theory, indeed. In practice, however, I've never seen any real benefits in toggling between 020, 030 040 or 060 targets when running the code on 060. Even the case 2 is handled by Cyberpatcher.

In most cases the C compiler produces adequate results as long as you tell it to produce 020+ code. Back when I was still into 68k I used SAS/C and gcc and checked out the code produced for performance issues. It was quite awful. Even when I told gcc to produce code for 060 it would still use the instructions that would get generate an exception. The generated code had no sensible scheduling. If I really needed the speed I optimized the critical part(s) by hand.

[olsen]

@olsen
GCC3 and GCC4 generate worse code than SAS/C.

That was to be expected. GCC seems to have a slant towards the x86 platform these days. Other architectures receive far less attention. I recently read that because the quality of the code produced for embedded platforms such as ARM and PPC left so much to be desired, more and more commercial developers went with the compilers provided by the hardware vendors. Apple's support for the LLVM compilers also speaks for itself.

Switching to any other compiler for a 68k only release would be a waste of time IMHO.

The warnings flagged for the code are sometimes more helpful than what SAS/C manages to produce (and the other way round, actually). But I wouldn't want to use the old GCC I have at hand for high performance production code.

I'm somewhat interested in RoadShow but I'm wary of dwarfed programs with no bug fixes or source code available.

If it's any consolation, Roadshow has been used in OS4, and has evolved with it, for the past 8-9 years.

Although you are a great Amiga stalwart, I would like some kind of future plan for the continuation of the product with or without you.

Yes, this is how it ought to be. It didn't help that Holger Kruse suddenly dropped out of the picture with Miami, did it? As for my own plans, I admit that until about two weeks ago I did not have any for Roadshow 68k any more. So, give me a little time and a few ideas to wrestle with, and maybe I'll be able to come up with a long term perspective for Roadshow.

I like the idea of a more reasonable price as a download from a website with a PayPal buy it now link. It's not that difficult to do anymore. I would buy the newest CED if it was distributed this way and was 1/2 the cost also.

CygnusEd comes on a physical CD-ROM, each one specially made for the customer. There's a price tag for shipping, too, and the CD-ROM acts as something of a weak "copy protection". Meaning that updates & patches are based upon what's on the CD-ROM.

So, you suggest changes may be a good thing? I'm currently working on getting the next CygnusEd out the door. Something which I neglected to attend to in the past few years, on account of severe Amiga burnout.

[pVC]

There have been cheap offers for amigaish programs lately, and when it's stayed around 10e, I've bought them even if I don't need it that much. I think it's a good tactic in today's situation.

That 10e, for example, is cheap enough to attract even occasional Amiga triers to buy the software instead of pirating or giving up. At least when it's easily available (web download, paypal). And also for long time Amiga hobbyists, who are thinking if it's worth to buy new software or stick with old options.

I don't think there are that much heavy users who are willing to pay tens of euros anymore. Low price and availablility would benefit whole Amiga community, and I believe author too, better than rarely bought expensive product.

I'm happy with AmiTCP/IP Genesis on my classic Amigas with my current usage, but if it will be around 10e I'll promise to buy it anyway

EDIT: same apply to CED too. I've been thinking of buying later version, but it's just too expensive in current form and situation (I bought CubicIDE when it was on <20e offer, but I'd rather use CED ).

[Orphan264]

Add me to the list of people interested!!

[kolla]

I really don't see the point, yet another utterly limited and primitive IP stack for Amiga, and also this time one is supposed to pay for it - why bother?

Edit: The only thing I'd be willing to pay for, is for the sources to be released under open source license.

I strongly refuse to pay for binaries when it comes to Amiga these days, not because I cannot afford it, but because I have experienced how painfull it is with these binaries after relatively short time, as authors abandon them.

[itix]

I really don't see the point, yet another utterly limited and primitive IP stack for Amiga, and also this time one is supposed to pay for it - why bother?

Currently it is impossible get any TCP/IP stack for real Amigas unless you pirate Miami. Better than not having TCP/IP stack at all although I dont think there are many users left... WinUAE users wont need it.

Another option would be porting MosNet/AROS TCP but I dont see it happening either...

[Piru]

Currently it is impossible get any TCP/IP stack for real Amigas unless you pirate Miami.

Actually that is not the case. GPL AmiTCP/IP is available (AmiTCP-bin-30b2.lha).