BBC BASIC
« 32-bit versus 64-bit timing comparison »

Welcome Guest. Please Login or Register.
Jan 22nd, 2018, 5:09pm


Cross-platform BBC BASIC (Win32, Linux x86, Android, Mac OS-X, Raspberry Pi)

« Previous Topic | Next Topic »
Pages: 1  Notify Send Topic Print
 thread  Author  Topic: 32-bit versus 64-bit timing comparison  (Read 225 times)
DDRM
Global Moderator
ImageImageImageImageImage


member is offline

Avatar




PM


Posts: 30
xx Re: 32-bit versus 64-bit timing comparison
« Reply #4 on: Dec 13th, 2017, 1:10pm »

Hi Richard,

My tuppence-worth (if it's worth that much! grin )

I think a 64 bit version would be worth having, particularly if some platforms will no longer be able to run the 32 bit version.

As discussed here and on the groups.io platform, there is probably no way of avoiding substantial incompatibilities with the 32 bit version, so my view would be that this is one of those crunch-points where you simply have to bite the bullet and accept a substantial degree of incompatibility. Once you make that decision, it may free you to go for solutions that involved a bit more incompatibility, but result in a better "end product". I'd go there.

I know you see inclusion of an assembler as a key USP of BBC Basics, but I don't think it should be a deal-breaker: a working BBC Basic without it is much better than no working version at all!

Would you also make a 64 bit version of BB4W?

Hope that's useful.

Best wishes,

D
User IP Logged

Richard Russell
Administrator
ImageImageImageImageImage


member is offline

Avatar




Homepage PM


Posts: 691
xx Re: 32-bit versus 64-bit timing comparison
« Reply #5 on: Dec 13th, 2017, 3:11pm »

on Dec 13th, 2017, 1:10pm, DDRM wrote:
my view would be that this is one of those crunch-points where you simply have to bite the bullet and accept a substantial degree of incompatibility.

Is there a 'market' for that, though? You explained that your own lack of interest in BBCSDL largely stems from its incompatibility with BB4W, yet a 64-bit version would be less compatible still! Would you use it?

Quote:
I know you see inclusion of an assembler as a key USP of BBC Basics, but I don't think it should be a deal-breaker: a working BBC Basic without it is much better than no working version at all!

I can't agree with that. Have you considered how many libraries depend on there being an assembler: SORTLIB, SOCKLIB, TIMERLIB (and many more in the case of BB4W)? Then there are the debugging features: there would be no Trace or Single Step, no List Variables and no Profiler without an assembler.

And there's a more fundamental point. BBC BASIC, being a traditional interpreter, is an extremely slow language (and, as the figures at the start of this thread show, a 64-bit version is slower still). The only mitigating factor is the assembler, which allows you to speed up time-critical parts of a program enormously. All my major applications (FIRBBC, Colour Recovery, Free-d etc.) crucially rely on assembler code.

Quote:
Would you also make a 64 bit version of BB4W?

I would have no means of doing so. All of the code which interfaces the interpreter with Windows (filing system, OS commands, VDU emulation, MODE 7 emulation, SOUND and ENVELOPE etc.) is written in assembly language and is therefore not 64-bit compatible.

Richard.
User IP Logged

Richard Russell
Administrator
ImageImageImageImageImage


member is offline

Avatar




Homepage PM


Posts: 691
xx Re: 32-bit versus 64-bit timing comparison
« Reply #6 on: Dec 13th, 2017, 11:03pm »

This may help put things in perspective. I've just been adapting the FNmessagebox function in SDLIDE.bbc to be compatible with bb64.exe. I didn't find it easy, not least because if there was anything wrong it just crashed spectacularly: no error messages or anything like that to give me a clue.

Here's what I ended up with. You can judge for yourself whether this degree of modification is something you, or other users, would be prepared to cope with in the interests of compatibility with a 64-bit BBC BASIC.

Code:
      DEF FNmessagebox(title$, message$, flags%)
      LOCAL R%, mbd{}, bd{()}, button$(), id%()
      IF BB4W% THEN
        SYS "MessageBox", @hwnd%, message$, title$, flags% TO R%
      ELSE
        DIM button$(2), id%(2)
        title$ += CHR$0 : message$ += CHR$0
        button$() = "Cancel"+CHR$0, "No"+CHR$0, "Yes"+CHR$0
        id%() = IDCANCEL, IDNO, IDYES
        IF @platform% AND &40 THEN
          DIM mbd{flags%, pad1%, window%%, title%%, message%%, numbuttons%, pad2%, buttons%%, colorScheme%%}
          DIM bd{(2) flags%, buttonid%, text%%}
          mbd.window%% = @hwnd%
          mbd.title%% = !^title$
          mbd.message%% = !^message$
          FOR R% = 0 TO 2
            bd{(R%)}.text%% = !^button$(R%)
            bd{(R%)}.buttonid% = id%(R%)
          NEXT
          mbd.flags% = flags% AND NOT &F
          CASE flags% AND &F OF
            WHEN MB_YESNOCANCEL:
              mbd.numbuttons% = 3
              mbd.buttons%% = bd{(0)}
            WHEN MB_YESNO:
              mbd.numbuttons% = 2
              mbd.buttons%% = bd{(1)}
          ENDCASE
        ELSE
          DIM mbd{flags%, window%, title%, message%, numbuttons%, buttons%, colorScheme%}
          DIM bd{(2) flags%, buttonid%, text%}
          mbd.window% = @hwnd%
          mbd.title% = !^title$
          mbd.message% = !^message$
          FOR R% = 0 TO 2
            bd{(R%)}.text% = !^button$(R%)
            bd{(R%)}.buttonid% = id%(R%)
          NEXT
          mbd.flags% = flags% AND NOT &F
          CASE flags% AND &F OF
            WHEN MB_YESNOCANCEL:
              mbd.numbuttons% = 3
              mbd.buttons% = bd{(0)}
            WHEN MB_YESNO:
              mbd.numbuttons% = 2
              mbd.buttons% = bd{(1)}
          ENDCASE
        ENDIF
        SYS "SDL_ShowMessageBox", mbd{}, ^R%
      ENDIF
      = R% 

Richard.
User IP Logged

michael
Full Member
ImageImageImage


member is offline

Avatar




PM


Posts: 141
xx Re: 32-bit versus 64-bit timing comparison
« Reply #7 on: Dec 14th, 2017, 04:46am »

It would be an asset to have a 64bit version in the works. Even if it is promoted as an experimental version. Never hurts to tinker with an idea.

Compatibility would be not so important, if a person could harness the core aspects were there. (graphics, and basic controls)

A person could build thier own graphics controls from the ground up.

Id say start with a small working package. It can be its own thing too. Its not too hard to learn the differnces.
User IP Logged

I like reinventing the wheel, but for now I will work on tools for D3D
Richard Russell
Administrator
ImageImageImageImageImage


member is offline

Avatar




Homepage PM


Posts: 691
xx Re: 32-bit versus 64-bit timing comparison
« Reply #8 on: Dec 14th, 2017, 7:09pm »

on Dec 14th, 2017, 04:46am, michael wrote:
It would be an asset to have a 64bit version in the works. Even if it is promoted as an experimental version. Never hurts to tinker with an idea.

I've updated bb64.zip which, as discussed, flags that it is a 64-bit edition by setting bit 6 of @platform% (so the least significant byte is now &40).

However please be aware that this change has significantly worsened compatibility, and SDLIDE.bbc will no longer run correctly without modification. I have a patched version here; if anybody wants it uploaded let me know.

Richard.
« Last Edit: Dec 14th, 2017, 10:30pm by Richard Russell » User IP Logged

Richard Russell
Administrator
ImageImageImageImageImage


member is offline

Avatar




Homepage PM


Posts: 691
xx Re: 32-bit versus 64-bit timing comparison
« Reply #9 on: Dec 17th, 2017, 9:41pm »

For those who have downloaded, or expect to download, the 'experimental' 64-bit version of BBC BASIC, these are the main issues you need to be aware of when testing:
  • Although described as a '64-bit version', BBC BASIC is a 32-bit language and pointers (particularly pointers to the heap and stack) remain 32-bits. This means (in this release at least) that the heap and stack must reside in the bottom 4 Gbytes of the address space.

  • The SYS statement has not been modified to be 64-bit compatible, and can currently pass only 32-bit integer parameters to the called function. Passing floating-point values will be a particularly tricky issue to resolve because of the x86-64 ABI, and currently no fully satisfactory solution is known.

  • API calls (e.g. of SDL 2.0 functions) which take a structure as a parameter are very likely to require the layout of the structure to be modified. Typically this will involve changing 32-bit members to 64-bits, and inserting padding members to ensure that any 64-bit members are QWORD aligned.

  • Bit 6 of the @platform% system variable is set by this version, to indicate that it is 64-bits. This may be tested when it is necessary to make code conditional on the 'bitness', for example in order to declare a modified structure layout as above. However please note that this change may itself result in an incompatibility with existing programs.

  • Some 'system variables', notably @hwnd%, @memhdc% and @hfile%() are still 32-bits, even though the values they contain may not be. This has not proved to be an issue in Windows, to date, but almost certainly will be if and when the 64-bit version is ported to other platforms. Solutions to this are bound to introduce more incompatibilities.

  • There is no assembler (or, to be precise, the assembler is for ARM which is no use at all!). This is not going to be acceptable in the long term, but at present there is no known solution for how an assembler will eventually be implemented.

  • The CALL statement and the USR function, which are used to call 'machine code' routines, may not work as expected and certainly will not pass the static integer variables (A%, B% etc.) in a way compatible with their 32-bit cousins. In the absence of an assembler it is unlikely that you will be wanting to use these keywords, but not impossible.

  • Some Interpreter Internal Variables are not at the addresses documented at the Wiki, because they have been moved to accommodate 64-bit values.

  • Several of the current libraries are not 64-bit compatible, these include arraylib, asmlib*, sortlib, socklib, ogllib/gleslib and timerlib.
There are probably other factors that don't immediately come to mind. If you notice any unexpected behaviour that cannot be explained by these differences, please let me know. Happy testing!

Richard.
« Last Edit: Dec 18th, 2017, 11:56am by Richard Russell » User IP Logged

Pages: 1  Notify Send Topic Print
« Previous Topic | Next Topic »

Donate $6.99 for 50,000 Ad-Free Pageviews!


This forum powered for FREE by Conforums ©
Sign up for your own Free Message Board today!
Terms of Service | Privacy Policy | Conforums Support | Parental Controls