BBC BASIC
« O% under w32/w64 »

Welcome Guest. Please Login or Register.
Oct 24th, 2017, 11:04am


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: O% under w32/w64  (Read 126 times)
pez
New Member
Image


member is offline

Avatar




Homepage PM


Posts: 4
xx O% under w32/w64
« Thread started on: Sep 24th, 2017, 7:25pm »

Hello.

Despite the fact that:

"BBC BASIC is not an ideal platform on which to write 'pure' assembler code, that is code which does everything in assembler and runs continuously without returning to BASIC", "Re: Interrupts << Reply #2 on: 06/19/2016 at 09:43:21 >>:

http://bbcbasic.conforums.com/index.cgi?action=display&board=assembly&&num=1466323816&&start=2#0

please allow me to insist and ask:

Under w32 or w64, is there any *clearly* defined range of permissible values for O% - in absolute addresses or relatively in terms of P% or whatever else - or any other programming way to find that range with certainty?

Sincerely,

Petros Zimourtopoulos
User IP Logged

Richard Russell
Administrator
ImageImageImageImageImage


member is offline

Avatar




Homepage PM


Posts: 605
xx Re: O% under w32/w64
« Reply #1 on: Sep 24th, 2017, 8:34pm »

on Sep 24th, 2017, 7:25pm, pez wrote:
Under w32 or w64, is there any *clearly* defined range of permissible values for O% - in absolute addresses or relatively in terms of P% or whatever else - or any other programming way to find that range with certainty?

O% can, in principle, point anywhere at all - so long as it is writable memory. Therefore, any of the methods of reserving memory available in BBC BASIC may be used: for example you can reserve it from the heap using DIM or from the stack using DIM ... LOCAL or from Windows by calling one of the memory allocation APIs such as GlobalAlloc or HeapAlloc.

It doesn't really matter which you choose: the whole point of separating O% (the address at which the assembled code is stored) and P% (the 'program counter') is that the absolute value of O% is unimportant.

Richard.
User IP Logged

pez
New Member
Image


member is offline

Avatar




Homepage PM


Posts: 4
xx Re: O% under w32/w64
« Reply #2 on: Sep 25th, 2017, 07:08am »

Dear Mr. Russell,

Thank you very much for your prompt reply.

Well, given that this is the case, what would you advise us to do - apart from using a mistrusted conventional assembler of "compiler" type - when we need an absolute starting address? Is that possible at all?

Finally, in order to relieve us from using, once more, that so tedious trial-and-error technique, could you, please, reveal to us if you provided this favorable assembler with checks which do not allow O% values of non-writable memory?

Sincerely yours,

Petros Zimourtopoulos
User IP Logged

Richard Russell
Administrator
ImageImageImageImageImage


member is offline

Avatar




Homepage PM


Posts: 605
xx Re: O% under w32/w64
« Reply #3 on: Sep 25th, 2017, 08:35am »

