68000 version missing

[patrikaxelsson]

Is there anything which would prevent a 68000 build of AmiSSL?

I understand that from a performance perspective, a say 7.14MHz 68000 A500 would do SSL/TLS very slowly, but I think it would be of great value that any Amiga system, disregarding cpu can use software requiring SSL/TLS.

On topic of 68000 performance, there are rather quick 68000 systems nowadays - for example an A500 with the Wicher500i accelerator which has a 68000 running at 50MHz performs impressively. Had the chance to do some comparisons against such a system and it for example extracts lha files at half the speed of a 030@25MHz A3000, so for being a 68000 it packs a serious punch.

[Futaura]

The main reason is that the GCC baserel build we are using lacks 64-bit integer math support when compiling for 68000

[patrikaxelsson]

Sorry for potentially being ignorant, but what exactly is "the GCC baserel build"?

Does this file have anything to do with it? https://github.com/jens-maus/amissl/blob/1a9d189885403a0e82f63bed3cfcd15097ec9814/libcmt/int64math.c

There are a lot of #ifdef with 68000/68060 parts there btw.

[jens-maus]

Sorry for potentially being ignorant, but what exactly is "the GCC baserel build"?

Well, what Oliver wanted to say (and all what you have to keep in mind) is: The GCC compiler suite for 68000 is not usable/capable to be used in the context of OpenSSL/AmiSSL. It misses fundamental features (baserel) which are essential for a shared library like AmiSSL and there are no newer or any further development going on in terms of getting modern compiler suites ported to OS3/68000. Thus, there are very limited chances to see any further improvements in that area. However, feel free to work on baserel support for GCC yourself and then you would increase the chances to see a pure 68000 version of AmiSSL.

[Futaura]

Jens summed it up better than I could - unfortunately I know next to nothing about building compilers. He and others spent a lot of time getting baserel working properly for m68k - I think we use https://github.com/adtools/amigaos-gcc-2.95.3. OS4 already had the feature (well, I think Stefan pestered the Friedens to add it, while porting AmiSSL v3), but it was removed after GCC 4.0.4. The feature stems back to SAS/C (as used for AmiSSL v3) which allowed shared libraries to use A6 (library base) as a small data pointer, instead of the usual A4. AmiSSL relies on this feature because OpenSSL relies too much on global variables, so we have to ensure every user of the library has their own copy of the global data. There is no getting away from it, even in OpenSSL 3.0.

The int64math code is related, but something different. I introduced it for the 68060, to replace some of GCC's own code, because GCC uses instructions in its 64-bit math library code that are not available on the 68060, hence it triggered traps and emulation = immense slowdown. That is the only real reason we needed a separate version of AmiSSL for 68060, otherwise the 68020-60 version would have been fine. Likewise, I disabled https://github.com/jens-maus/amissl/blob/7a52623747a30be1626d258a3b466217a8bd25df/openssl/crypto/bn/asm/bn_m68k.s in the 68060 build for the same reason.

Ignoring AmiSSL and baserel, even this code will not link when compiling with -m68000 with GCC 2.95.3:

unsigned long long func(unsigned long long a, unsigned long long b)
{
  return a/b;
}

int main(int argc, char **argv)
{
  return 0;
}

[patrikaxelsson]

Well, what Oliver wanted to say (and all what you have to keep in mind) is: The GCC compiler suite for 68000 is not usable/capable to be used in the context of OpenSSL/AmiSSL. It misses fundamental features (baserel) which are essential for a shared library like AmiSSL and there are no newer or any further development going on in terms of getting modern compiler suites ported to OS3/68000. Thus, there are very limited chances to see any further improvements in that area. However, feel free to work on baserel support for GCC yourself and then you would increase the chances to see a pure 68000 version of AmiSSL.

From what I can see in the Makefile, for os3 the gcc argument -resident32 is used:

2.5 -resident32

This option is an improved version of ‘-resident’ (see -resident) — it does not impose any limits on data section size. Unfortunately, just like ‘-fbaserel32’ (see -fbaserel32), it is only available for 68020 or higher processors. Therefore, it is necessary to specify ‘-m68020’ or higher to use this option.

Note: This option was first made available in the ‘GCC’ 2.7.2.1, ‘Geek Gadgets’ snapshot ‘970109’. This option has no negative form.

Sounds like the "small data" model in SAS/C and VBCC, or rather that would be the -resident variant, as it has 64kB limits which this 020+ model does not have according to above docs.

[patrikaxelsson]

I think we use https://github.com/adtools/amigaos-gcc-2.95.3.

Do you build AmiSSL on the Amiga or in a cross-compile fashion?

Ignoring AmiSSL and baserel, even this code will not link when compiling with -m68000 with GCC 2.95.3:

unsigned long long func(unsigned long long a, unsigned long long b)
{
  return a/b;
}

int main(int argc, char **argv)
{
  return 0;
}

This is because of missing 64-bit signed division code for the 68000, right?

[Futaura]

Yes, -resident32 is used - it uses 32-bit address offsets ("small data" being 16-bit), which I think involves instructions not available on 68000. It took us a long time to get this all working correctly, so I'm not too keen to mess with it.

I can build the OS4 AmiSSL on my A1XE using the native environment, but it is much faster to cross-compile and build releases from Linux, especially as I have to cross-compile the OS3 version.

This is because of missing 64-bit signed division code for the 68000, right?

Yes, but that's only part of the problem, because of the baserel stuff above.

To sum things up, a 68000 version cannot happen anytime soon, I think. I'm more concerned with porting OpenSSL 3.0 right now, as we have hit a big problem regarding OS3. I'd be keen to hear your views at #60. I want to make sure I choose the best way forward.