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

Welcome Guest. Please Login or Register.
Jan 23rd, 2018, 4:50pm


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 236 times)
Richard Russell
Administrator
ImageImageImageImageImage


member is offline

Avatar




Homepage PM


Posts: 692
xx 32-bit versus 64-bit timing comparison
« Thread started on: Dec 10th, 2017, 11:31pm »

I present these figures without analysis. I don't suggest that any 'conclusions' can be drawn from them, as such - the interpreters are after all totally different. But if we are going to be forced kicking-and-screaming into a 64-bit world (which really makes no sense for a 32-bit language like BBC BASIC) they are obviously of some interest.

Richard.

User ImageUser Image
User IP Logged

michael
Full Member
ImageImageImage


member is offline

Avatar




PM


Posts: 141
xx Re: 32-bit versus 64-bit timing comparison
« Reply #1 on: Dec 11th, 2017, 03:38am »

I tried the Win64 version you linked and It just stays in immediate mode.

I am sure many people would love a true Win64 conversion of BBC4W, but at the moment, there doesn't seem to be any issues with 32bit (yet)

Never say never I guess. Is there talk of Microsoft going 64bit and dropping 32bit compatibility?

Currently 64bit is in my computer and 32bit works fine as the default. I do run a couple games with 64bit.

Doesn't hurt to play with possibilities.

You have a link to a current Win64 you have?
I would like to toy around with it..
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: 692
xx Re: 32-bit versus 64-bit timing comparison
« Reply #2 on: Dec 11th, 2017, 08:51am »

on Dec 11th, 2017, 03:38am, michael wrote:
I tried the Win64 version you linked and It just stays in immediate mode.

It doesn't stay in immediate mode, it starts in immediate mode - exactly as does BBCSDL if you run it without an IDE! Indeed 'bbcsdl.exe' and 'bb64.exe' are substantially identical, functionally, apart from the significant 32-bit vs 64-bit issues (and the absence of an assembler).

Immediate mode was all you got on the BBC Micro and it's perfectly adequate for running programs so, to the extent that the reason for releasing an experimental 64-bit version is to allow testing, that should be sufficient. If you need to edit a program it's safer to do that in BB4W or BBCSDL.

However at the discussion group I explained that both IDEs will run in 64-bit mode, although SDLIDE is flaky and prone to crashing (I know one of the reasons). So if you really want to try that you can, but don't expect it to be stable.

Quote:
I am sure many people would love a true Win64 conversion of BBC4W

Not if they've been following the threads on the subject they won't, because of all the compatibility problems! That's the whole reason for me wanting to encourage discussion, because it raises issues that we haven't had to face since the 16-bit (MS-DOS) to 32-bit (Windows) transition 16 years ago!

Richard.
« Last Edit: Dec 11th, 2017, 12:48pm by Richard Russell » User IP Logged

Richard Russell
Administrator
ImageImageImageImageImage


member is offline

Avatar




Homepage PM


Posts: 692
xx Re: 32-bit versus 64-bit timing comparison
« Reply #3 on: Dec 12th, 2017, 9:38pm »

on Dec 11th, 2017, 08:51am, Richard Russell wrote:
That's the whole reason for me wanting to encourage discussion...

So can we get some discussion going? Is a 64-bit version a worthwhile development or are the compatibility issues just too great? If it's not worth proceeding with, should BBCSDL continue to exist solely for the Android port (assuming Android continues to support 32-bit apps) or should it be abandoned?

If a 64-bit BBC BASIC is developed should it replace the 32-bit BBCSDL editions altogether, or be supported alongside them? Given that significant incompatibilities are unavoidable, how do we tackle them given that it's more than 16 years since a similar situation last arose?

All versions of BBC BASIC (with the notable exception of Brandy) have incorporated an assembler for the host processor, but we don't have a suitable x86_64 assembler. What can and should be done about that?

That's just a few questions that immediately come to mind; I am sure there are many more. So who wants to set the ball rolling, if not with answers at least in moving the discussion forward?

Richard.
User IP Logged

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: 692
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: 692
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: 692
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: 692
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