on Sep 25th, 2017, 07:08am, pez wrote:
when we need an absolute starting address? Is that possible at all?[

I think that perhaps you have confused the functions of O% and of P%. Since O% determines only where the assembled code is temporarily stored, not where it runs, there are no circumstances when it would need to have an absolute address. It's P% that may well need to have an "absolute starting address" (for example you may be wanting the assembled code to run in ROM at a specific place in the memory map) and there are no restrictions on the value of P% when OPT has been set appropriately.

A conventional standalone assembler typically stores the assembled code in a sequential file whereas BBC BASIC's assembler always stores the assembled code in memory. But they are equivalent: when writing to memory O% substitutes for the file pointer when writing to disk. It simply keeps track of where in memory the next byte should be written and its absolute value is irrelevant.

Quote:
checks which do not allow O% values of non-writable memory?

It's not possible for the BBC BASIC assembler to determine whether O% is set appropriately or not. If O% were set to an area of non-writable memory or non-existent memory then it would of course result in an immediate failure (typically an 'access violation' exception). But there are many areas of memory that are writable but which must not be written to, and accidentally setting O% there could cause data loss or file corruption or worse.

The main issue related to the use of the BBC BASIC assembler is that it is necessary to reserve memory in advance, in which the assembled code will be stored, but there is no way of determining how much memory needs to be reserved! Only after the first pass of the assembly process has completed is the size of the code known, and by then it's too late.

One solution is initially to reserve an amount of memory that is far more than could possibly be required, and then run one pass of the assembler. At that point you know how much memory is needed, so you can free the large amount of memory that you initially reserved and allocate a new, smaller, block that is only just large enough. Now you can run two more passes of the assembler as normal.

When you are wanting to assemble only a small amount of code this 'three pass' technique is probably overkill; you might as well simply allocate plenty of memory to begin with and accept that some of it will be wasted. But if you are keen to avoid memory wastage the three-pass technique is valuable.

Richard.
User IP Logged

pez
New Member
Image


member is offline

Avatar




Homepage PM


Posts: 4
xx Re: O% under w32/w64
« Reply #4 on: Sep 25th, 2017, 11:36am »

Dear Mr. Russell,

Yes, you are absolutely right of course; I had confused them.

Once again, thank you very much : for your prompt replies, for your detailed explanations, and for your time.

Respectfully yours,

Petros Zimourtopoulos
User IP Logged

pez
New Member
Image


member is offline

Avatar




Homepage PM


Posts: 4
xx Re: O% under w32/w64
« Reply #5 on: Sep 28th, 2017, 11:45am »

Dear Mr. Russell,

I had to look for the source of this confusion of mine, and I think that I located it in the common part of the following two, slightly different, phrases - from the session "Reserving Memory" in both Assembler versions:

Basic86 Manual : "Machine code instructions are assembled as if they were going to be placed in memory at the addresses specified by the program counter, P%. Their actual location in memory may be determined by O% depending on the OPTion specified (see below)."

BBC BASIC for Windows Help : "Machine code instructions are assembled as if they were going to be placed in memory at the addresses specified by the program counter, P%. Their actual location in memory is determined by P% or O% depending on the value of OPT used."

from which I erroneously concluded that, since O% is the only one, from P% and O%, which is mentioned in both versions, then O% definitely points to actual, that is "absolute" for me, locations.

Thank you for reading all that.

Sincerely yours,

Petros Zimourtopoulos
User IP Logged

Richard Russell
Administrator
ImageImageImageImageImage


member is offline

Avatar




Homepage PM


Posts: 605
xx Re: O% under w32/w64
« Reply #6 on: Sep 28th, 2017, 1:08pm »

on Sep 28th, 2017, 11:45am, pez wrote:
I erroneously concluded that, since O% is the only one, from P% and O%, which is mentioned in both versions, then O% definitely points to actual, that is "absolute" for me, locations.

Actually both O% and P% are mentioned in both versions (P% at the end of the first sentence, O% in the second sentence). No doubt the change from the older version to the newer one was supposed to make it clearer, but it may not have succeeded.

The historical context is that in early versions of BBC BASIC (for example the original 6502 and Z80 versions) P% determined both where the code was stored in memory and where it would ultimately be executed. There was no provision for these to be different, and neither O% nor bit 2 of OPT were used by the assembler.

This is still by far the most common mode of operation, since the assembler is normally used to generate code that will be executed at run time by the same program. The ability to store the code at a different address (O%) from that at which it will be executed (P%) was added to support two main usage cases:
  • Assembling code that will eventually be programmed into a ROM or other non-volatile read-only storage device.

  • Assembling code which be copied into, and executed in, the address space of another process.
In either case the eventual execution address must be known at assemble-time. The BBC BASIC assembler does not have the capability, that virtually all standalone assemblers do, of outputting 'relocatable' object code that can be automatically adjusted (by a linker or loader program) to execute at any address.

Of course it is possible to use any assembler, including BBC BASIC's assembler, to create 'position independent code' (PIC) that will run at any address without modification. But there is an overhead in creating such code (more so in the case of 32-bit x86 than ARM, since the former doesn't support PC-relative addressing).

Richard.
« Last Edit: Sep 28th, 2017, 1:15pm 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