Topics

Apple phasing out 32-bit support

Richard Russell
 

Apple have announced that Mac OS 'High Sierra' will be the last version of the Operating System to have 'full' 32-bit support. This will eventually affect BBC BASIC, which of course is a 32-bit program (for example it assumes that a pointer can be stored in an integer variable).

Although this isn't an immediate problem it would probably be wise to start thinking about the future of BBC BASIC in a predominantly 64-bit world. This is something that has been discussed before, but not for quite some time.

I would be interested in people's views on whether, and how, BBC BASIC could be adapted for 64-bit operation, and the consequences of the various options on performance, compatibility with existing programs etc.

Richard.

wilsr747
 

I don't use a Mac, but if I did I suppose the 64 bit program would (eventually) be required. How difficult is it to port it into 64 bit?

Rog W

Richard Russell
 

On Wed, Jun 7, 2017 at 03:51 am, wilsr747 wrote:
How difficult is it to port it into 64 bit?

I don't think the "difficulty" of implementation is the primary issue.  Rather, it's that BBC BASIC as it currently stands is inherently a 32-bit language.  So before worrying about how difficult it might be to make the changes we need to discuss how (if it's practical at all) the BBC BASIC language can be adapted to be 64-bit compatible, and when there is more than one option decide which is best for performance and/or compatibility with existing programs.  Inevitably, there are likely to be conflicting arguments.

It's worth bearing in mind that BBC BASIC was designed as a 32-bit language right back in 1981, when there were barely any 16-bit processors let alone 32-bit ones, and when 4 Gbytes of memory (the maximum that can be addressed with a 32-bit pointer) was greater than anybody could conceive of being available or necessary.  That was remarkably prescient, and the fact that the language architecture and syntax has remained compatible with advances in CPU and memory technology to the present day is astonishing.

Indeed there is no pressing need to move beyond 32-bits even now, the addressing capability is more than adequate for any plausible BASIC program.  All popular 64-bit CPUs (x86 and ARM) can run 32-bit code with no penalty and little OS overhead, and as far as I know Microsoft don't have any current plans to remove 32-bit support from Windows.  It's only because Apple, for company policy reasons rather than technical ones, want to force people to move to 64-bits that we need to have the discussion at all.

Richard.

Cecil Bayona
 

On 6/7/2017 6:20 AM, Richard Russell wrote:
On Wed, Jun 7, 2017 at 03:51 am, wilsr747 wrote:
How difficult is it to port it into 64 bit?
I don't think the "difficulty" of implementation is the primary issue. Rather, it's that BBC BASIC as it currently stands is inherently a 32-bit language. So before worrying about how difficult it might be to make the changes we need to discuss how (if it's practical at all) the BBC BASIC language can be adapted to be 64-bit compatible, and when there is more than one option decide which is best for performance and/or compatibility with existing programs. Inevitably, there are likely to be conflicting arguments.
It's worth bearing in mind that BBC BASIC was designed as a 32-bit language right back in 1981, when there were barely any 16-bit processors let alone 32-bit ones, and when 4 Gbytes of memory (the maximum that can be addressed with a 32-bit pointer) was greater than anybody could conceive of being available or necessary. That was remarkably prescient, and the fact that the language architecture and syntax has remained compatible with advances in CPU and memory technology to the present day is astonishing.
Indeed there is no pressing need to move beyond 32-bits even now, the addressing capability is more than adequate for any plausible BASIC program. All popular 64-bit CPUs (x86 and ARM) can run 32-bit code with no penalty and little OS overhead, and as far as I know Microsoft don't have any current plans to remove 32-bit support from Windows. It's only because Apple, for company policy reasons rather than technical ones, want to force people to move to 64-bits that we need to have the discussion at all.
Richard.
I'm a new user so as I'm getting started it make no difference to me if the applications is 64 bits or not, you can still use 32 bit integers no matter what and memory is plentiful with modern PCs so higher memory usage is not a big issue. Right now I mostly use Windows and Linux with 64 bit installs of the OS and Applications when possible just for future compatibility. I do have some older Macs but this change won't affect me as I have an older Mini that can't use the newer OSes anyway.

Like you mentioned there is no pressing need but it's a serious concern for Mac users who use BBC Basic like to keep up with the newer OSes.

One thought to minimize changes is to keep 32 bit math use if you are concerned with AM usage but I think there days memory is not an issue. Except for one PC which runs Windows 7 32 bits for compatibility with old software all my PCs have 16GB minimum of RAM with my larger PCs having 24GB of RAM. I have a lot of PCs.

--
Cecil - k5nwa
http://thepartsplace.k5nwa.com/

Richard Russell
 

On Wed, Jun 7, 2017 at 09:50 am, Cecil Bayona wrote:
I'm a new user so as I'm getting started it make no difference to me if the applications is 64 bits or not

It could!  To make BBC BASIC 64-bit compatible means changing the language so existing programs - including any programs you currently use or may write yourself - may not work, even though they don't need the increased addressing space.  For example any program using assembler code is for sure not going to run, and I think you said you were interested in BB4WForth which is nearly all assembly language!  Nobody should think that they won't be affected, so the more contributions to this discussion the better.

Of course we could abandon BBC BASIC on Mac OS-X - only a short time after having first achieved it - and put off any decisions until other OSes drop support for 32-bit code too.  But that's almost bound to happen: even now 64-bit Linux doesn't support 32-bit code unless you install 'multiarch' - and some people don't like doing so.   I wouldn't be surprised if Android goes the way of iOS and removes 32-bit support, and once all the other OSes have, even Windows might go the same way.

That's why we need to have the discussion and make some decisions now, even if they aren't immediately actioned.  And if it's going to need me to make some of the changes, we only have a very limited time before I'm incapable of doing so safely (possibly that's already the case). :-(

Richard.

Cecil Bayona
 

On 6/7/2017 12:49 PM, Richard Russell wrote:
On Wed, Jun 7, 2017 at 09:50 am, Cecil Bayona wrote:
I'm a new user so as I'm getting started it make no difference to me
if the applications is 64 bits or not
It could! To make BBC BASIC 64-bit compatible means *changing the language* so existing programs - including any programs you currently use or may write yourself - may not work, even though they don't need the increased addressing space. For example any program using assembler code is for sure not going to run, and I think you said you were interested in BB4WForth which is nearly all assembly language! Nobody should think that they won't be affected, so the more contributions to this discussion the better.
Of course we could abandon BBC BASIC on Mac OS-X - only a short time after having first achieved it - and put off any decisions until other OSes drop support for 32-bit code too. But that's almost bound to happen: even now 64-bit Linux doesn't support 32-bit code unless you install 'multiarch' - and some people don't like doing so. I wouldn't be surprised if Android goes the way of iOS and removes 32-bit support, and once all the other OSes have, even Windows might go the same way.
That's why we need to have the discussion and make some decisions now, even if they aren't immediately actioned. And if it's going to need me to make some of the changes, we only have a very limited time before I'm incapable of doing so safely (possibly that's already the case). :-(
Richard.
Yes it will affect many it's just in my case since I have not written any software it's neither here or there for me. I do intend to use BB4WForth and it's mostly assembler so I will have to byte the bullet when that day arrives and learn 64 bit assembler for Intel CPUs. Fortunately the assembler code in BB4WForth is written in little snippets which are nice and small so it should not be a major conversion one little piece at a time.

I would recommend that you keep the 32 bit version available even if it is rarely maintained for persons wanting to change old software applications without a re-write in that way the impact is minimized on the users.

I know from now on I will keep every version that comes out on my NAS drives so I'm covered, right now I have the version 5.44 LTS installed and don't intend to change software on the PC with every release, only LTS versions except for the SDL versions for other OSes since they are a work in progress.

Thanks for the conversation.

--
Cecil - k5nwa
http://thepartsplace.k5nwa.com/

Richard Russell
 

On Wed, Jun 7, 2017 at 11:25 am, Cecil Bayona wrote:
right now I have the version 5.44 LTS installed

Not recognising this reference, I did a Google search which revealed that it is a release of PureBasic!  This is a support group for the BBC BASIC language (specifically 'BBC BASIC for Windows' and 'BBC BASIC for SDL 2.0').  It has no connection with PureBasic, other than the tenuous one that some people have migrated from BBC BASIC to PureBasic because it is seen as superior (it is for example a compiled, rather than interpreted, language).

Richard.

Cecil Bayona
 

On 6/7/2017 4:28 PM, Richard Russell wrote:
On Wed, Jun 7, 2017 at 11:25 am, Cecil Bayona wrote:
right now I have the version 5.44 LTS installed
Not recognising this reference, I did a Google search which revealed that it is a release of PureBasic! This is a support group for the BBC BASIC language (specifically 'BBC BASIC for Windows' and 'BBC BASIC for SDL 2.0'). It has no connection with PureBasic, other than the tenuous one that some people have migrated from BBC BASIC to PureBasic because it is seen as superior (it is for example a compiled, rather than interpreted, language).
Richard.
Sorry, cracking up here, been a busy day so far and yes that is for PureBasic. Both Basics have Windows, Linux, and MacOs versions and both have extensive libraries to get things done so both are usable for quickie tools which is my main area of interest.

Other languages that I like to use is Forth and Delphi Pascal with C when I have little choice.

--
Cecil - k5nwa
http://thepartsplace.k5nwa.com/

Richard Russell
 

On Wed, Jun 7, 2017 at 03:29 am, Richard Russell wrote:
I would be interested in people's views on whether, and how, BBC BASIC could be adapted for 64-bit operation, and the consequences of the various options on performance, compatibility with existing programs etc.

Won't somebody set the ball rolling?  Let us know what you think a 64-bit BBC BASIC should look like, and how the inevitable incompatibilities should be addressed.

Richard.

bb4w@...
 

On 10 Jun, Richard Russell <news@...> wrote:
On Wed, Jun 7, 2017 at 03:29 am, Richard Russell wrote:

I would be interested in people's views on whether, and how, BBC BASIC
could be adapted for 64-bit operation, and the consequences of the
various options on performance, compatibility with existing programs
etc.
Won't somebody set the ball rolling? Let us know what you think a
64-bit BBC BASIC should look like, and how the inevitable
incompatibilities should be addressed.
Richard.
Hello Richard

With your knowledge of its inner workings, can you outline what the
physical problems are for you converting BB4W to 64bit. Also is there any
other improvements this a good opportunity to add?

Regards
Ian K

john_fowler_son@...
 

I think there are a couple of ways of looking at this.  Firstly, this seems like a bit of a straw in the wind from Apple.  "Next will be the last..." seems like a very long way in the future before 32b support disappears and as that day approaches there might well be many other software providers getting queazy.  (I use Windows, but looking at "Services" in Task Manager, I see a lot of exe*32s running!).  As for Microsoft, their record of backward compatibility is much better and long may that continue.

But to the second viewpoint, how do you feel Richard? This is your baby - if you WANT to do this, you will do it, and you will do it superbly.  If you have to do it, you will do it, and do it very well. If you do not want to do it, I for one am not going to beat you up.

I am in no way qualified to suggest how it might be done and I can only guess at the ramifications.  I had a quick scan through a list of my programmes and - since they all run under Windows - they all contain assembler (even if only in the form of the INSTALLed WINLIBs) and the implication that they might "suddenly" become obsolete does not appeal.  On the other hand, if you were to say such programmes would run without alteration - leaving only assembler I have written to be checked, then I am relaxed - there is relatively little of that and it is simple enough code: not be true for others of course.  But there must be many implications which I am blind to - for example, what about all the *SYS calls - how many of those are invalid when running not running in *32 mode?

And are there upsides beyond "future proofing"?

Ideally, therefore, any new 64b version would have a *32 mode, which would run "32b BB4W code" and (therefore) "compile" an exe*32.  But as for a "64b only" version - implying "all" programmes would need looking at for compatiblity - well now I am nervous.

I suspect only you know exactly what the options are and what workload each would imply for yourself.  But just the prospect of re-writing all the libraries etc must be a daunting task - let alone the interpreter itself.

So how do YOU feel ?

Best wishes,

Howard

Richard Russell
 

On Sun, Jun 11, 2017 at 12:30 am, <bb4w@...> wrote:
can you outline what the
physical problems are for you converting BB4W to 64bit.

As I've said, I'm not at this stage concerned about the practical implications but only about the 'conceptual' changes to the language that would be necessary.  In any case it's highly unlikely that the implementation would be done by me: my faculties are deteriorating too fast for that.  The assembler code (as currently used for BB4W and the x86 editions of BBCSDL) cannot realistically be adapted for 64-bits - I tried some years ago and gave up - so we are probably talking about somebody other than me adapting the C code used currently for the ARM editions of BBCSDL.

Richard.

john_fowler_son@...
 

.... in which case my comments above are irrelevant.

Best wishes,

Howard

Richard Russell
 

On Sun, Jun 11, 2017 at 03:37 am, <john_fowler_son@...> wrote:
this seems like a bit of a straw in the wind from Apple.  "Next will be the last..." seems like a very long way in the future before 32b support disappears

If we look at the history of Mac OS, new versions have been released on an annual basis since 2011 so if High Sierra (to be released in 2017) is the last to support 32-bit apps that means the first not to have such support is likely to be released sometime in 2018.  That is only next year so I don't see how you conclude that it will be "a very long way in the future".

> This is your baby - if you WANT to do this, you will do it, and you will do it superbly

No, it isn't and I won't.  As you know, the rush (almost panic) to get BBCSDL written and released was because I am only too aware of my 'waning powers' and that it will be only a short time before I am incapable of writing anything other than 'trivial' code (if that stage hasn't been reached already).  My preference would be to release the C source code of the ARM editions of BBCSDL (which can be compiled for x86, of course) and leave it to the 'next generation' to make the actual changes necessary for 64-bit operation.

> I had a quick scan through a list of my programmes and - since they all run under Windows -
> they all contain assembler (even if only in the form of the INSTALLed WINLIBs)

Your parenthesised comment is the critical one: if the only use of assembler code is in libraries then any incompatibility can be resolved by making different libraries available for the different platforms.  After all that's exactly where we are now: most (32-bit) BBC BASIC programs that I write today are designed to run in BB4W, BBCSDL (x86) and BBCSDL (ARM) so that they are compatible with all the supported platforms.  That means no assembler (unless one goes to the trouble of including both x86 and ARM code); for example both 'SDLIDE.bbc' and 'touchide.bbc' are 100% BASIC code.

>  for example, what about all the SYS calls - how many of those are invalid when running not running in *32 mode?

SYS is indeed a major source of incompatibility, but again we don't need to contemplate a 64-bit version to face that challenge because we have it with BBCSDL already!  If you are currently writing BBC BASIC programs with thought being given to them running on Linux, Mac OS-X, Android and the Raspberry Pi (and I hope you are) then you need to worry about SYS calls now.

> Ideally, therefore, any new 64b version would have a *32 mode, which would run
> "32b BB4W code" and (therefore) "compile" an exe*32.

That's a quite separate issue concerning the IDE, not the language, surely?  It would no doubt be possible to create an IDE which would allow you to build either 32-bit or 64-bit programs, but the 'language' and therefore the BASIC 'source code' (in many cases) would need to be different according to which you are building.

> So how do YOU feel ?

More than anything else it is vital that the future of BBC BASIC be decoupled from me!  BBCSDL has already been a major departure from the precedent of BB4W, being a collaborative project in which I have been, and remain, dependent on the contributions of others (for example the BBCEdit IDE supplied by Andy Parkes).  Without that contribution BBCSDL will fail, and it is already looking as though that might happen because my repeated requests for help with documentation, libraries, tools etc. seem to have fallen on deaf ears.  For a 64-bit version of BBC BASIC I would expect to have only a consultative role.

For the present, everybody seems to be concentrating on the practical implications of modifying the interpreter, rewriting libraries, creating new IDEs etc. but I think that is premature.  Before any of those are contemplated we need to know how the language itself needs to be changed, but nobody has addressed that issue at all so far.

So, please, think about the BBC BASIC language rather than any particular implementation.  The language has been tied to 32-bits since its inception in 1980 or thereabouts, and fundamental changes will be necessary if it is to work in a 64-bit environment.  For example what about 'integer' variables: those that have a percent suffix (e.g. A%, myinteger%); should they remain 32-bits or should they change to be 64-bits?  There are pros and cons to both options, so what I want to learn is what people feel and whether there is a consensus.  The same applies to other aspects of the language which would have to change (e.g. DIM, indirection, CALL, SYS, USR, the assembler etc. etc.).  How can the inevitable incompatibilities best be managed?

Or do we simply recognise that BBC BASIC is a 32-bit language and has no future in a 64-bit world?

Richard.

John Alfred
 
Edited

How about telling Apple about the effects on BBC-BASIC, and what it means in terms of support?
And can they make it backwards compatible?
 
John Alfred
 

Richard Russell
 

On Sun, Jun 11, 2017 at 06:48 am, John Alfred wrote:
How about telling Apple about the effects on BBC-BASIC

Very funny.  I suppose it helps to maintain a sense of humour!

Richard.

P.S. Did you realise that you copied the entirety of my last (long) message into your reply?  I've edited it, but not soon enough to spare the inboxes of everybody else!  Please be considerate and trim replies.

John Alfred
 

Sorry Richard, but that message was intended for the usual readers to see.

No I was serious in my suggestion. It wasn't a joke!

If supporters of Apple products are not willing to tell Apple how Apple decisions affect them, then how can Apple know the downside of their decisions?

If you are shy about telling Apple, then I can do it. Just give me an email address and I'll do the rest.

Best regards
John Alfred, m. eng, mba



Sent from my iPhone

On 11 Jun 2017, at 15:41, "Richard Russell" <news@...> wrote:

On Sun, Jun 11, 2017 at 06:48 am, John Alfred wrote:
How about telling Apple about the effects on BBC-BASIC

Very funny.  I suppose it helps to maintain a sense of humour!

Richard.

P.S. Did you realise that you copied the entirety of my last (long) message into your reply?  I've edited it, but not soon enough to spare the inboxes of everybody else!  Please be considerate and trim replies.

Richard Weir
 

Hi Richard,

I am composing a reply, but life (birthdays, elderly parents etc) keeps interrupting my chain of thought.

In short, and without al the careful considerations I am trying to asseble:

  • Start with a pure 64bit BBCBasic, something that will allow backward compatibility only for the simplest BASIC programs. All variables would be 64bit (or more) as appropriate. It's possibly the easiest option, and you may get some idea of its usefulness from the number of copies downloaded.
  • Maybe, then try to create a simple compatibility-box, something that creates a virtual 32bit memory map. The changes from 32bit BBCBasic needed (that I can think of, there are sure to be others) are that DIM <var> <size> statements should return an offset into the memory map, not an absolute address, and that $, ? and ! indirection operators should add the offset to get the absolute, 64bit address.

    One major limitation of this version is that it won't allow OS calls: that would be infinitely more complex, because 32bit and 64bit OS calls require different parameters
    and parameter lengths; anybody trying to use OS calls from a 32bit BASIC really needs to rewrite for 64bit.
Obviously I have yet to consider what changes to BASIC resources would be needed

Richard Russell
 

On Sun, Jun 11, 2017 at 08:48 am, John Alfred wrote:
No I was serious in my suggestion. It wasn't a joke!

As I said in an earlier message, Apple are forcing programmers to move to 64-bit code not (primarily) for technical reasons but as company policy.  They have no interest in the degree of inconvenience that it will cause.  The reason I assumed your comment was a joke was the implication that Apple might care about a program that they have never heard of, written by a private individual, and of which there is not a single user on their platform (so far as I'm aware); of course they don't.  Apple rarely take notice even of international corporations or governments!

Richard.

Richard Weir
 

Hello Richard,

I have been composing a reply, but life keeps distracting me and I am having difficulty getting my thoughts together. The following has not been properly considered, and may be seriously in error in one or more places.

Still, to get the ball rolling:

I suggest that to start with, you could create a pure 64bit BBC4W, one that only provides compatibility to the simplest 32bit BBCB4W programs. It's the easiest option!

Then, maybe, you could create (or add to the 64bit version) a "compatibility box" mode, wherein a virtual 32bit memory-map is presented. All variables would be created within that memory map. DIM <var> <size> would return offsets into that memory map, not absolute addresses. Indirection operators would need to add the relevant offset to create the absolute address needed before accessing memory. There would be one severe limitation: OS calls would not be supported. But then, if a user really needs OS calls then they would be better off rewriting their 32bit program for 64bit.

(I am not sure about the compatibility box idea. There are - at the very least - other issues regarding indirection into variable header records that need to be considered. However I never used them much and am less familiar with them, and prefer not to address them from a position of ignorance.)


I was wondering if it would be possible and relatively simple to create a new variable type "pointer" that could be bit-length agnostic, ie it is as long as is required for the "current" address size available when BBCB4W is updated. It would future-proof the language, and only require relatively minor (? am I right?) changes if, say, a 256bit processor range comes out.

Anybody else have any thoughts?

All the best Richard, and thanks for maintaining this invaluable resource!

Richard Weir.

Previous Topic Next Topic