Can anyone spot why this piece of code can't *Save a file out???
Gazza
20 : REM For this to work, you MUST have at least the same
amount of
30 : REM free memory available as the amount of free space on
the
40 : REM media you wish to wipe. This means a 2MB buffer to wipe
50 : REM blank HD floppies.
60 : CLS:file%=0:pass%=1:seed%=RND(0-TIME)
70 : REPEAT:file$=FNrandomname(8):UNTIL FNfind(file$)=0
80 : ON ERROR PROCmoan:END
90 :
100 : REM Configs... All must be defined but can be changed by
the user.
110 : REM passes% : The number of times a block of random
garbage gets
120 : REM written as a file to the media.
130 : REM prngmax% : The highest number used by the random
number
140 : REM generator. As the memory is organised in
bytes, the
150 : REM highest possible number is 255.
160 : REM drive% : The target drive. This is the one that gets
hit.
170 : passes% =3 :REM Total number of passes.
180 : prngmax% =255 :REM Maximum value for PRNG.
(Max. 255)
190 : drive% =0 :REM Target drive.
200 :
210 : REM Announce...
220 : PRINT"This program wipes the free space on the media in
drive ";drive%
230 : PRINT"Once used any deleted files cannot be retrieved by"
240 : PRINT"ANYTHING!":PRINT
250 : PRINT"Do you want to continue? (Y/N)":PRINT
260 : REPEAT
270 : g$=GET$
280 : UNTIL INSTR("YyNn",g$)<>0
290 : IF INSTR("Nn",g$)<>0 THEN PRINT"Operation aborted by
user!!":END
300 :
310 : REM Get the amount of available space on the disc and
create a memory
320 : REM block of that size.
330 : space%=FNfreespace(drive%):PRINT"There are ";space%;" bytes
remaining.":PRINT
340 : DIM blk% space%
350 :
360 : REM Fill this block with different garbage for every pass.
370 : REM and write it to disc in the fastest safe way possible.
380 : REM We kick the PRNG before we fill the block each time to
390 : REM make sure we have random garbage.
400 : seed%=RND(0-TIME) :REM Kick PRNG.
410 : PRINT"Filling block..."
420 : FOR offs%=0 TO space%:PRINTTAB(18,8)"Offset "+STR$(offs
%):blk%?offs%=RND(prngmax%):NEXT offs%
430 :
440 : FOR pass%=1 TO passes%
450 : PRINT"Pass ";pass%;"..."
460 : path$="ADFS::"+STR$(drive%)+".$."+file$
470 : PRINT"Writing ";space%;" bytes."
480 : OSCLI"Save "+path$+" "+STR$(blk%)+" + "+STR$(space%)
490 : NEXT pass%
500 :
510 : REM We are done, display message and tidy up!
520 : PRINT"Operation completed sucessfully!"
530 : END
540 :
550 : DEFFNfreespace(drive%)
560 : LOCAL free%,dr$:dr$=":"+STR$(drive%)
570 : SYS"ADFS_FreeSpace",dr$ TO ,free%
580 : =free%
590 :
600 : DEFPROCmoan
610 : REPORT:PRINT" at line ";ERL
620 : PRINT"The wipe operation failed!!"
630 : PRINT"This could be down to a media or programming error!"
640 : ENDPROC
650 :
660 : DEFFNrandomname(length%)
670 : LOCAL i%,file$
680 : FOR i%=1 TO length%
690 : file$+=CHR$(96+RND(26))
700 : NEXT i%
710 : =file$
720 :
730 : DEFFNfind(file$)
740 : LOCAL found%
750 : SYS"XOS_File",17,file$ TO found%
760 : =found%
Yes... I know it's messy as hell. I haven't yet had the time to tidy
it up and optimise it yet. What's happening is that I'm getting "No
readable memory at this address." when I try to *Save the file from
within the program. However, when I stick a breakpoint in the code
before line 480 and issue PRINT ~blk% and PRINT ~space% to get the
addresses in hex and issue the following command...
OSCLI"Save "+path$+"&<~blk%> + &<~space%>"
... The file will write itself to disk quite happily. The logically
obvious answer would be to use STR$(~blk%) and STR$(~space%) but doing
this just seems to spout "Unknown variable." errors...
Any help would be appreciated.
Peter Naulls
>
> Yes... I know it's messy as hell. I haven't yet had the time to tidy
> it up and optimise it yet. What's happening is that I'm getting "No
> readable memory at this address." when I try to *Save the file from
> within the program. However, when I stick a breakpoint in the code
> before line 480 and issue PRINT ~blk% and PRINT ~space% to get the
> addresses in hex and issue the following command...
With due respect, maybe that's the problem. If you know it's
messy, then tidying might be exactly what's in order. Not
only might you find the problem yourself, but asking other
people to read code you know is messy is asking a bit too
much.
Bryan Hogan
ups.com>
Gazza <use...@garethlock.com> wrote:
> ... The file will write itself to disk quite happily. The logically
> obvious answer would be to use STR$(~blk%) and STR$(~space%) but doing
> this just seems to spout "Unknown variable." errors...
You've got the tilde in the wrong place:
PRINT STR$~(blk%)
...should do the trick.
Bryan.
Ste (news)
<d4c9b626-0f64-4451...@e27g2000yqd.googlegroups.com>,
Gazza <use...@garethlock.com> wrote:
> OSCLI"Save "+path$+"&<~blk%> + &<~space%>"
>
> ... The file will write itself to disk quite happily. The logically
> obvious answer would be to use STR$(~blk%) and STR$(~space%) but doing
> this just seems to spout "Unknown variable." errors...
The syntax you require is:
OSCLI"Save "+path$+" " + STR$~blk% + " + " + STR$~space%
As to why you are not using OS_File 10, I have no idea. There should be
little or no need for OSCLI in any BASIC program.
Steve
--
Steve Revill @ Home
Note: All opinions expressed herein are my own.
Richard Russell
> As to why you are not using OS_File 10, I have no idea. There should be
> little or no need for OSCLI in any BASIC program.
Platform independence? OSCLI "SAVE..." is portable across all
versions of BBC BASIC; OS_File 10 is RISC OS only. I know there are
other aspects of the program that are necessarily OS-specific, but to
me that isn't a good reason to make the rest less portable than it
need be.
Richard.
http://www.rtrussell.co.uk/
Jonathan Graham Harston
> 480 : OSCLI"Save "+path$+" "+STR$(blk%)+" + "+STR$(space%)
OSCLI "Save "+path$+" "+STR$~blk%+" + "+STR$~space%
> obvious answer would be to use STR$(~blk%) and STR$(~space%) but doing
--
J.G.Harston - j...@arcade.demon.co.uk - mdfs.net/User/JGH
There are three food groups: brown, green and ice cream.
Christopher Bazley
> On Dec 25, 2:03 am, "Ste (news)" <st...@revi11.plus.com> wrote:
>
> > As to why you are not using OS_File 10, I have no idea. There should be
> > little or no need for OSCLI in any BASIC program.
>
> Platform independence? OSCLI "SAVE..." is portable across all
> versions of BBC BASIC; OS_File 10 is RISC OS only.
Really? You astonish me. So presumably "all versions of BBC BASIC"
emulate a subset of Acorn MOS commands. How on earth do you decide
which of the many commands to emulate? Many BBC BASIC programs dating
from the 1980s will use *FX, which alone gives access to a huge number
of operations.
If I were writing a BBC BASIC interpreter then I'd disclaim any
knowledge of the effects of OSCLI, just as the system() function in
the ISO standard C library isn't a portable mechanism of doing
anything.
--
Christopher Bazley
Rob Kendrick
Christopher Bazley <cs9...@gmail.com> wrote:
> > Platform independence? OSCLI "SAVE..." is portable across all
> > versions of BBC BASIC; OS_File 10 is RISC OS only.
>
> Really? You astonish me. So presumably "all versions of BBC BASIC"
> emulate a subset of Acorn MOS commands. How on earth do you decide
> which of the many commands to emulate? Many BBC BASIC programs dating
> from the 1980s will use *FX, which alone gives access to a huge number
> of operations.
>
> If I were writing a BBC BASIC interpreter then I'd disclaim any
> knowledge of the effects of OSCLI, just as the system() function in
> the ISO standard C library isn't a portable mechanism of doing
> anything.
Indeed; I doubt it works reliably, or at all, under Windows, DOS, on
the various Z80 systems, or under UNIX with Brandy.
How hard is it to write a function to do this? 5 lines?
B.
Richard Russell
> Really? You astonish me. So presumably "all versions of BBC BASIC"
> emulate a subset of Acorn MOS commands. How on earth do you decide
> which of the many commands to emulate?
OSCLI commands can fairly readily be divided into two broad categories
- those that are inherently OS-specific and those which are not OS-
specific and which in many other BASICs are provided by native
statements. Effectively the latter kind are just extending the BBC
BASIC language.
OSCLI "FX..." is clearly in the former category; most of the *FX
commands have no direct equivalent in non-Acorn OSes. OSCLI "SAVE..."
however is firmly in the latter category; most BASICs provide a means
to save and load files from/to blocks of memory (e.g. BSAVE/BLOAD in
some dialects). Therefore all my versions of BBC BASIC, irrespective
of OS platform, implement OSCLI "SAVE..." and OSCLI "LOAD...".
> If I were writing a BBC BASIC interpreter then I'd disclaim any
> knowledge of the effects of OSCLI
That's not very 'user friendly'. The split between what operations
are available as native BBC BASIC statements (e.g. CHAIN) and what are
available only via OSCLI (e.g. *LOAD) is largely arbitrary, and stems
partly from historical limitations on the BBC Micro (both of memory
and availability of 8-bit tokens). It doesn't seem right to me to
deny a BBC BASIC user a platform-independent way of saving out a block
of memory to file simply because of a design decision taken in 1981
that has no real relevance today.
Richard.
http://www.rtrussell.co.uk/
To reply by email change 'news' to my forename.
Rob Kendrick
Richard Russell <ne...@rtrussell.co.uk> wrote:
> OSCLI "FX..." is clearly in the former category; most of the *FX
> commands have no direct equivalent in non-Acorn OSes. OSCLI "SAVE..."
> however is firmly in the latter category; most BASICs provide a means
> to save and load files from/to blocks of memory (e.g. BSAVE/BLOAD in
> some dialects). Therefore all my versions of BBC BASIC, irrespective
> of OS platform, implement OSCLI "SAVE..." and OSCLI "LOAD...".
And what happens when somebody wants to launch SAVE.EXE ? :)
B.
Richard Russell
> And what happens when somebody wants to launch SAVE.EXE ? :)
**SAVE
or
*RUN SAVE
or
OSCLI "*SAVE"
or
OSCLI "RUN SAVE"
will all do that.
Gazza
STR$~(space%) as described by Bryan Hogan and all seems to work. In a
brief answer to Steve as to why I didn't use OS_File 10, I was cooking
this up in 15 minutes at the club and didn't have easy reference to
the PRM regarding the syntax of OS_File 10, otherwise I'd have
probably gone down this route.
Currently, I'm using the code on line 420 to fill the memory with
random garbage...
FOR offs%=0 TO space%:blk%?offs%=RND(255):NEXT offs%
Is there a quicker way of doing this, possibly using ARM code? Filling
a 1.44MB block is taking upwards of 20 minutes.
Christopher Bazley
I got a bit carried away and wrote a function to do the equivalent of
*Save. As you might expect, it is an order of magnitude slower to save
a file one byte at a time than as a single block of data, but it would
be a practical alternative for many applications.
I obtained the following results on my StrongARM Risc PC when creating
256 KB files on a RAM disc:
BASIC's BPUT : 1971 bytes per centisecond
OSCLI *Save : 152044 bytes per centisecond
SWI OS_File 10 : 154665 bytes per centisecond
The difference is less significant with 1 KB files (more time in BASIC
interpreter, less in the OS):
BASIC's BPUT : 768 bytes per centisecond
OSCLI *Save : 2243 bytes per centisecond
SWI OS_File 10 : 2355 bytes per centisecond
Here is my test program:
ON ERROR: ON ERROR OFF: PRINT REPORT$;" at line ";ERL:END
@%="F.3"
blocksize% = 256 * 1024
DIM test% blocksize%-1
n% = 0:t% = TIME
REPEAT
PROCsave("1", test%, blocksize%)
n% += blocksize%:s% = TIME - t%
UNTIL s% >= 100
PROCreport(n%, s%)
n% = 0:t% = TIME
REPEAT
PROCsave2("2", test%, blocksize%)
n% += blocksize%:s% = TIME - t%
UNTIL s% >= 100
PROCreport(n%, s%)
n% = 0:t% = TIME
REPEAT
PROCsave3("3", test%, blocksize%)
n% += blocksize%:s% = TIME - t%
UNTIL s% >= 100
PROCreport(n%, s%)
END
DEF PROCsave(path$, blk%, space%)
LOCAL f%
f% = OPENOUT(path$)
WHILE space% > 0
BPUT#f%,?blk%:blk% += 1
space% -= 1
ENDWHILE
CLOSE #f%
ENDPROC
DEF PROCsave2(path$, blk%, space%)
OSCLI("Save "+path$+" "+STR$~blk%+" + "+STR$~space%)
ENDPROC
DEF PROCsave3(path$, blk%, space%)
SYS "OS_File",0,path$,blk%,blk%,blk%,blk%+space%
ENDPROC
DEF PROCreport(n%, s%)
PRINT "Bytes per centisecond :";n% / s%
ENDPROC
Despite its relative slowness, I feel that PROCsave has something to
recommend it: namely, the fact that it is highly portable, pure BBC
BASIC.
--
Christopher Bazley
Christopher Bazley
I respect your opinion (particularly given your involvement in the
design of BBC BASIC). However, the need for gymnastics with STR$ and
knowledge of the syntax of a command for an obsolete OS (e.g. that it
implicitly expects hexadecimal addresses) are clear evidence that the
lack of block-save and block-load commands in BBC BASIC has a great
deal of relevance today. The fact that the original poster got the STR
$~ part of the puzzle wrong supports this.
The need for an extra token could be avoided by providing an
alternative form of the BPUT and BGET commands that allowed
specification of a start address and the number of bytes to be written/
read.
--
Christopher Bazley
Chris Hall
ups.com>
Gazza <use...@garethlock.com> wrote:
[snip]
> ... The file will write itself to disk quite happily. The logically
> obvious answer would be to use STR$(~blk%) and STR$(~space%) but doing
> this just seems to spout "Unknown variable." errors...
> Any help would be appreciated.
STR$~(var%) works, STR$(~var%) doesn't.
--
Chris Hall <ch...@svrsig.org>
Martin Bazley
Er, fill it with zeroes instead? Just as effective, and considerably
less processor-intensive.
Of course, you technically don't need to fill it with anything at all,
since the original contents of the block will be fairly random anyway.
If you really want ARM code, try this: (untested, of course, since this
is csap!)
blocksize%=1600*1024:REM May need to be reduced slightly
DIM block% blocksize%
DIM code% 256
FOR pass%=0 TO 2 STEP 2
P%=code%
[OPT pass%
MOV R2,#0
MOV R3,R0
.loop%
STR R2,[R3],#4
CMP R3,R1
BLT loop%
MOV R4,R0
MOV R5,R1
MOV R0,#10
ADR R1,filename%
SWI "OS_File"
MOV R0,#6
SWI "OS_File"
MOV PC,R14
.filename%
EQUS "ADFS::0.$.x"
EQUB 0
ALIGN
]
NEXT
A%=block%
B%=block%+blocksize%
CALL code%
--
__<^>__ Red sky in the morning: Shepherd's warning
/ _ _ \ Red sky at night: Shepherd's delight
( ( |_| ) ) Mince and potatoes: Shepherd's pie
\_> <_/ ======================= Martin Bazley ==========================
Chris Johnson
<f7d02a2a-ecf9-4dea...@m38g2000yqd.googlegroups.com>,
> Is there a quicker way of doing this, possibly using ARM code?
> Filling a 1.44MB block is taking upwards of 20 minutes.
I guess writing single bytes is going to be the slowest. Writing a
stream of 32-bit words would speed things up, remembering the total
size may not be an integral number of words, so a check on space%
would be required, and any odd bytes at the end written separately.
Assembler would obviously speed things up (by orders of magnitude?),
again writing words of data would be much quicker than single bytes.
--
Chris Johnson
Rob Kendrick
Christopher Bazley <cs9...@gmail.com> wrote:
> I got a bit carried away and wrote a function to do the equivalent of
> *Save. As you might expect, it is an order of magnitude slower to save
> a file one byte at a time than as a single block of data, but it would
> be a practical alternative for many applications.
Indeed; nobody expects applications written in BBC Basic to be fast.
And if they care about portability like this (if they don't, what's
wrong with OS_GBPB and OS_File?), it's the price they pay.
B.
Rob Kendrick
Richard Russell <ne...@rtrussell.co.uk> wrote:
> On Dec 27, 12:17 pm, Rob Kendrick <n...@rjek.com> wrote:
> > And what happens when somebody wants to launch SAVE.EXE ? :)
>
> **SAVE
> or
> *RUN SAVE
> or
> OSCLI "*SAVE"
> or
> OSCLI "RUN SAVE"
>
> will all do that.
My point being that it stinks of specialism and hack. Anybody using
OSCLI has no right to assume any portability at all.
B.
Rob Kendrick
Gazza <use...@garethlock.com> wrote:
> Currently, I'm using the code on line 420 to fill the memory with
> random garbage...
>
> FOR offs%=0 TO space%:blk%?offs%=RND(255):NEXT offs%
>
> Is there a quicker way of doing this, possibly using ARM code? Filling
> a 1.44MB block is taking upwards of 20 minutes.
Why do you want to fill it with random data? Depending on what you
actually want to do, you may not need to do this at all. Otherwise, I
have a reasonably fast ARM implementation of ARC4 somewhere which is a
reasonably good PRNG and stream cipher that's also very simple to
understand. But it might not be worth using, depending on your
situation.
B.
Gazza
wrote:
Thanks Martin. This should work for me. Seeing as space% is read by
using a call to ADFS_FreeSpace the block size I use is exactly the
amount of free space on the target device. As I understand it, to
stick it in my code, all I need to do is...
A%=blk%
B%=blk%+space%
Could you confirm this to be correct?
Gazza
This program, when given a blank, but previously used floppy should be
able to securely wipe whatever is in the data area, whether the FS can
see it or not... Remember when you delete files, the data is still
there until it's overwritten. All you do is remove the file record
from the catalogue.
Richard Russell
> The need for an extra token could be avoided by providing an
> alternative form of the BPUT and BGET commands that allowed
> specification of a start address and the number of bytes to be written/
> read.
But this doesn't help the portability aspect at all, since even if I
provided such a feature in BB4W it would be the *only* version of BBC
BASIC to have it! The whole point of supporting OSCLI "SAVE..." is to
provide a *portable* way of saving a block of memory to a file; the
awkward syntax (in terms of hex addresses etc) is an unavoidable
consequence.
Richard.
http://www.rtrussell.co.uk/
To reply by enail change 'news' to my forename.
Gazza
>
> - Show quoted text -
I tried the OPENOUT route to start with and found thew thrashing of
the FDD during the operation to be unacceptable. Hence the fill a
block and dump it all at once method.
Steve Drain
>
> DEF PROCsave(path$, blk%, space%)
> LOCAL f%
> f% = OPENOUT(path$)
> WHILE space% > 0
> BPUT#f%,?blk%:blk% += 1
> space% -= 1
> ENDWHILE
> CLOSE #f%
> ENDPROC
>
> recommend it: namely, the fact that it is highly portable, pure BBC
> BASIC.
May I offer a quicker loop:
DEF PROCsave(path$, blk%, space%)
LOCAL f%,i%
f% = OPENOUT(path$)
FOR i%=0 TO space%
BPUT#f%,blk%?i%
NEXT i%
CLOSE #f%
ENDPROC
It is more than 10% faster. ;-)
--
; ,', * Basalt * - gives RO 3.10+ versions of BASIC V new and alternative
;,' keywords, dynamic memory for arrays and blocks, new variable types.
;', Legal, fast and simple to use. Freeware - version 0.98� - 19 Aug 03
,; ',, Steve Drain, Kappa : http://www.kappa.me.uk/basalt.htm
David Holden
Might I suggest a different approach which would be a *lot* quicker.
1. Find out how much free space there is on the disc.
2. DIM a block of memory that size.
3. Fill block of memory with 0's (or anything else you chose)
4. Save the block of data to the disc.
Should take a few seconds.
--
David Holden - APDL - <http://www.apdl.co.uk>
Richard Russell
> Indeed; nobody expects applications written in BBC Basic to be fast.
Rather a sweeping generalisation! When I want the very fastest
possible performance from an application, I use BBC BASIC with the
time-critical parts in assembler code. I could achieve *nearly* as
good performance by using an alternative language with inline
assembler capabilities (e.g. C) - or by linking with code assembled
conventionally - but BBC BASIC assembler has the edge.
This is because BBC BASIC assembles the code at run-time rather than
compile-time so, for example, 'immediate constants' can be used for
values which are actually variables at run-time (loading a register
from an immediate constant is usually faster than loading it from
memory). To match the performance using a conventional assembler
you'd have to resort to self-modifying-code: ugh!
This particular aspect of BBC BASIC is rarely highlighted despite
being (AFAIK) unique in any programming language.
Richard.
http://www.rtrussell.co.uk/
To reply by email change 'news' to my forename.
Rob Kendrick
Right, in which case you want to ADFS_DiscOp or similar to write
directly to blocks, and you'll want to write zeros, then ones, then
random data, then random data, then ones, then zeros, or a similar
contrived arrangement.
Otherwise, just wave a strong magnet over it and throw it in the bin :)
B.
Rob Kendrick
Richard Russell <ne...@rtrussell.co.uk> wrote:
> On Dec 27, 7:36 pm, Rob Kendrick <n...@rjek.com> wrote:
> > Indeed; nobody expects applications written in BBC Basic to be fast.
>
> Rather a sweeping generalisation! When I want the very fastest
> possible performance from an application, I use BBC BASIC with the
> time-critical parts in assembler code.
I just use C and a good compiler. If it's still not fast enough, I
wait a week or two. There's a difference between "slow", "fast", and
"fastest". "slow" is rarely good enough, and what BBC Basic is. C is
"fast", and writing your application in assembler and taking twice as
long over it for "fastest" is rarely necessary.
<snip>
> This is because BBC BASIC assembles the code at run-time rather than
> compile-time so, for example, 'immediate constants' can be used for
> values which are actually variables at run-time (loading a register
> from an immediate constant is usually faster than loading it from
> memory). To match the performance using a conventional assembler
> you'd have to resort to self-modifying-code: ugh!
>
> This particular aspect of BBC BASIC is rarely highlighted despite
> being (AFAIK) unique in any programming language.
There are countless libraries for doing this, and doing this portably,
from any language that supports C linkage.
B.
Richard Russell
> "fastest" is rarely necessary.
Rarely, but sometimes. If you're processing, say, real-time video
then it's essential that you can process a frame in less than 40 ms
(25 fps). 40.01 ms just isn't good enough - dropped frames are
unacceptable. If using BBC BASIC assembler makes that difference,
it's worthwhile. Don't knock it!
> There are countless libraries for doing this, and doing this portably,
> from any language that supports C linkage.
Interesting, I've never come across one. Have you a link?
Portability is in any case a somewhat limited concept when it comes to
assembler code!
Rob Kendrick
Richard Russell <ne...@rtrussell.co.uk> wrote:
> On Dec 28, 12:55 pm, Rob Kendrick <n...@rjek.com> wrote:
> > "fastest" is rarely necessary.
>
> Rarely, but sometimes. If you're processing, say, real-time video
> then it's essential that you can process a frame in less than 40 ms
> (25 fps). 40.01 ms just isn't good enough - dropped frames are
> unacceptable. If using BBC BASIC assembler makes that difference,
> it's worthwhile. Don't knock it!
That's a real-time problem, too. And I don't doubt that a C
implementation on a modest PC could do this for most common video
codecs. And the C code has the obvious advantage of automatically
being able to take advantage of new hardware when using a new compiler.
> > There are countless libraries for doing this, and doing this
> > portably, from any language that supports C linkage.
>
> Interesting, I've never come across one. Have you a link?
> Portability is in any case a somewhat limited concept when it comes to
> assembler code!
Firstly, there's libtcc, which is a C compiler (which I believe has
in-line assembler if you want to throw away portability) in the form of
a library. You pass it a string of C source, it returns a function
pointer to call.
Secondly, there's liblightning, which is a macro-based system where
assembler is abstracted from the real hardware, and then it will
assemble and optimise at runtime for where it's running.
Thirdly, there's LLVM. You either just write C code that constantly
gets optimised over the lifetime of the program, or you use it in a
similar approach to libtcc. LLVM's optimisations are astonishingly
good.
Fourthly, there are all the assembler-generation libraries out there
used by JITed languages such as LuaJIT, JavaScript V8, etc.
I don't doubt there are many many more.
B.
Richard Russell
> And I don't doubt that a C implementation on a modest PC could do this
> for most common video codecs.
You're missing the point (deliberately?). What a C implementation
might or might not be able to achieve with some specific processing
task (e.g. a video codec) is irrelevant.
If BBC BASIC assembler can do something more quickly than any other
method, then that's a valuable property. It may make it possible to
do something which cannot otherwise be done, or at the very least is
likely to make it possible to do something *better* than would
otherwise be the case (real-time video processing, in particular,
almost always involves a trade-off of quality against speed).
BBC BASIC has its strengths, and it has its weaknesses. You're
entitled to draw attention to its weaknesses, but don't knock the fact
that it is has a unique and valuable characteristic which means it is
particularly well suited when the very fastest performance is
desirable.
> Firstly, there's libtcc
> Secondly, there's liblightning
> Thirdly, there's LLVM.
> Fourthly, there are all the assembler-generation libraries out there
> used by JITed languages such as LuaJIT, JavaScript V8, etc.
None of those are at all comparable. They may help with optimising
code in various ways, but they don't allow you to write assembler code
in which values that are variables at run-time are coded as inline
immediate constants.
Peter Naulls
[snip dozens and dozens of lines again including a GMail bit]
> I tried the OPENOUT route to start with and found thew thrashing of
> the FDD during the operation to be unacceptable. Hence the fill a
> block and dump it all at once method.
If you really are going to consume lots of bandwidth (mental or
otherwise) here, then for the 20th time, please trim approprirately.
Rob Kendrick
Richard Russell <ne...@rtrussell.co.uk> wrote:
> On Dec 28, 1:14 pm, Rob Kendrick <n...@rjek.com> wrote:
> > And I don't doubt that a C implementation on a modest PC could do
> > this for most common video codecs.
>
> You're missing the point (deliberately?). What a C implementation
> might or might not be able to achieve with some specific processing
> task (e.g. a video codec) is irrelevant.
>
> If BBC BASIC assembler can do something more quickly than any other
> method, then that's a valuable property. It may make it possible to
> do something which cannot otherwise be done, or at the very least is
> likely to make it possible to do something *better* than would
> otherwise be the case (real-time video processing, in particular,
> almost always involves a trade-off of quality against speed).
Except it doesn't, and isn't, and other things do it more easily,
maintainably and reusably.
> > Firstly, there's libtcc
> > Secondly, there's liblightning
> > Thirdly, there's LLVM.
> > Fourthly, there are all the assembler-generation libraries out there
> > used by JITed languages such as LuaJIT, JavaScript V8, etc.
>
> None of those are at all comparable. They may help with optimising
> code in various ways, but they don't allow you to write assembler code
> in which values that are variables at run-time are coded as inline
> immediate constants.
They all do. (A code generator that does not has very limited
usefulness; especially when your aim is to write a JIT.)
B.
Martin Bazley
[huge snip - please learn to quote!]
>
> Thanks Martin. This should work for me. Seeing as space% is read by
> using a call to ADFS_FreeSpace the block size I use is exactly the
> amount of free space on the target device. As I understand it, to
> stick it in my code, all I need to do is...
>
> A%=blk%
> B%=blk%+space%
>
> Could you confirm this to be correct?
As far as I can tell, yes, that should work. All usual Usenet warnings
about not having been tested in any way apply, though...
--
__<^>__ "Did you know that polar bears stay white all year round? ...The
/ _ _ \ white colour makes them less visible to the seals and penguins they
( ( |_| ) ) hunt." - Nelson Thornes AQA-endorsed GCSE science textbook
Richard Russell
> BBC BASIC assembles the code at run-time rather than
> compile-time so, for example, 'immediate constants' can be used for
> values which are actually variables at run-time (loading a register
> from an immediate constant is usually faster than loading it from
> memory).
Something I've not done previously is actually to quantify the speed
advantage of loading a register from an immediate constant rather than
a memory location. I've just done that, and on my PC 'mov eax,[data]'
takes a little over twice as long as 'mov eax,constant' when the
memory location is cached (sorry, I'm only in a position to test x86
code here). If the memory location wasn't in the L1 cache the
advantage would be very much greater.
Obviously the overall benefit in execution speed that can be achieved
by this substitution will never be great, because instructions that
can take immediate data instead of accessing memory will only ever be
a small part of the time-critical code, but any improvement is worth
having.
However much or little the potential benefit, I still think it's a
noteworthy side-effect of being able to assemble code at run-time
rather than compile/link-time. It's something I've been aware of, and
have actively taken advantage of, for some time, but I don't think
I've ever seen it mentioned before in discussions about what makes BBC
BASIC 'different'.
I'm saddened that there seem to be people (or at least one person!) so
opposed to BBC BASIC that they feel the need to challenge even this
simple statement of fact. Hopefully some others will have found it as
interesting as I do.
druck
> If BBC BASIC assembler can do something more quickly than any other
> method, then that's a valuable property. It may make it possible to
> do something which cannot otherwise be done, or at the very least is
> likely to make it possible to do something *better* than would
> otherwise be the case (real-time video processing, in particular,
> almost always involves a trade-off of quality against speed).
But none of your points remotely stand up. The only example you came up
with was using assembler, and using a BASIC runtime to generate
assembler, firstly isn't really using BASIC, just an awkward inefficent
way to generate assembler.
> BBC BASIC has its strengths, and it has its weaknesses. You're
> entitled to draw attention to its weaknesses, but don't knock the fact
> that it is has a unique and valuable characteristic which means it is
> particularly well suited when the very fastest performance is
> desirable.
But what features are these, apart from generating something else?
---druck
druck
> I'm saddened that there seem to be people (or at least one person!) so
> opposed to BBC BASIC that they feel the need to challenge even this
> simple statement of fact. Hopefully some others will have found it as
> interesting as I do.
I'm saddened when hobbyist BASIC programmers pretend nothing has been
learnt from 50 years of computer science language development and
professional software engineering best practice. There are languages
which are vastly superior to BASIC, even BBC BASIC, in every way.
If you don't feel inclined to / capable of learning any of them, then
carry on using BASIC and hand written assembler (the least productive
form of programming that exists), but please don't pretend it because it
is in anyway superior or the best solution to any task.
---druck
Jonathan Graham Harston
> deny a BBC BASIC user a platform-independent way of saving out a block
> of memory to file simply because of a design decision taken in 1981
> that has no real relevance today.
to Roger is to implement LOAD string,addr and SAVE string,addr,addr
in BASIC, rather than LOAD and SAVE only being for BASIC programs.
nntp wrote:
> > of OS platform, implement OSCLI "SAVE..." and OSCLI "LOAD...".
>
> And what happens when somebody wants to launch SAVE.EXE ? :)
*Run.
nntp wrote:
> Indeed; nobody expects applications written in BBC Basic to be fast.
> And if they care about portability like this (if they don't, what's
> wrong with OS_GBPB and OS_File?), it's the price they pay.
checks what platform the program is running on and issues
appropriate calls. Eg:
DEFPROCf_cdir(A$)
ON ERROR LOCAL:ENDPROC
IF use_mkdir THEN OSCLI"MkDir "+A$ ELSE OSCLI"CDir "+A$
ENDPROC
nntp wrote:
> My point being that it stinks of specialism and hack. Anybody using
> OSCLI has no right to assume any portability at all.
*SAVE is not available to a running BBC BASIC program.
usenet wrote:
> FOR offs%=0 TO space%:blk%?offs%=RND(255):NEXT offs%
>
> Is there a quicker way of doing this, possibly using ARM code? Filling
> a 1.44MB block is taking upwards of 20 minutes.
FOR offs%=0 TO space% STEP 4:blk%!offs%=RND(&7FFFFFFF):NEXT offs%
or you could try:
FOR offs%=0 TO space% STEP 128
$(blk%+offs%)=STRING$(128,CHR$0)
NEXT offs%
but the space needs to have a spare byte at the end for the
terminating <CR>.
--
J.G.Harston - j...@arcade.demon.co.uk - mdfs.net/User/JGH
...and Brutha said to Simony, "Where there is darkness we will make
a great light"
Richard Russell
> The only example you came up with was using assembler
D'oh! This entire discussion is about using assembly language and the
benefits that assembling the source code at run time can bring. It
has nothing whatever to do with any other aspects of BBC BASIC, so
trying to bring them into the equation simply muddies the waters.
> But what features are these, apart from generating something else?
This isn't about BASIC, it's about assembly language and how using the
BBC BASIC assembler can result in code that runs faster than using a
conventional assembler.
> If you don't feel inclined to / capable of learning any of them, then
> carry on using BASIC and hand written assembler (the least productive
> form of programming that exists), but please don't pretend it because it
> is in anyway superior or the best solution to any task.
As I think you know perfectly well, I was a professional programmer
for over 25 years and much of my coding has been done in C (with a
little in Fortran and C++, and a smattering in more obscure
languages). But it's you who has brought the relative merits of
different programming languages into this discussion, not me!
Surely it should be possible to have a sensible, technical, non-
controversial discussion about the BBC BASIC assembler without
drifting off at a tangent into the merits or otherwise of BASIC and
other languages? Oh, silly me, not on a comp.sys.acorn newsgroup
obviously!
Richard.
http://www.rtrussell.co.uk/
Rob Kendrick
druck <ne...@druck.org.uk> wrote:
> If you don't feel inclined to / capable of learning any of them, then
> carry on using BASIC and hand written assembler (the least productive
> form of programming that exists), but please don't pretend it because
> it is in anyway superior or the best solution to any task.
Or even remotely unique to BBC Basic.
B.
Rob Kendrick
j...@arcade.demon.co.uk (Jonathan Graham Harston) wrote:
> nntp wrote:
You're breaking threading again. Stop that.
> > > of OS platform, implement OSCLI "SAVE..." and OSCLI "LOAD...".
> >
> > And what happens when somebody wants to launch SAVE.EXE ? :)
>
> How would you do it on any other platform?
>
> *Run.
Right, and now how to run "*Run" ? If you can't recognise this as an
ugly hack, there's no hope for you.
> nntp wrote:
> > Indeed; nobody expects applications written in BBC Basic to be
> > fast.
>
> I do.
There's no hope for you. :)
> > And if they care about portability like this (if they don't, what's
> > wrong with OS_GBPB and OS_File?), it's the price they pay.
>
> When I want to be that platform independant, I use a library that
> checks what platform the program is running on and issues
> appropriate calls. Eg:
>
> DEFPROCf_cdir(A$)
> ON ERROR LOCAL:ENDPROC
> IF use_mkdir THEN OSCLI"MkDir "+A$ ELSE OSCLI"CDir "+A$
> ENDPROC
And to think that we've had an operating system API abstraction
standard from the IEEE for 20 years, and people still refuse to use it,
even though we have an excellent implementation under RISC OS!
> nntp wrote:
> > My point being that it stinks of specialism and hack. Anybody using
> > OSCLI has no right to assume any portability at all.
>
> Give me a list of platforms that BBC BASIC is available for where
> *SAVE is not available to a running BBC BASIC program.
Give me a list where it doesn't stink of specialism and hack, like most
of BBC Basic.
B.
Richard Russell
wrote:
> When I get that time machine built, the one message I'll send back
> to Roger is to implement LOAD string,addr and SAVE string,addr,addr
> in BASIC, rather than LOAD and SAVE only being for BASIC programs.
Indeed; I'd probably also want to add other 'file system' operations
such as deleting and renaming files, which have direct equivalents in
pretty much every OS and which are intrinsic to most BASICs (for
example in QBASIC they're 'KILL filespec$' and 'NAME oldspec$ AS
newspec$' respectively).
To be fair to Sophie, given the 16K language restriction of the BBC
Micro it was probably the right decision to offload these to OSCLI,
but it would have been desirable to add them in BASIC 5. Of course I
have to accept some of the blame myself, because it was up to the BBC
(i.e. me) to make suggestions for additions at that stage, and it
never occurred to me to propose incorporating them.
> > Indeed; nobody expects applications written in BBC Basic to be fast.
>
> I do.
Fast is a relative term. BBC BASIC is fast for a 'pure' interpreter
(for example I benchmarked it as about 15-times faster than Liberty
Basic, which is also an interpreter) but obviously it's excruciatingly
slow compared with many other languages, unless you make use of
assembler code.
> When I want to be that platform independant, I use a library that
> checks what platform the program is running on and issues
> appropriate calls.
I agree that's a good approach. Speculating about what BBC BASIC
*might* have been, with hindsight, has little value other than as an
academic exercise (unless that time machine of yours starts
working!). I'd far rather concentrate on practical ways of overcoming
its limitations.
Richard.
http://www.rtrussell.co.uk/
Ste (news)
Jonathan Graham Harston <j...@arcade.demon.co.uk> wrote:
> A simple four-fold increase:
>
> FOR offs%=0 TO space% STEP 4:blk%!offs%=RND(&7FFFFFFF):NEXT offs%
or this:
FOR ptr%=blk% TO blk% + space% STEP 4:!ptr%=RND:NEXT
Which is going to be faster yet. Be very careful with this sort of thing; it
is easy to write too many bytes at the end of the block and corrupt any
following data. For example, if you did:
DIM blk% space%
then you're asking for trouble. The FOR loop should look more like this:
FOR ptr%=blk% TO blk% + space% - 4 STEP 4
and even then it's only going to work correctly iff space% was a whole
multiple of 4.
Steve
--
Steve Revill @ Home
Note: All opinions expressed herein are my own.
Xavier
http://www.amazon.com/Build-Time-Machine-Paul-Davies/dp/0670030635
But well don't start spending a few billions to build the machine,
as some say it's already built, applying Davies' ideas :
http://public.web.cern.ch/Public/fr/LHC/LHC-fr.html
Jonathan Graham Harston
> academic exercise (unless that time machine of yours starts
> working!). I'd far rather concentrate on practical ways of overcoming
> its limitations.
You don't blame the tool when used to do an inappropriate task, you
blame the person inappropriately using it.RISC OS Choices System - http://mdfs.net/Software/RISCOS
chris...@bigfoot.com
> Christopher Bazley wrote:
>
> > DEF PROCsave(path$, blk%, space%)
> > LOCAL f%
> > f% = OPENOUT(path$)
> > WHILE space% > 0
> > BPUT#f%,?blk%:blk% += 1
> > space% -= 1
> > ENDWHILE
> > CLOSE #f%
> > ENDPROC
>
> > Despite its relative slowness, I feel that PROCsave has something to
> > recommend it: namely, the fact that it is highly portable, pure BBC
> > BASIC.
>
> May I offer a quicker loop:
>
> DEF PROCsave(path$, blk%, space%)
> LOCAL f%,i%
> f% = OPENOUT(path$)
> FOR i%=0 TO space%
> BPUT#f%,blk%?i%
> NEXT i%
> CLOSE #f%
> ENDPROC
>
> It is more than 10% faster. ;-)
Somewhat improbably, my machine reports it to be approximately 32%
faster (0.347 cs rather than 0.511 cs per KB). However, it also
produces the wrong result (by outputting 1 byte too many) because
BASIC's FOR loop is inclusive (blk%?space% is out of bounds).
--
Christopher Bazley
Christopher Bazley
> Christopher Bazley wrote:
>
> > DEF PROCsave(path$, blk%, space%)
> > LOCAL f%
> > f% = OPENOUT(path$)
> > WHILE space% > 0
> > BPUT#f%,?blk%:blk% += 1
> > space% -= 1
> > ENDWHILE
> > CLOSE #f%
> > ENDPROC
>
> > Despite its relative slowness, I feel that PROCsave has something to
> > recommend it: namely, the fact that it is highly portable, pure BBC
> > BASIC.
>
> May I offer a quicker loop:
>
> DEF PROCsave(path$, blk%, space%)
> LOCAL f%,i%
> f% = OPENOUT(path$)
> FOR i%=0 TO space%
> BPUT#f%,blk%?i%
> NEXT i%
> CLOSE #f%
> ENDPROC
>
> It is more than 10% faster. ;-)
I'm not sure what happened to my previous posting, so I'll observe
again that your version emits one more byte than it should do (because
the upper limit of BASIC's FOR statement is inclusive).
--
Christopher Bazley
Steve Drain
Oops. Silly mistake. Sorry.
Steve
Gazza
> On 27-Dec-2009, Chris Johnson <chrisjohnson+n...@spamcop.net> wrote:
>
> > In article
> > <f7d02a2a-ecf9-4dea-abb0-09c82af5b...@m38g2000yqd.googlegroups.com>,
If you look at the code, that's exactly what I'm doing... It's just
sitting in a loop for 10+ minutes filling a 1.38MB block of RAM with
values generated by RND(255)
David Holden
On 4-Jan-2010, Gazza <use...@garethlock.com> wrote:
> On Dec 28 2009, 11:21�am, "David Holden" <Spam...@apdl.co.uk> wrote:
> >
> > Might I suggest a different approach which would be a *lot* quicker.
> >
> > 1. Find out how much free space there is on the disc.
> >
> > 2. DIM a block of memory that size.
> >
> > 3. Fill block of memory with 0's (or anything else you chose)
> >
> > 4. Save the block of data to the disc.
> >
> > Should take a few seconds.
> >
> If you look at the code, that's exactly what I'm doing... It's just
> sitting in a loop for 10+ minutes filling a 1.38MB block of RAM with
> values generated by RND(255)
I think you've missed the most important point. Why are you faffing about
generating and writing random bytes? Why not just fill the block with a
fixed value? Best would be &A5, the same as a newly formatted disc (&F6 for
a 1.44MB DOS disc). Better yet use &A5A5A5A5 words and do it in a quarter of
the time, well under a second even in Basic.
Ste (news)
<b822306f-370e-4f4c...@j19g2000yqk.googlegroups.com>,
Gazza <use...@garethlock.com> wrote:
> If you look at the code, that's exactly what I'm doing... It's just
> sitting in a loop for 10+ minutes filling a 1.38MB block of RAM with
> values generated by RND(255)
Did you not see my post <50d1504...@revi11.plus.com> ? There are
clearly at least five ways to significantly speed up your original code
(plus fix the bug of writing off the end of the buffer).
Ta,
Rob Kendrick
"Ste (news)" <st...@revi11.plus.com> wrote:
> In article
> <b822306f-370e-4f4c...@j19g2000yqk.googlegroups.com>,
> Gazza <use...@garethlock.com> wrote:
> > If you look at the code, that's exactly what I'm doing... It's just
> > sitting in a loop for 10+ minutes filling a 1.38MB block of RAM with
> > values generated by RND(255)
>
> Did you not see my post <50d1504...@revi11.plus.com> ? There are
> clearly at least five ways to significantly speed up your original
> code (plus fix the bug of writing off the end of the buffer).
Or mine, <20091228125...@trite.i.flarn.net.i.flarn.net>, where
I explain that using BBC Basic's PRNG for any security application at
all is so pointless as to not worth bothering with it; either do it
properly, or just write zeros.
B.
Gazza
> I'm saddened when hobbyist BASIC programmers pretend nothing has been
> learnt from 50 years of computer science language development and
> professional software engineering best practice. There are languages
> which are vastly superior to BASIC, even BBC BASIC, in every way.
>
> If you don't feel inclined to / capable of learning any of them, then
> carry on using BASIC and hand written assembler (the least productive
> form of programming that exists), but please don't pretend it because it
> is in anyway superior or the best solution to any task.
>
> ---druck
Maybe there are still some retro programmers out there who actually
LIKE these old-school programming techniques and prefer to use them
over development suites that do all the hard work for you. For these
people, it's the challenge of writing the program that gives them the
buzz rather than the end result. I know, for me anyway, that having an
idea, then working on that idea and seeing it come to life on the
screen, including all the errors and oopses on the way, is much more
rewarding than these point and click program creation tools you can
get. I guess they have their place in the modern slap it together
bloat-ware world, but in doing things that way, you don't learn
anything like as much about what's going on under the hood. That is
why people like me enjoy programming in "inferior" languages... It's
more of a challenge, therefore more fun!!
Richard Porter
write:
> On Dec 29 2009, 12:34�am, druck <n...@druck.org.uk> wrote:
>> I'm saddened when hobbyist BASIC programmers pretend nothing has been
>> learnt from 50 years of computer science language development and
>> professional software engineering best practice. There are languages
>> which are vastly superior to BASIC, even BBC BASIC, in every way.
I'm sure there's no pretence about it. Interpretted languages are
slow, but easy to test and debug. And despite 50 years of development
I believe there are still a lot of CoBOL programs out there!
>> If you don't feel inclined to / capable of learning any of them, then
>> carry on using BASIC and hand written assembler (the least productive
>> form of programming that exists), but please don't pretend it because
>> it is in anyway superior or the best solution to any task.
Hand-written assembler may be unproductive and difficult to maintain
unless copiously commented, but it can result in far more efficient
programs. We couldn't have done what we did on the BBC Micro without
some very lean 6502 programming.
> Maybe there are still some retro programmers out there who actually
> LIKE these old-school programming techniques and prefer to use them
> over development suites that do all the hard work for you. For these
> people, it's the challenge of writing the program that gives them the
> buzz rather than the end result. I know, for me anyway, that having an
> idea, then working on that idea and seeing it come to life on the
> screen, including all the errors and oopses on the way, is much more
> rewarding than these point and click program creation tools you can
> get. I guess they have their place in the modern slap it together
> bloat-ware world, but in doing things that way, you don't learn
> anything like as much about what's going on under the hood. That is
> why people like me enjoy programming in "inferior" languages... It's
> more of a challenge, therefore more fun!!
Well said!
I seem to remember that IBM's unofficial motto was "We also sell
memory".
--
Richard Porter
rich@ / www. richardporter.me.uk
"You can't have Windows without pains."
Rob Kendrick
Richard Porter <dontu...@address.uk.invalid> wrote:
> The date being 9 Jan 2010, Gazza <use...@garethlock.com> decided to
> write:
>
> > On Dec 29 2009, 12:34 am, druck <n...@druck.org.uk> wrote:
> >> I'm saddened when hobbyist BASIC programmers pretend nothing has
> >> been learnt from 50 years of computer science language development
> >> and professional software engineering best practice. There are
> >> languages which are vastly superior to BASIC, even BBC BASIC, in
> >> every way.
>
> I'm sure there's no pretence about it. Interpretted languages are
> slow, but easy to test and debug. And despite 50 years of development
> I believe there are still a lot of CoBOL programs out there!
Interpreted languages need not be slow, and many aren't. (Lua, which
Gavin has already mentioned, can in some circumstances beat C
compilers). And there's not as if there isn't a wealth of excellent
interpreted languages out there; many of which are better than Basic.
And COBAL programmers are almost always employed to maintain dreadful
ancient crusty legacy systems; nobody writes /new/ products in COBAL
anymore.
> >> If you don't feel inclined to / capable of learning any of them,
> >> then carry on using BASIC and hand written assembler (the least
> >> productive form of programming that exists), but please don't
> >> pretend it because it is in anyway superior or the best solution
> >> to any task.
>
> Hand-written assembler may be unproductive and difficult to maintain
> unless copiously commented, but it can result in far more efficient
> programs. We couldn't have done what we did on the BBC Micro without
> some very lean 6502 programming.
But computers today are nothing like the BBC Micro. Writing in
higher-level compiled languages can be far more productive, in terms of
time spent programming and debugging, as well as runtime. Modern CPUs
(ARMs included) are often scarily complex in terms of performance
tuning. You don't want to learn all the new rules for each new version
of a CPU, mainly because a compiler already knows them.
B.
Richard Russell
> But computers today are nothing like the BBC Micro. Writing in
> higher-level compiled languages can be far more productive, in terms of
> time spent programming and debugging, as well as runtime. Modern CPUs
> (ARMs included) are often scarily complex in terms of performance
> tuning. You don't want to learn all the new rules for each new version
> of a CPU, mainly because a compiler already knows them.
Largely true, but even today very many programs performing time-
critical operations contain *some* assembler code (maybe in a
library). It may be only a small proportion of the total, but it's
vital to achieve the best performance. After all, why else do Intel
publish their IPP (Integrated Performance Primitives) library, which
consists of "optimized [assembler] functions covering frequently-used
fundamental algorithms":
http://software.intel.com/en-us/intel-ipp/
"Intel IPP functions are designed to deliver performance beyond what
optimized compilers alone can deliver".
In the real world you cannot yet, and probably never will be able to,
use 100% high-level language for all applications.
Richard.
http://www.rtrussell.co.uk/
Rob Kendrick
Richard Russell <ne...@rtrussell.co.uk> wrote:
> On Jan 10, 12:28 am, Rob Kendrick <n...@rjek.com> wrote:
> > But computers today are nothing like the BBC Micro. Writing in
> > higher-level compiled languages can be far more productive, in
> > terms of time spent programming and debugging, as well as runtime.
> > Modern CPUs (ARMs included) are often scarily complex in terms of
> > performance tuning. You don't want to learn all the new rules for
> > each new version of a CPU, mainly because a compiler already knows
> > them.
>
> Largely true, but even today very many programs performing time-
> critical operations contain *some* assembler code (maybe in a
> library). It may be only a small proportion of the total, but it's
> vital to achieve the best performance. After all, why else do Intel
> publish their IPP (Integrated Performance Primitives) library, which
> consists of "optimized [assembler] functions covering frequently-used
> fundamental algorithms":
Sure, but these pieces of assembler are more often than not in the C
library or compiler support library. Very occationally you might find
assembly in libraries that aren't system-support ones. Under UNIX, for
example, assembler is astonishingly rare.
Unless you're writing an OS, a compiler, a C library, or some media
application that you need another 5% performance out, writing assembler
is completely unnecessary, because so few applications are CPU-bound.
B.
Richard Russell
> Sure, but these pieces of assembler are more often than not in the C
> library or compiler support library.
They will only be in a library (which somebody had to write in
assembler in the first place!) if they are a 'standard' function, such
as a video rendering or data compression algorithm. Not all speed-
critical applications will be in that category, often the requirement
will be unique to your application. In such a case are you content to
suffer the performance penalty of 100% compiled code? I'm not!
Take the specific program that I was thinking about when I started
this topic - my Colour Recovery application used to restore the Dad's
Army, Are You Being Served? and Doctor Who episodes to colour:
http://colourrecovery.wikispaces.com/Processed+programmes
That is very speed-sensitive - even using highly-optimised assembler
it takes about 50 CPU-hours to process a 30 minute TV programme! The
computations required are quite specific to the application, and off-
the-shelf library routines wouldn't be appropriate. Using a BBC BASIC
plus assembler combination I achieved probably a faster execution time
than *any* other method.
> Unless you're writing an OS, a compiler, a C library, or some media
> application that you need another 5% performance out, writing assembler
> is completely unnecessary, because so few applications are CPU-bound.
Nearly every major program I have ever written has been a "media
application" - often real-time - in which a 5% performance improvement
would be worthwhile. That's not surprising, given that I was working
for BBC R&D, but not that unusual either. Your experience may be
different.
Richard.
http://www.rtrussell.co.uk/
druck
> That is why people like me enjoy programming in "inferior" languages... It's
> more of a challenge, therefore more fun!!
I don't have any problem with that, it's your hobby and you can do
whatever you like, no matter how painful.
However it's people complaining about that they want to do something
very painful in BASIC, and when it's pointed out how easy it would be in
an alternative language, then turning around and claiming BASIC has some
mythical superiority over the other languages.
---druck
Jeremy Nicoll - news posts
> http://colourrecovery.wikispaces.com/Processed+programmes
>
> That is very speed-sensitive - even using highly-optimised assembler
> it takes about 50 CPU-hours to process a 30 minute TV programme! The
> computations required are quite specific to the application, and off-
> the-shelf library routines wouldn't be appropriate. Using a BBC BASIC
> plus assembler combination I achieved probably a faster execution time
> than *any* other method.
Any method - I'm not sure I believe that. What about using a compiled
program running on substantially faster hardware than whatever (presumably
x86 processor) you used?
--
Jeremy C B Nicoll - my opinions are my own.
Email sent to my from-address will be deleted. Instead, please reply
to newsre...@wingsandbeaks.org.uk replacing "nnn" by "284".
Rob Kendrick
Richard Russell <ne...@rtrussell.co.uk> wrote:
> On Jan 10, 11:47 am, Rob Kendrick <n...@rjek.com> wrote:
> > Sure, but these pieces of assembler are more often than not in the C
> > library or compiler support library.
>
> They will only be in a library (which somebody had to write in
> assembler in the first place!) if they are a 'standard' function, such
> as a video rendering or data compression algorithm. Not all speed-
> critical applications will be in that category, often the requirement
> will be unique to your application. In such a case are you content to
> suffer the performance penalty of 100% compiled code? I'm not!
I'm saying that the vast majority of uses, assembler serves no purpose
what so ever. Very very occasionally in user-land applications it
serves a purpose, and it's almost always hidden in a library.
Suggesting that it's fabulous to use it everywhere is just plain wrong.
> That is very speed-sensitive - even using highly-optimised assembler
> it takes about 50 CPU-hours to process a 30 minute TV programme! The
> computations required are quite specific to the application, and off-
> the-shelf library routines wouldn't be appropriate. Using a BBC BASIC
> plus assembler combination I achieved probably a faster execution time
> than *any* other method.
Without knowing what process is being done, it's impossible to know if
something like C would have been more appropriate. Certainly, if it
were written in C, vectorising, parallelising and threading the
algorithm would have been easier, as well as the code automatically
taking advantage of new instructions and other CPUs.
Interestingly, almost all high-performance software I have experience
with is written with very little or none assembler; it's amazing how
far you can get by just thinking about the problem for slightly longer.
B.
Richard Russell
<jn.nntp.scrap...@wingsandbeaks.org.uk> wrote:
> Any method - I'm not sure I believe that. What about using a compiled
> program running on substantially faster hardware than whatever (presumably
> x86 processor) you used?
Of course I meant "any other method on the same hardware"!
But, yes, I do believe it's entirely likely that the speed advantage I
gain from assembling at run time (see earlier messages in this thread)
outweighs any disadvantage from a small amount of the program (time-
wise) being executed in interpreted BASIC. Obviously I haven't
actually tried an alternative method and compared the results, so it
isn't something I can easily prove. Equally it's not something
anybody can disprove, without actually trying it.
The point I wanted to make in raising this topic is that, in certain
special (and admittedly not very typical) circumstances, using BBC
BASIC with embedded assembler can be a perfectly sensible choice when
speed is important. This is my judgement based on 30 years as a
professional programmer, with plenty of experience of other languages
like C to draw upon.
Richard.
http://www.rtrussell.co.uk/
Rob Kendrick
Richard Russell <ne...@rtrussell.co.uk> wrote:
> The point I wanted to make in raising this topic is that, in certain
> special (and admittedly not very typical) circumstances, using BBC
> BASIC with embedded assembler can be a perfectly sensible choice when
> speed is important. This is my judgement based on 30 years as a
> professional programmer, with plenty of experience of other languages
> like C to draw upon.
Perhaps for 0.05% of tasks, it might be appropriate, if it weren't for
the unmaintainability of assembler and BASIC programs :) tbh, I'd
rather wait a little longer either for my alternative language to
finish, or a faster computer to come along, than have to deal with ugly
syntax, general incompatibility with version control, and proprietary
non-portable runtime environments.
As for somebody who claims 30 years of experience in other languages
like C, I find it astonishing that you claimed you couldn't think of
another language that it was possible to do runtime-creation of
assembler!
B.
Richard Russell
> it's amazing how far you can get by just thinking about the problem for slightly longer.
Oh, absolutely, I couldn't agree more. And I did think long and hard
about the problem before deciding on algorithms, language etc.
You're also absolutely right about paralellism; the only reason it's
not important in this specific application is that I routinely run
multiple copies of the program concurrently (each working on a
different 'chunk' of the video source) which very efficiently utilises
the CPU without any programming overhead.
Richard.
http://www.rtrussell.co.uk/
Erik G
> They will only be in a library (which somebody had to write in
> assembler in the first place!) if they are a 'standard' function, such
> as a video rendering or data compression algorithm. Not all speed-
> critical applications will be in that category, often the requirement
> will be unique to your application. In such a case are you content to
> suffer the performance penalty of 100% compiled code? I'm not!
It is strange to see how the "assembler code runs faster than anything"
argument is both used against compiled code and in favour of interpreted
BASIC.
I think there is a false dichotomy here: "Either use purely compiled
code, or use BASIC with embedded assembler." All other possibilities are
excluded.
It is quite possible, and actually rather easy, to link routines written
in assembler to a program written in C.
High time somebody (maybe me) wrote an article in riscos.info on writing
APCS compatible assembly routines. Any suggestions for a title?
> Take the specific program that I was thinking about when I started
> this topic - my Colour Recovery application used to restore the Dad's
> Army, Are You Being Served? and Doctor Who episodes to colour:
>
> http://colourrecovery.wikispaces.com/Processed+programmes
>
> That is very speed-sensitive - even using highly-optimised assembler
> it takes about 50 CPU-hours to process a 30 minute TV programme! The
> computations required are quite specific to the application, and off-
> the-shelf library routines wouldn't be appropriate. Using a BBC BASIC
> plus assembler combination I achieved probably a faster execution time
> than *any* other method.
But you can't be sure, because you haven't tried another solution, let
alone measured the differences. Your statement effectively says: "I
think BBC BASIC plus assembler is the fastest solution for programs with
a lot of data processing. I have this big-ass program that does a lot of
data processing. I used BBC BASIC plus assembler for it. I think that
was the fastest solution". This does not prove anything. It merely
states your opinion in a different way. (Note: I do agree that using
library assembly routines is not very helpful for the bulk of the
required work in this example.)
Having said that, your program is a good example of a problem that needs
a solution that runs as fast as possible. It is worthwhile to spend a
lot of time to create a fast program and optimising it. It may even be
worth-while to select/buy a suitable platform to run it on.
The time-honoured way to do this is roughly as follows:
- A) design the program, keeping an eye on the need for speed. Select
fast algorithms. Extra memory space can be used if it saves on
execution time.
- B) Write the program in a suitable high-level language. C is very
popular for data processing. Some advocates favour FORTRAN (see "Real
Programmers don't eat Quiche". Today's teraflop supercomputers are
still being programmed in FORTRAN, and today's FORTRAN has come a
long way since F4.)
- C) Measure the performance, preferably using a profiler. Find out
which parts of the program use up most of the execution time, on a
line-by-line basis.
- D) See if the algorithm can be improved, or a different algorithm can
be used to speed up the parts that use the most time. This is often
the most effective way to get a faster program.
- E) Optimise the bejeezes out of the parts that use the most time,
usually the central loops in a series of nested loops. Use the usual
tricks like strength reduction, sentinels, expelling invariant code,
loop unrolling, etc. The profiler is your friend here. A good compiler
will usually do these things for you, but you never know. Inspect the
assembly produced to make sure.
- F) If all else fails, isolate the part (or parts) of the program that
use the most execution time into a routine, and replace that routine
with an assembler version. You can use the assembly output of the
compiler for the original as a basis for your assembly version.
Optimise, and check the effect of your changes with the profiler.
- G) There is often gain to be had from tuning the program to the
hardware. Use knowledge of the size of the cache. Order instructions
for best use of the cycles between memory fetches. Use the FPU
coprocessor to move blocks in memory while the CPU does some
computing. Etc. Though a good compiler will use many of these tricks,
some things can only be done by hand in assembler. Beware though, it
is easy to overlook some effect and actually make the program slower
by a change intended to make it go faster.
Key points in this process:
- Use a profiler to actually *measure* the performance of each part of
the program, and to find out where optimisation would be most
effective. As far as I know, a profiler is not available for BBC
BASIC.
- Use a variety of other methods to optimise performance before
resorting to writing in assembler.
Final notes:
For a program that runs for 50 hours, it is worthwhile to invest in the
latest hardware, especially if you need more than one run. For video
processing it is probably useful to consider special hardware (such as
a PC video card) to do much of the work.
High time to introduce my Law of Computing Pointlessness:
"Assuming computing speed (due to improvements in hardware) doubles
over a time T (often given as 18 months), then there is no point in
starting a program now that is expected to require a time of 2T or more
to run on today's best hardware. It is better to spend at least a time T
working on other problems and then invest in hardware that is twice as
fast." (parts in parentheses are not part of the law.)
A program that requires 2T now will only require T after waiting T,
also completing after 2T from now. You can do other stuff while waiting.
For programs that run even longer, the waiting time can be extended. I
leave it to the reader to work out how long you can wait before
completion will take longer than starting right now.
--
Erik G http://www.xs4all.nl/~erikgrnh
== 'From:' address is a spam trap. Do not use
== See web site for email address
Peter Naulls
> As Richard Russell wrote on 10 Jan 2010:
>
>> They will only be in a library (which somebody had to write in
>> assembler in the first place!) if they are a 'standard' function, such
>> as a video rendering or data compression algorithm. Not all speed-
>> critical applications will be in that category, often the requirement
>> will be unique to your application. In such a case are you content to
>> suffer the performance penalty of 100% compiled code? I'm not!
>
> It is strange to see how the "assembler code runs faster than anything"
> argument is both used against compiled code and in favour of interpreted
> BASIC.
>
> I think there is a false dichotomy here: "Either use purely compiled
> code, or use BASIC with embedded assembler." All other possibilities are
> excluded.
>
> It is quite possible, and actually rather easy, to link routines written
> in assembler to a program written in C.
UnixLib does this, for speed-critical stuff like memory operations.
This is pretty typical. It's also been rather unfortunately, had a
rather higher proportion of bugs than the C (IME). Read into this what
you will.
> High time somebody (maybe me) wrote an article in riscos.info on writing
> APCS compatible assembly routines. Any suggestions for a title?
"ACPS compatibility". If the topic proves to be something else, we'll
just rename it. Anyway, such an article would be greatly appreciated.
Jeremy Nicoll - news posts
> You're also absolutely right about paralellism; the only reason it's
> not important in this specific application
I don't follow; I had the impression you were talking about a speed-critical
app.
> is that I routinely run multiple copies of the program concurrently (each
> working on a different 'chunk' of the video source) which very efficiently
> utilises the CPU without any programming overhead.
Excuse me, "the CPU" implies just one of them. What happened to the idea of
using parallelism and splitting the work over multiple CPUs?
And what about using CPUs with hardware vector processing capabilities? I
mean, I don't somehow think the Met Office, or people studying nuclear bomb
explosions etc (for example) use BBC BASIC with or without assembler for
their number-crunching.
What made you choose x86 as the target architecture in the first place?
Richard Russell
> I think there is a false dichotomy here: "Either use purely compiled
> code, or use BASIC with embedded assembler." All other possibilities are
> excluded.
By whom? The comparison I initially highlighted was between assembler
code in a BBC BASIC wrapper and assembler code in (for example) a C
wrapper, and why the BBC BASIC solution can run more quickly. "Purely
compiled code" isn't relevant to that issue, and wasn't mentioned (by
me).
> It is quite possible, and actually rather easy, to link routines written
> in assembler to a program written in C.
I rather think you've missed the point, given that this is the
reference against which I was comparing the BBC BASIC assembler
solution. It's not relevant whether the assembler code is embedded in
a C source file or a separate ASM file, since they are both assembled
(and linked) at 'compile time'.
> This does not prove anything. It merely states your opinion in a different way.
My "opinion" is based on an incontrovertible fact, that code assembled
at run-time can run faster than code assembled at compile-time (all
other things being equal, and excluding the possibility of self-
modifying code or run-time patching of code). The unquantifiable
component is whether or not that factor outweighs the relative
slowness of interpreted BASIC compared to (say) compiled C for the
part of the program *not* written in assembler.
[snipped useful tips on how to optimise performance]
> - Use a profiler to actually *measure* the performance of each part of
> the program, and to find out where optimisation would be most
> effective. As far as I know, a profiler is not available for BBC
> BASIC.
Erm, I profile all my speed-critical BBC BASIC programs, and I have
profiled this particular application more than once. I either use
the profiler utility supplied with BBC BASIC for Windows
(PROFILER.BBC) or, more commonly these days, Michael Hutton's Profiler
add-in:
http://bb4w.wikispaces.com/Tools+and+Utilities
> For a program that runs for 50 hours, it is worthwhile to invest in the
> latest hardware, especially if you need more than one run.
I tend to run the program simultaneously on two fairly fast PCs,
usually overnight. Since I don't get paid for the work, I'm not sure
I would consider purchasing new hardware an "investment"!
Richard.
http://www.rtrussell.co.uk/
Richard Russell
"The CPU" may have four cores (or there may be multiple CPUs),
> What happened to the idea of
> using parallelism and splitting the work over multiple CPUs?
I run at least twice the number of instances of the application as
there are cores, that way Windows quite efficiently makes use of all
the available CPU resources without any need for me to consider
parallelism explicitly in my coding.
When it's necessary for a *single instance* of a program to run as
quickly as possible, then certainly you need to write it in such a way
that it will make efficient use of the available resources, and that
can be far from easy (and BBC BASIC is not a suitable language!).
> What made you choose x86 as the target architecture in the first place?
It's ubiquitous, it outperforms any other inexpensive computing
platform and I have it available here in quantity! I also have many
years experience in programming it in assembler code.
Richard.
http://www.rtrussell.co.uk/
Peter Naulls
> It's ubiquitous, it outperforms any other inexpensive computing
> platform and I have it available here in quantity! I also have many
> years experience in programming it in assembler code.
And largely irrelevant to RISC OS. Do you think we can stay on
topic?
Rob Kendrick
Richard Russell <ne...@rtrussell.co.uk> wrote:
> > It is quite possible, and actually rather easy, to link routines
> > written in assembler to a program written in C.
>
> I rather think you've missed the point, given that this is the
> reference against which I was comparing the BBC BASIC assembler
> solution. It's not relevant whether the assembler code is embedded in
> a C source file or a separate ASM file, since they are both assembled
> (and linked) at 'compile time'.
This is one way C can use assembler. And only one way. You seem to
keep putting BBC Basic forward as the only language that can produce
assembler at runtime. This is clearly bogus, as anybody who has
written a JIT will tell you.
B.
Richard Russell
> This is one way C can use assembler. And only one way. You seem to
> keep putting BBC Basic forward as the only language that can produce
> assembler at runtime. This is clearly bogus, as anybody who has
> written a JIT will tell you.
You're confusing 'assembler code' (which in this context means code in
source mnemonic form) with 'machine code' (i.e. the binary
instructions that the CPU executes). Of course there are plenty of
systems that generate machine code 'on the fly' at run time, of which
a JITter is one, but I've never encountered another one that does so
by first generating mnemonic source code and then running that through
an assembler.
BBC BASIC is (as far as I'm aware) unique in incorporating an
assembler in every executable. That makes it possible to write code
which varies from one run to the next without any extra effort.
Contrast that with the alternative, which is - by some means or other
- to create or modify code at run time without the aid of an
assembler. Possible, of course, but messy, risky and difficult to
debug.
A good example is when you don't even know the address at which the
machine code will need to live until run-time. That is the case (in
Windows, at least) if you're injecting code into a remote process.
Doing it 'conventionally' means you have to relocate the code to the
required address at run-time; I've even seen that done by using C code
to scan the binary image, detect embedded addresses and modify them.
Ugh!
Using the BBC BASIC assembler it's trivial; not knowing the start
address until run time makes no difference at all.
Richard.
http://www.rtrussell.co.uk/
Rob Kendrick
Richard Russell <ne...@rtrussell.co.uk> wrote:
> You're confusing 'assembler code' (which in this context means code in
> source mnemonic form) with 'machine code' (i.e. the binary
> instructions that the CPU executes). Of course there are plenty of
> systems that generate machine code 'on the fly' at run time, of which
> a JITter is one, but I've never encountered another one that does so
> by first generating mnemonic source code and then running that through
> an assembler.
Why would you need an assembler when you can eradicate this step? You
simply use functions or macros that resemble opcodes and generate the
required code. This approach has a plethora of advantages.
B.
Rob Kendrick
Sorry, I meant to paste this in this message:
Here's an example of DynASM, which is used in LuaJIT (which produces
some mind-bogglingly fast code). It acts as a pre-processor that sits
neatly into any sane build system. You'll notice direct use of C
structures and values, looping, constants, and such.
static void jit_inline_coroutine(jit_State *J, jit_InlineInfo *ii)
{
int arg = ii->func+1;
int res = ii->res;
int i;
switch (JIT_IH_IDX(ii->hidx)) {
case JIT_IH_COROUTINE_YIELD:
| cmp aword [L+((int)&LHASCOCO((lua_State *)0))], 0 // Got a C stack?
| je L_DEOPTIMIZE
| mov L->savedpc, &J->nextins // Debugger-friendly.
| add BASE, arg*#TVALUE
if (ii->nargs >= 0) { /* Previous op was not open and did not set TOP. */
| lea TOP, BASE[ii->nargs]
}
| mov L->base, BASE
| mov L->top, TOP
| call &luaCOCO_yield, L
| mov BASE, L->base
| mov TOP, L->top
jit_assert(ii->nresults >= 0 && ii->nresults <= EXTRA_STACK);
for (i = 0; i < ii->nresults; i++) {
| setnilvalue TOP[i] // Clear undefined result.
| copyslot BASE[res+i], BASE[arg+i] // Move result down.
}
ii->nargs = -1; /* Force restore of L->top. */
break;
case JIT_IH_COROUTINE_RESUME:
jit_assert(ii->nargs != 0 && ii->res == ii->func);
| add BASE, (arg+1)*#TVALUE
if (ii->nargs >= 0) { /* Previous op was not open and did not set TOP. */
| lea TOP, BASE[ii->nargs-1]
} else {
| cmp TOP, BASE; jb L_DEOPTIMIZE // No thread arg? Deoptimize.
}
| istt -1, LUA_TTHREAD; jne L_DEOPTIMIZE // Wrong type? Deoptimize.
| mov L:eax, BASE[-1].value
| cmp aword [L:eax+((int)&LHASCOCO((lua_State *)0))], 0
| je L_DEOPTIMIZE // No C stack? Deoptimize.
| mov L->savedpc, &J->nextins // Debugger-friendly.
| mov L->top, TOP
| call &jit_coroutine_resume, L, BASE, ii->nresults
| mov BASE, L->base
if (ii->nresults == -1) {
| mov TOP, eax
}
ii->nargs = -1; /* Force restore of L->top. */
break;
default:
jit_assert(0);
break;
}
}
Gazza
The other thing that I said, and I stand by it, is that RAD tools
quickly produce fancy programs for the programmers, but if you ask
those same programmers how to write a piece of code that say converts
a string of characters from uppercase to lowercase, or visa-versa.
Chances are, they'll just tell you that they use the built-in function
for the language. However, hardcore old-school programmers have to
know about the ins and outs of the ASCII set to do this kind of thing.
It's little things like that that give you the knowledge of the
insides of the machine.
How many people could do now, what David Braben did with Elite for
example. I mean by using just raw asm for the coding. I know it's not
exactly necessary what with the multi-megabytes of memory and disk
space we have at our disposal with the modern hardware. But it's
skills like that that get lost with these point and click RAD tools.
Skills that can produce programs that are fully contained (on Windoze)
and are a matter of kilobytes in size. Now that is what I call
programming!
Matthew Phillips
on 11 Jan 2010 Gazza wrote:
> On Jan 10, 2:33�pm, druck <n...@druck.org.uk> wrote:
> > Gazza wrote:
> > > That is why people like me enjoy programming in "inferior" languages... It's
> > > more of a challenge, therefore more fun!!
> >
> > I don't have any problem with that, it's your hobby and you can do
> > whatever you like, no matter how painful.
> >
> > However it's people complaining about that they want to do something
> > very painful in BASIC, and when it's pointed out how easy it would be in
> > an alternative language, then turning around and claiming BASIC has some
> > mythical superiority over the other languages.
>
> The other thing that I said, and I stand by it, is that RAD tools
> quickly produce fancy programs for the programmers, but if you ask
> those same programmers how to write a piece of code that say converts
> a string of characters from uppercase to lowercase, or visa-versa.
> Chances are, they'll just tell you that they use the built-in function
> for the language. However, hardcore old-school programmers have to
> know about the ins and outs of the ASCII set to do this kind of thing.
> It's little things like that that give you the knowledge of the
> insides of the machine.
And sadly some of the old-school programmers fail to update their knowledge
when something like Unicode comes along, where you really don't want to be
implementing it yourself.
If you want a reminder of why people use built-in functions, read this
fictitious account of a programming job interview:
http://exold.com/article/stupid-interview-questions
> How many people could do now, what David Braben did with Elite for example.
> I mean by using just raw asm for the coding. I know it's not exactly
> necessary what with the multi-megabytes of memory and disk space we have at
> our disposal with the modern hardware. But it's skills like that that get
> lost with these point and click RAD tools. Skills that can produce programs
> that are fully contained (on Windoze) and are a matter of kilobytes in
> size. Now that is what I call programming!
Yes, that kind of feat is immensely impressive. But it can always be
trumped: my old boss used to regale me with tales of sorting a database of a
million records stored on punched cards using a computer with only 1K of
memory. Very impressive, but in the end our amazement was not so much at
what could be achieved with limited resources, but that anyone made the
effort against such tremendous obstacles in the first place.
Of course, if it's challenge you are after, and you really dislike the idea
of debuggers and integrated developments environmemts, that's no reason to
disdain the use of C on RISC OS -- we don't have them. So you can recapture
the feel of the heroic age of computing with little trouble.
--
Matthew Phillips
Dundee
Richard Russell
> Why would you need an assembler when you can eradicate this step?
Most assembler programmers prefer to program in conventional source
code, with the convenience of two-pass assembly, listing output etc.;
I know I do. Using a relatively standard syntax is especially
important when you want to incorporate code modules from elsewhere.
Some kind of unfamiliar macro language that performs a similar role
doesn't really cut the mustard, especially when the advantages of run-
time code generation are relatively minor. The point of the BBC BASIC
assembler is that you get the assembly-at-run-time feature, with the
advantages it provides, for no extra effort!
It seems to upset you that BBC BASIC has a unique characteristic that
can be advantageous to the assembler programmer. One might naively
expect that the 'Acorn community', who are predominantly represented
on this newsgroup, might be more likely than most to celebrate the
achievements of Acorn, including BBC BASIC, and be proud that it has
some small relevance even today. Yet, perversely, there seems to be a
small group of individuals here who are determined to make out that
BBC BASIC is useless. We live in a topsy-turvy world.
Richard.
http://www.rtrussell.co.uk/
Rob Kendrick
Richard Russell <ne...@rtrussell.co.uk> wrote:
> On Jan 11, 1:03 am, Rob Kendrick <n...@rjek.com> wrote:
> > Why would you need an assembler when you can eradicate this step?
>
> Most assembler programmers prefer to program in conventional source
> code, with the convenience of two-pass assembly,
Yes, and all of this can be achieved with the process I described.
> It seems to upset you that BBC BASIC has a unique characteristic that
> can be advantageous to the assembler programmer.
No, it upsets me that you peddle it as unique. Or even useful for more
than 0.05% of tasks.
B.
Richard Russell
> No, it upsets me that you peddle it as unique.
I've never come across any other programming language which
incorporates a full, standard Intel-syntax IA-32 assembler in *every*
executable (even when the BASIC program doesn't itself include any
assembler source code - it might load it from a file at run time!).
I'm pretty confident that in that respect it is unique, by quite a
wide margin.
And what's so upsetting about it being unique anyway? I'm sure there
are many other ways in which BBC BASIC is unique, in fact probably
every programming language is unique in some way or other. Uniqueness
is good, it makes life more interesting!
Richard.
http://www.rtrussell.co.uk/
Rob Kendrick
Richard Russell <ne...@rtrussell.co.uk> wrote:
> On Jan 11, 9:47 am, Rob Kendrick <n...@rjek.com> wrote:
> > No, it upsets me that you peddle it as unique.
>
> I've never come across any other programming language which
> incorporates a full, standard Intel-syntax IA-32 assembler in *every*
> executable (even when the BASIC program doesn't itself include any
> assembler source code - it might load it from a file at run time!).
> I'm pretty confident that in that respect it is unique, by quite a
> wide margin.
Woah, way to move the goalposts. Sure, every time I find a counter
example of your bogus claims, you add more specialisation to try to
prove yourself right.
(And you're still not.)
> And what's so upsetting about it being unique anyway? I'm sure there
> are many other ways in which BBC BASIC is unique, in fact probably
> every programming language is unique in some way or other. Uniqueness
> is good, it makes life more interesting!
Nothing's wrong with being unique, but pushing something as having
unique functionality when it does not is something else.
B.
Steve Fryatt
<742b798d-7a69-47c3...@e37g2000yqn.googlegroups.com>:
> The other thing that I said, and I stand by it, is that RAD tools quickly
> produce fancy programs for the programmers, but if you ask those same
> programmers how to write a piece of code that say converts a string of
> characters from uppercase to lowercase, or visa-versa. Chances are,
> they'll just tell you that they use the built-in function for the
> language. However, hardcore old-school programmers have to know about the
> ins and outs of the ASCII set to do this kind of thing. It's little things
> like that that give you the knowledge of the insides of the machine.
What code would you use to convert lower case to upper case on a RISC OS
machine, then? It's not as simple as you think, even if you ignore Unicode
on RISC OS 5; that's why the Territory module offers SWIs to do (most of)
the work for you.
--
Steve Fryatt - Leeds, England
Richard Russell
> Woah, way to move the goalposts. Sure, every time I find a counter
> example of your bogus claims, you add more specialisation to try to
> prove yourself right.
Not at all. Central to my argument all along has been that BBC BASIC
(as a feature of the language) incorporates an assembler in its
executables.
> Nothing's wrong with being unique, but pushing something as having
> unique functionality when it does not is something else.
I would agree entirely. But BBC BASIC *does* have unique
functionality (note: that doesn't mean it can do something that cannot
be done in any other way, that's not what "unique functionality"
means). I will continue to point that out whenever it's relevant.
Richard.
http://www.rtrussell.co.uk/
Rob Kendrick
Richard Russell <ne...@rtrussell.co.uk> wrote:
> On Jan 11, 10:20 am, Rob Kendrick <n...@rjek.com> wrote:
> > Woah, way to move the goalposts. Sure, every time I find a counter
> > example of your bogus claims, you add more specialisation to try to
> > prove yourself right.
>
> Not at all. Central to my argument all along has been that BBC BASIC
> (as a feature of the language) incorporates an assembler in its
> executables.
So, we've added "as a feature of the language" as a goalpost, when
before it was simply that you could generate assembler with differing
constants and such at runtime.
> > Nothing's wrong with being unique, but pushing something as having
> > unique functionality when it does not is something else.
>
> I would agree entirely. But BBC BASIC *does* have unique
> functionality (note: that doesn't mean it can do something that cannot
> be done in any other way, that's not what "unique functionality"
> means). I will continue to point that out whenever it's relevant.
I boggle.
B.
Richard Russell
> So, we've added "as a feature of the language" as a goalpost
We were talking about BBC BASIC and its uniqueness. Did you not know
that the assembler is a feature of the language? :-)
> I boggle.
For those with impaired understanding of English, "functionality"
refers to *how* something is achieved just as much as to *what* can be
achieved.
I feel rather like the beleagured scientist here:
http://www.youtube.com/watch?v=IBHEsEshhLs
Richard.
http://www.rtrussell.co.uk/
Christopher Bazley
ups.com>
Richard Russell <ne...@rtrussell.co.uk> wrote:
> It seems to upset you that BBC BASIC has a unique characteristic that
> can be advantageous to the assembler programmer. One might naively
> expect that the 'Acorn community', who are predominantly represented
> on this newsgroup, might be more likely than most to celebrate the
> achievements of Acorn, including BBC BASIC, and be proud that it has
> some small relevance even today. Yet, perversely, there seems to be a
> small group of individuals here who are determined to make out that
> BBC BASIC is useless. We live in a topsy-turvy world.
There are two problems as I see it.
One is timeliness. You wouldn't expect a veteran of the battle of
Britain to advocate the use of the Hawker Hurricane by the modern-day
R.A.F. The fact that he would not do so does not reflect a lack of
pride in the R.A.F. or understanding of the historical importance of
that aircraft.
Secondly, given that Acorn never (to the best of my knowledge)
published a version of BBC BASIC that incorporated an Intel-syntax
IA-32 assembler, it seems perverse to celebrate it as one of their
achievements. I could be wrong about this - perhaps for the ABC?
Advocates of computing platforms tend to endorse software written
specifically for that architecture (e.g. in ARM assembly language for
the Archimedes), and anything that can be ported to it. On the other
hand, non-portable software for rival platforms is 'bad'. Expecting
Acorn users (even ex-Acorn users) to rejoice in your promotion of x86
assembly language is a bit much.
--
Chris Bazley
Star Fighter 3000: http://starfighter.acornarcade.com/
Richard Russell
<christopher.baz...@blueyonder.co.uk> wrote:
> Secondly, given that Acorn never (to the best of my knowledge)
> published a version of BBC BASIC that incorporated an Intel-syntax
> IA-32 assembler
Did they not make available BBC BASIC (86) for the 80186 Second
Processor? Certainly my BBC BASIC (Z80) was published by Acorn for
the Z80 Second Processor (I've got the Acorn user guide in front of
me, part no. 409003).
> Expecting Acorn users (even ex-Acorn users) to rejoice in your promotion of x86
> assembly language is a bit much.
What we've been discussing isn't specific to the x86. The advantages
of 'run-time assembly' over 'compile-time assembly' are relevant to
the ARM / RISC OS platform too. Obviously I know more about the
Windows platform, so I'm bound to refer to that in specific examples.
In any case, don't many 'Acorn users' run Virtual Acorn or VRPC on a
Windows PC? If so, I would have expected that they might well be
interested in BBC BASIC for Windows.
Richard.
http://www.rtrussell.co.uk/
David Holden
On 11-Jan-2010, Richard Russell <ne...@rtrussell.co.uk> wrote:
> Did they not make available BBC BASIC (86) for the 80186 Second
> Processor? Certainly my BBC BASIC (Z80) was published by Acorn for
> the Z80 Second Processor (I've got the Acorn user guide in front of
> me, part no. 409003).
Also the Z88 had BBC Basic with (I think) a Z80 assembler.
--
David Holden - APDL - <http://www.apdl.co.uk>
Rob Kendrick
"David Holden" <Spa...@apdl.co.uk> wrote:
> On 11-Jan-2010, Richard Russell <ne...@rtrussell.co.uk> wrote:
>
> > Did they not make available BBC BASIC (86) for the 80186 Second
> > Processor? Certainly my BBC BASIC (Z80) was published by Acorn for
> > the Z80 Second Processor (I've got the Acorn user guide in front of
> > me, part no. 409003).
>
> Also the Z88 had BBC Basic with (I think) a Z80 assembler.
Wasn't this also written by Richard, or is my memory failing me?
B.
Jeremy Nicoll - news posts
> On Jan 11, 1:03�am, Rob Kendrick <n...@rjek.com> wrote:
> > Why would you need an assembler when you can eradicate this step?
>
> Most assembler programmers prefer ....
Oh-oh, here comes another sweeping generalisation...
> to program in conventional source code, with the convenience of two-pass
> assembly, listing output etc.; I know I do.
What about just using a decent assembler? That'll do as many passes as
required (two isn't necessarily enough), listings, cross-references etc to
your heart's content...
> Some kind of unfamiliar macro language that performs a similar role
> doesn't really cut the mustard,
Maybe not. So why not use a familiar macro language that's well understood,
especially if for example every OS service call (ie SWI) has a documented
macro for generating correct format calls for its use in either re-entrant
or no-renetrant code and so on, and almost every internal table used in the
OS and most major apps and many small ones has its data layout defined in
terms the macros and assembler can use?
> The point of the BBC BASIC assembler is that you get the
> assembly-at-run-time feature, with the advantages it provides, for no
> extra effort!
Hooray for that. But I'm not sure that all commercial installations would
allow that; the idea of code that changes at run-time is potentially a
security nightmare.
> It seems to upset you that BBC BASIC has a unique characteristic that
> can be advantageous to the assembler programmer.
I don't think the idea of that upsets people; the problem is no-one here
thinks what you claim as unique actually is. And when you claim that the
'unique' feature makes BB4W immensely powerful people wonder why you'd not
use a more powerful feature in something else instead.
Peter Naulls
> In any case, don't many 'Acorn users' run Virtual Acorn or VRPC on a
> Windows PC? If so, I would have expected that they might well be
> interested in BBC BASIC for Windows.
Enough already. They demonstrably aren't by not posting here.
Perhaps they might in future, but for the moment, your monthly
advocacy about BASIC on Windows and x86 is the same old stuff,
ending up with lots of pointless arguments about a language
people often shouldn't be using on a platform they often don't
want to use.
*If* they were genuinely people wanting to use BB4W, then
they might be tolerated, or even encouraged, but these
endless remonstrations are making it hard to deal with
people with genuine *RISC OS* programming problems in
any language.
If you want to debate x86 vs ARM or whatever, or the
value of certain languages then fine - but take it
to advocacy. Then people can go crazy and show how little
evidence you have for your claims.
In the meantime, some of us are trying to help users with
more immediate problems.
Alan Wrigley
> In any case, don't many 'Acorn users' run Virtual Acorn or VRPC on a
> Windows PC? If so, I would have expected that they might well be
> interested in BBC BASIC for Windows.
My gut feeling is that most people interested in programming are enthusiasts
using native hardware, whereas most users of VA are consumers not producers.
ICBW.
Alan
--
RISC OS - you know it makes cents
Richard Russell
<jn.nntp.scrap...@wingsandbeaks.org.uk> wrote:
> What about just using a decent assembler? That'll do as many passes as
> required (two isn't necessarily enough)
The BBC BASIC assembler will do as many passes as you like (have you
actually ever used it?).
> But I'm not sure that all commercial installations would
> allow that; the idea of code that changes at run-time is potentially a
> security nightmare.
The BBC BASIC approach and the alternatives suggested by Rob (e.g. a
JIT) *all* necessarily make changes to (or create) code at run-time.
The issue is whether the changes/creation are done using an assembler
or another method such as indirection. If you're not allowed to
change/create code at run-time, the discussion is moot (and how are
you then supposed to do things like relocate code so you can inject it
into another process?).
> And when you claim that the
> 'unique' feature makes BB4W immensely powerful people wonder why you'd not
> use a more powerful feature in something else instead.
Please don't put words into my mouth. I've never claimed that it
makes BB4W "immensely powerful"; that's a figment of your
imagination. The most I've claimed is that it can result in a small
increase of the execution speed of assembler code, not just in BBC
BASIC for Windows but all versions of BBC BASIC.
The discussion in this thread has never been *anything at all* to do
with BASIC versus (say) C, or interpreters versus compilers, or
Windows versus RISC OS, or one version of BBC BASIC versus another.
It's been about assembling code at run-time rather than assembling
code at compile-time, and the advantages that can bring, which is an
interesting (to me) and little-discussed subject. It shouldn't even
be contentious.
Some people here seem incapable of holding a sensible, calm technical
debate. Instead they try to turn it into a full-blown argument, by
introducing red-herrings in an attempt to wind people up. I'm not
surprised, because this is a comp.sys.acorn group, but I'm
disappointed that it always seems to happen.
Richard.
http://www.rtrussell.co.uk/
Rob Kendrick
Alan Wrigley <spam...@keepyourfilthyspamtoyourself.co.uk> wrote:
> Richard Russell <ne...@rtrussell.co.uk> wrote:
>
> > In any case, don't many 'Acorn users' run Virtual Acorn or VRPC on a
> > Windows PC? If so, I would have expected that they might well be
> > interested in BBC BASIC for Windows.
>
> My gut feeling is that most people interested in programming are
> enthusiasts using native hardware, whereas most users of VA are
> consumers not producers.
>
> ICBW.
I don't think you are. For a long time, much of our RISC OS software
was compiled in VRPC (or it might have been VA5000, I don't recall)
running on a Windows box, as it was so much faster and easier.
Eventually, we just ended up cross-compiling instead, as it's so much
easier and quicker. I suspect many developers are the same, or at
least would be if they hadn't left.
B.
Richard Russell
> Perhaps they might in future, but for the moment, your monthly
> advocacy about BASIC on Windows and x86 is the same old stuff,
Absolutely classic that you should think I'm advocating BB4W or x86,
when the point I've been making in this thread is completely platform
neutral (at least, excluding Brandy which doesn't have an assembler).
Richard.
http://www.rtrussell.co.uk/
Rob Kendrick
Richard Russell <ne...@rtrussell.co.uk> wrote:
> On Jan 11, 4:02 pm, Jeremy Nicoll - news posts
> <jn.nntp.scrap...@wingsandbeaks.org.uk> wrote:
> > What about just using a decent assembler? That'll do as many
> > passes as required (two isn't necessarily enough)
>
> The BBC BASIC assembler will do as many passes as you like (have you
> actually ever used it?).
I'm worried that either you don't know the type of assembler that
Jeremy is referring to, or you're deliberately misunderstanding him.
As an example, for others, our own CPU design's assembler is heavily
macro-based. It will iteratively assemble sources, as many of the
instructions are macros for a chain of instructions. (This is because
it's a microcontroller, the choice of instructions is limited, so
macros provide the appearance of a richer instruction set.)
Unfortunately, these macros can be variable length. The assembler does
as many passes as required to make sure the shorted encoding is used
everywhere. Doing similar with BBC BASIC's assembler is... tiresome.
> > And when you claim that the
> > 'unique' feature makes BB4W immensely powerful people wonder why
> > you'd not use a more powerful feature in something else instead.
>
> Please don't put words into my mouth. I've never claimed that it
> makes BB4W "immensely powerful"; that's a figment of your
> imagination.
You allude to it:
"BBC BASIC has its strengths, and it has its weaknesses. You're
entitled to draw attention to its weaknesses, but don't knock the fact
that it is has a unique and valuable characteristic which means it is
particularly well suited when the very fastest performance is
desirable."
"Using a BBC BASIC plus assembler combination I achieved probably a
faster execution time than *any* other method."
> The discussion in this thread has never been *anything at all* to do
> with BASIC versus (say) C, or interpreters versus compilers, or
> Windows versus RISC OS, or one version of BBC BASIC versus another.
> It's been about assembling code at run-time rather than assembling
> code at compile-time, and the advantages that can bring, which is an
> interesting (to me) and little-discussed subject. It shouldn't even
> be contentious.
Indeed not. But what is contentious is your constant parroting that
it's somehow unique, or provides advantages that aren't available
elsewhere.
B.
Peter Naulls
(notice how much of my post you snipped)
The fallacy of your post is so obvious I won't even point it out, but
please don't continue to make excuses to clutter up this group with your
endless posts which have no value to people trying to solve genuine
RISC OS problems. Follow ups set, for whatever value that has.
Jeremy Nicoll - news posts
> On Jan 11, 4:02�pm, Jeremy Nicoll - news posts
> <jn.nntp.scrap...@wingsandbeaks.org.uk> wrote:
> > What about just using a decent assembler? �That'll do as many passes as
> > required (two isn't necessarily enough)
>
> The BBC BASIC assembler will do as many passes as you like (have you
> actually ever used it?).
No; I know nothing about the relevant instruction set. I just thought you'd
highlighted the two pass aspect, so I was commenting in it.
In BASIC under RISC OS I've used the assembler in the sense that I've run
programs that used it, but I've not written any.
I've read a couple of ARM assembler textbooks several times [for interest in
the architecture and instruction set only; similarly awhile ago I read
Knuth's MMIXware textbook - and indeed found errors in it and got the
standard $2.56 cheque from him for that which pleased me a lot!], but always
forgotten the stuff again as I had no use for it.
> > But I'm not sure that all commercial installations would
> > allow that; the idea of code that changes at run-time is potentially a
> > security nightmare.
>
> The BBC BASIC approach and the alternatives suggested by Rob (e.g. a
> JIT) *all* necessarily make changes to (or create) code at run-time.
Yes I realise that. It's just that features like that are not necessarily
useable in real life.
> If you're not allowed to change/create code at run-time, the discussion is
> moot (and how are you then supposed to do things like relocate code so you
> can inject it into another process?).
In the architecture I have written assembler for, provided you wrote your
code in a re-entrant, relocatable, reusable fashion (which was obligatory
for OS changes anyway so I never learned not to), I never saw any use that
involved 'injecting' it elsewhere.
However if it had been possible to bypass address-space separation, perhaps
by putting the code in shared memory somewhere, or one wanted to hook some
existing code running in your own address space, there'd be no need to
fiddle with it to make it work in the new location. It would already work
wherever you put it.
That's IBM S/390 by the way.
> > And when you claim that the 'unique' feature makes BB4W immensely
> > powerful people wonder why you'd not use a more powerful feature in
> > something else instead.
>
> Please don't put words into my mouth. I've never claimed that it
> makes BB4W "immensely powerful"; that's a figment of your
> imagination. The most I've claimed is that it can result in a small
> increase of the execution speed of assembler code, not just in BBC
> BASIC for Windows but all versions of BBC BASIC.
OK.
> The discussion in this thread has never been *anything at all* to do
> with BASIC versus (say) C,
Well when you said
"When I want the very fastest possible performance from an
application, I use BBC BASIC with the time-critical parts
in assembler code."
I don't think it's unreasonable that people discuss whether your choice of
BBC BASIC was appropriate to your own requirement.
If what you're saying is that there was no choice, then the conditional part
of your statement doesn't make much sense.
druck
> My "opinion" is based on an incontrovertible fact, that code assembled
> at run-time can run faster than code assembled at compile-time (all
> other things being equal, and excluding the possibility of self-
> modifying code or run-time patching of code).
You really can't be serious? Humour us by explaining that.
> The unquantifiable
> component is whether or not that factor outweighs the relative
> slowness of interpreted BASIC compared to (say) compiled C for the
> part of the program *not* written in assembler.
Whatever that is actually supposed to mean, if you can't quantify it, it
isn't true.
---druck
Dave Higton
<c3eae521-0399-47cb...@l30g2000yqb.googlegroups.com>
Richard Russell <ne...@rtrussell.co.uk> wrote:
> It seems to upset you that BBC BASIC has a unique characteristic that
> can be advantageous to the assembler programmer. One might naively
> expect that the 'Acorn community', who are predominantly represented
> on this newsgroup, might be more likely than most to celebrate the
> achievements of Acorn, including BBC BASIC, and be proud that it has
> some small relevance even today. Yet, perversely, there seems to be a
> small group of individuals here who are determined to make out that
> BBC BASIC is useless. We live in a topsy-turvy world.
Rob left the world of RISC OS behind some years ago, except for
his (largely negative, as you have seen) continuing presence in
the newsgroups.
Dave