BBC BASIC for Windows
General >> General Board >> BB4W v6 beta
http://bb4w.conforums.com/index.cgi?board=general&action=display&num=1395961811
BB4W v6 beta
Post by rtr on Mar 27th, 2014, 11:10pm

I have updated BB4W v6 to beta 7 (I have informed the testers by email so this is just by way of a 'backup' announcement).

Richard.

P.S. I would previously have posted this in the closed Developers' Area of this forum, but as an ordinary member I don't have access to that.
Re: BB4W v6 beta
Post by admin on Apr 13th, 2014, 10:24am

Typically BB4W v6 is only a little slower than v5 (it can even be faster), but occasionally the difference is more marked. One program, making particularly heavy use of floating-point calculations, gave these results:

BB4W v5.95a (*FLOAT 40): 0.94 seconds
BB4W v5.95a (*FLOAT 64): 1.78 seconds
BB4W version 6 beta 8: 1.88 seconds

So in this case v6 actually ran at only half the speed of v5 (albeit performing the calculations with twice the accuracy). If this is a concern you would be advised to keep a copy of v5.95a handy; I have shortcuts to both on my desktop.

Richard.
Re: BB4W v6 beta
Post by rtr on May 7th, 2014, 08:52am

Perhaps I could take this opportunity to remind you that BB4W version 6 (currently at Beta 8) is available for anybody to try - so long as you have the full version of v5.95a installed.

Beta 8 adds 'strikeout' to the available font styles:

Code:
      *font Arial,16,q
      VDU 5,30
      PRINT "Struck out text"

The strikeout (Q) and underscore (U) styles are mutually exclusive (the Q doesn't stand for anything, the character was determined by its bit pattern!).

If you don't currently have version 6, and you would like to, simply contact me privately and I will send you a download link.

Richard.
Re: BB4W v6 beta
Post by FrankK on May 8th, 2014, 8:11pm

Perhaps I could take this opportunity to remind you that BB4W version 6 (currently at Beta 8) is available for anybody to try - so long as you have the full version of v5.95a installed.

Beta 8 adds 'strikeout' to the available font styles:



Could you please send me the download link.
Frank Kemp
Re: BB4W v6 beta
Post by rtr on May 14th, 2014, 12:54pm

When I relinquished the admin role for this forum it slipped my mind that in so doing I would lose access to the closed 'Developers Area'; as a 'Junior Member' I have no way of reading the threads there. sad

I have received a request from somebody asking for information about BB4W version 6, specifically a list of new features. A search of this forum and the Yahoo group has failed to locate this information, so I am wondering whether it was originally posted to the Developers' Area.

Can I please ask somebody who can still access that part of the forum to have a quick look to see if there is a description of the BB4W v6 features. If so, it would be very helpful to copy them into this thread.

Richard.
Re: BB4W v6 beta
Post by Edja on May 14th, 2014, 1:48pm

Quote:
Can I please ask somebody who can still access that part of the forum to have a quick look to see if there is a description of the BB4W v6 features. If so, it would be very helpful to copy them into this thread.
Is this what you were looking for ?
Quote:
the features of BB4W version 6, so here is a list of the main ones:

New data types: 80-bit floats, 64-bit integers and huge (effectively unlimited length) strings.
Removed support for legacy 40-bit floats (except in files and via the indirection operator |).
Native support for huge files (exceeding 4 Gbytes length).
New *FLOAT 80 command.
New *HEX 32/64 command which controls hexadecimal conversion and shift operators.
Improved compatibility with 64-bit Windows.

Richard.
Eddy
Re: BB4W v6 beta
Post by rtr on May 14th, 2014, 2:55pm

on May 14th, 2014, 1:48pm, Edja wrote:
Is this what you were looking for ?

Yes, thank you very much!

To those features can be added the ones that appeared in subsequent beta releases:
Richard.
Re: BB4W v6 beta
Post by rtr on May 26th, 2014, 11:45am

I have updated BB4W v6 to Beta 9. It may be downloaded from the usual place and with the usual filename.

This release fixes a bug in the EOF# function, which did not work correctly with files greater than 4 Gbytes (whoops!).

It is somewhat disappointing that this bug was not detected by the testers; you might want to review your testing protocols, especially in respect of 'huge' files.

Richard.
Re: BB4W v6 beta
Post by rtr on Aug 15th, 2014, 5:30pm

I have updated BB4W v6 to Beta 10. It may be downloaded from the usual place and with the usual filename.

The only change in this release is that I have added the following instructions to the assembler:

Code:
      fcomi   stn
      fcomip  stn
      fucomi  stn
      fucomip stn

The status of these instructions was recently discussed in another thread. They were introduced in the P6 (e.g. Pentium Pro) architecture so are very likely to be available on any current CPU. One option would have been to support them via the ASMLIB library but it was actually more straightforward to add them to the native assembler.

Richard.
Re: BB4W v6 beta
Post by David Williams on Aug 15th, 2014, 6:06pm

on Aug 15th, 2014, 5:30pm, Richard Russell wrote:
The only change in this release is that I have added the following instructions to the assembler:

Code:
      fcomi   stn
      fcomip  stn
      fucomi  stn
      fucomip stn


:-)

David.
Re: BB4W v6 beta
Post by David Williams 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:
lea eax, [0+ebx*4]


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.
--
Re: BB4W v6 beta
Post by rtr on Aug 16th, 2014, 07:18am

on Aug 16th, 2014, 12:08am, David Williams wrote:
Further ideas

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.
Re: BB4W v6 beta
Post by rtr 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:
lea eax, [0+ebx*4]

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.
Re: BB4W v6 beta
Post by David Williams 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.
--