SHA256 for all Ataris

All 680x0 related coding posts in this section please.

Moderators: simonsunnyboy, Mug UK, Zorro 2, Moderator Team

mikro
Hardware Guru
Hardware Guru
Posts: 2200
Joined: Sat Sep 10, 2005 11:11 am
Location: Kosice, Slovakia
Contact:

Re: SHA256 for all Ataris

Post by mikro »

Eero Tamminen wrote:Doesn't GDB work with GCC compiled binaries for source level debugging, at least under MiNT? (At least old GDB / GCC versions did.)
As Thorsten said, unfortunately the new gcc versions (>= 4.x) suffer from a bug which makes gdb hardly usable. It has something to do with so called 'stabs' format which had been used for a.out targets but as soon as Linux (and others) switched to 'DWARF', nobody has been really maintaining 'stabs' support.
If one has (MiNT) network connection, one might be able to run gdbserver on Atari and GDB GUI, such as DDD on PC:
Yes, that's possible (with the older gcc+gdb combo).
Btw. older GCC versions supported also the old DRI symbol format, which should work with most Atari debuggers. Getting that requires "-Wl,--traditional-format" GCC linker flag.
That still works in newer versions, too.

Btw I have m68k-atari-mint-gcc-2.95 cross compiler in the works (meaning buildable/usable on 64-bit systems) so one could make debug builds with this gcc (as its gdb friendly) and then do the final build with the latest gcc.
User avatar
Eero Tamminen
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2158
Joined: Sun Jul 31, 2011 1:11 pm

Re: SHA256 for all Ataris

Post by Eero Tamminen »

mikro wrote:
Eero Tamminen wrote:Doesn't GDB work with GCC compiled binaries for source level debugging, at least under MiNT? (At least old GDB / GCC versions did.)
As Thorsten said, unfortunately the new gcc versions (>= 4.x) suffer from a bug which makes gdb hardly usable. It has something to do with so called 'stabs' format which had been used for a.out targets but as soon as Linux (and others) switched to 'DWARF', nobody has been really maintaining 'stabs' support.
...
Btw I have m68k-atari-mint-gcc-2.95 cross compiler in the works (meaning buildable/usable on 64-bit systems) so one could make debug builds with this gcc (as its gdb friendly) and then do the final build with the latest gcc.
Why not the latest GCC version which output still works with GDB? (Based on your comment, 3.x should still work, as it broke in 4.x)

ThorstenOtto wrote:
Eero Tamminen wrote: For assembly level debugging of GCC compiled code, one can use Hatari debugger.
Good luck in trying to do this with gcc compiled code. Some functions you try debug won't even exist because they are inlined.
I've debugged some crashes on Linux from GCC optimized/generated x86 assembly which I understand much less than m68k assembly.

However, that assembly output listed closest preceding symbol name + offset for things like jumps & braches. That made it much easier to read, as one could see where e.g. printf() was called etc.

Such a feature would be nice also for Hatari disassembly output, but currently its debugger relies completely on the CPU core (or separate disassembler) for generating the assembly, and that doesn't currently know anything about symbols loaded by the debugger.
ThorstenOtto
Atari God
Atari God
Posts: 1159
Joined: Sun Aug 03, 2014 5:54 pm

Re: SHA256 for all Ataris

Post by ThorstenOtto »

I've done a few more checks on this, with the following results:
  • The code in the archive i originally posted was a bit broken (so i have removed it, use the version below if you need it). The tests worked, but the file routines failed to do the final update. Simple reason was that i more or less copied your file reading loop, without realizing that your sha256_end did another call to SHA256Acc for the final update.
  • Your file routines seem to be broken, too. When done reading the file, the bytecount is appended to the stream. Your routine does not check whether that will fit in the buffer, and overwrites the end, and either crashes (because it smashed the stack of the caller), or just produces wrong results. You can test that by running it on a file of 1023 bytes length.
  • The (relative) poor performance of the C-Version compiled by PureC is mainly due to:
    • Although the RORu32 functions is inlined, it is still treated as a normal function call. That means that Pure-C cannot use d0-d2 around this call, and runs out of temporary registers. Replacing the inline function by the generic C Macro however makes things even worse.
    • GCC also uses some address registers for temporaries, but Pure-C doesn't
    So in the end, only 4 of the 8 accumulator variables in the inner loop are held in registers.
  • The C-Version only does the computation for 1 block (64 bytes), while your assembler version does it for up to 16. Dunno whether that really makes a big difference, since the version compiled by GCC isn't inlined, and still gives good results.
  • Using -O3 for gcc (for more agressive optimizations) does not give any noticable difference.
  • Using either gcc 4.6.4 or gcc 8.3 does not give any noticable difference, either.
The new archive now also has versions for SHA224 , SHA1 and SHA512 (just for fun)

Another interesting note: i always thought that MD5 is much simpler than SHA256, and should be much faster. It is, but the difference is smaller than expected (about a factor of 2 or so). Also interesting: on a real 64bit machine SHA512 is about twice as fast as SHA256.
You do not have the required permissions to view the files attached to this post.
JeanMars
Captain Atari
Captain Atari
Posts: 264
Joined: Fri Apr 09, 2010 5:15 pm
Location: France
Contact:

Re: SHA256 for all Ataris

Post by JeanMars »

Hi Thorsten,

I missed that response from you, sorry to relive this thread.
I was using SHA256 and I hit the bug you mentioned on my repository: https://github.com/JeanMars/SHA256
So I switched to your version, much more complete and elegant.
I used it for an app (compute SHA256 on files recursively from a folder), but it turns out that the results are not the same:
This app: SHA256("")=08c5a54e766e56a6f8430524d46fb0fee37b775701c44995daaf36640e33d265
Expected: e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855
As my dev env does not have stdint.h, I replaced #incude <stdint.h> with these lines (PureC here):
typedef unsigned char uint8_t ;
typedef unsigned long uint32_t ;
typedef unsigned long uintptr_t ;

Which seems fair to me; I don't think the error comes from here.
I attached my sources to this message, if you have the opportunity to have a look, I have probably made some stupid mistake but I didn't find it.

Cheers,
Jean
You do not have the required permissions to view the files attached to this post.
ThorstenOtto
Atari God
Atari God
Posts: 1159
Joined: Sun Aug 03, 2014 5:54 pm

Re: SHA256 for all Ataris

Post by ThorstenOtto »

JeanMars wrote:I have probably made some stupid mistake but I didn't find it.
Could be that some other definitions are missing (e.g __BYTE_ORDER__), and the code uses the wrong macros; hadn't have time to look into it. But attached should be a version that compiles also with original Pure-C headers.

You can invoke the programs also with --test and --bench to perform selftests and some simple benchmarks.
You do not have the required permissions to view the files attached to this post.
JeanMars
Captain Atari
Captain Atari
Posts: 264
Joined: Fri Apr 09, 2010 5:15 pm
Location: France
Contact:

Re: SHA256 for all Ataris

Post by JeanMars »

WIll have a look.

Thanks a million!
Post Reply

Return to “680x0”