Author |
Topic: BB4W v6 beta (Read 3032 times) |
|
David Williams
Developer
member is offline
meh
Gender: 
Posts: 452
|
 |
Re: BB4W v6 beta
« Reply #10 on: Aug 16th, 2014, 12:08am » |
|
on Aug 15th, 2014, 8:48pm, Richard Russell wrote:| But as the extra instructions are implemented only in v6 they will remain unavailable to 'conservative' users who insist on sticking with v5 indefinitely... ;D |
|
;D
Further ideas (there may be sound 'technical' reasons for not adopting them, but here goes...):
- Could it be made optional (perhaps by setting a bit in some BB4W variable) for the assembler to automatically insert near instructions when required so as to avoid the "Jump out of range" error and having to insert perhaps dozens of nears manually (especially when compiler-generated code is involved)?
- I can appreciate why having the floating point registers recognised natively as st(0), st(1), st(2) is a no-no (even though it would be nice in view of GCC-generated code), but how about having the assembler accept st as synonymous with st0? It's easily 'fixed' using the Search & Replace, but it can still take time.
- Not your fault, but just saying, from the point of view of assembling GCC-generated assembler code, I do wish GCC wouldn't output this sort of thing:
Code:
It trips up the BB4W assembler, and the 0+ part looks a bit pointless.
Apart from the near issue, st(n) and st obstacles, and lea [0+<reg>*<multiplier>], I now find it remarkably simple to incorporate GCC-generated code into my BB4W programs, and the time I'm saving in doing so makes me somewhat regret the many, many long hours I spent struggling with assembler coding and the inevitable bug-hunting that ensued.
(Play the world's saddest tune on the world's smallest violin...) :'(
David.
--
|
|
 Logged
|
|
|
|
rtr
Guest
|
|
Re: BB4W v6 beta
« Reply #11 on: Aug 16th, 2014, 07:18am » |
|
on Aug 16th, 2014, 12:08am, David Williams wrote:
I'm not looking for "ideas" for BB4W v6. After all, it's at Beta 10 so really only bugs qualify for consideration.
I felt that the omission of those instructions, whilst strictly justified because other P6-only instructions are also missing (e.g. CMOV, FCMOV), was sufficiently important to be an exception - but only because no code changes were required, only trivial additions to data tables. Therefore there was effectively zero risk in the modification; nothing could break.
Changes of the kind you suggest are out of the question I'm afraid.
Quote:| Could it be made optional (perhaps by setting a bit in some BB4W variable) for the assembler to automatically insert near instructions when required so as to avoid the "Jump out of range" error |
|
It's not possible in a two-pass assembler (at least, not for forward jumps). To do that requires a multi-pass approach; even the (oldish) version of NASM I use doesn't do it.
Richard.
|
|
Logged
|
|
|
|
rtr
Guest
|
|
Re: BB4W v6 beta
« Reply #12 on: Aug 16th, 2014, 09:48am » |
|
on Aug 16th, 2014, 12:08am, David Williams wrote:| how about having the assembler accept st as synonymous with st0? It's easily 'fixed' using the Search & Replace, but it can still take time. |
|
You could create a library, working on the same principle as the ASMLIB* libraries, which accepts st (and potentially also st(0)). The only snag with that approach is that you can't straightforwardly crunch the program - you need to offload the assembler code into a separate file, with an extension other than .BBC, that you CALL at run time.
Quote:I do wish GCC wouldn't output this sort of thing:
Code: |
|
BB4W's assembler accepts all these variants, but not the one you want:
Code: lea eax, [ebx*4+table]
lea eax, table[ebx*4]
lea eax, [ebx*4]table
Quote:| I now find it remarkably simple to incorporate GCC-generated code into my BB4W programs |
|
Have you disabled GCC's generation of SSE2 code for 64-bit floating-point calculations? I would have expected that to be the default when targeting a modern processor.
Richard.
|
|
Logged
|
|
|
|
David Williams
Developer
member is offline
meh
Gender:
Posts: 452
|
|
Re: BB4W v6 beta
« Reply #13 on: Aug 16th, 2014, 10:53am » |
|
on Aug 16th, 2014, 09:48am, Richard Russell wrote:| You could create a library, working on the same principle as the ASMLIB* libraries, which accepts st (and potentially also st(0)). The only snag with that approach is that you can't straightforwardly crunch the program - you need to offload the assembler code into a separate file, with an extension other than .BBC, that you CALL at run time. |
|
Thanks, I'll look into it.
Quote:| Have you disabled GCC's generation of SSE2 code for 64-bit floating-point calculations? I would have expected that to be the default when targeting a modern processor. |
|
My usual command line compilation instruction:
Code:gcc -c -O2 -march=native -o glib2.o glib2.c
Followed by (for compiling the DLL):
Code:gcc -o glib2.dll -s -shared glib2.o -Wl,--subsystem,windows
With regards C and compilation, I'm extremely 'green' having been at this for all of 2 weeks, so far.
Can't say I've noticed any SSE2 instructions in the GCC-generated assembler code, but then I haven't done that much on that side of things.
Shall I say it before you do? "This is off-topic for this thread".
Thought I'd beat you to it. :)
David.
--
|
|
Logged
|
|
|
|
|
