Sound for Squeak/Scratch

No C has nothing more in common with Assembly than any usable High Level Language (HLL),

I think you’ve just tripped over yourself there. Compare C with PHP. Both can be counted as “high level language”. One compiles to machine code, one compiles (if not interpreted) to a sort of p-code. One requires you to write (or use library) functions and do your own housekeeping. The other… provides a fairly sanitised environment for your “program” and does a lot of stuff for itself.
They couldn’t be more different. In fact, one might reason that there is a much greater difference between C and PHP than between C and assembler.

It is worth pointing out that C’s use of pointers and some of the things you can do – while not assembler – are very low level. Show me an HLL that does that sort of stuff.

The primary difference, however, is that while assembler is a list of instructions to the machine, a C program is a description of what is supposed to happen. The compiler looks at this description and attempts to make code from it. Due to a myriad of boring reasons, this code may or may not be what you had in mind.

This low-level aspect of C is why I (and others) tend to think of it as a sort of assembler-lite. This document explains what I mean.

‘Converting BASIC to Assembly’

Not read that, sounds interesting.

Converting C to assembly is dead easy. Create the directory “s” and then pass -s as a command line option. If you have a half-decent compiler, it’ll interleave source fragments with the assembly generated, so you can see what is going on and why. It is sometimes fascinating to see how a particular construct is compiled.

Though even Brian Kernigham is very attament about there being nothing assembly like about C,

Pointers.
Pointers to functions.

and it being further removed from the Hardware than many other HLLs.

Are you sure you read that correctly? Unless you are comparing with FORTRAN or some PDP-8 language I’ve never heard of, C is much closer to the hardware than most languages. Reference: Huge swathes of the C spec; but two off the top of my head:
1. int is a variable size object (maps to the natural word size of the target CPU), and
2. There is no such thing as a string. While there is a special syntax to make string accesses simpler ( because mystr[10] is simpler than *(mystr+10) ) however there is no C operation that works directly on strings. Strings are an array of bytes (or something larger on a unicode system) and you can’t even read the string length nor join two without resorting to library functions.

That said, C does attempt some degree of hardware abstraction, along with the often lauded (but fairly flawed in reality) concept of portable code. This is to be expected, for it is pretending to be a high level language after all!

I will close from a quote from Wiki on the C page :

Its design provides constructs that map efficiently to typical machine instructions, and therefore it found lasting use in applications that had formerly been coded in assembly language, most notably system software like the Unix computer operating system.

Looks like scratch works ok on the pi. A bit slow I have to admit but cats meow, circles honk like geese, saving a project changes the window title, trying to record sounds doesn’t crash (somebody made a right mess of the sound record code in that ancient image) and loading new image and sound samples works.

And C? C is just a jumped-up bastardised PDP assembler with delusions of adequacy. Don’t get me started on c++, c# or java.

Rick said:

there seems to be nothing much in C++ that you can’t go in plain old C if you take the time to think about your implementation

Pity the book didn’t mention that C++ was originally a preprocessor stage feeding existing C compilers.

But as Turing would be quick to point out, there is nothing in <language A> that can’t be done in <language B> – that’s sort of the point. It’s just that certain tasks are easier in certain languages.

Rick also mentioned:

I poked around the SVN repo and noted with some amusement that Squeak’s VM is written in C.

What I think is more amusing is that <insert C compiler of choice> is written in C. Trace that back!

I mean hand conversion, not cheating with a compiler.

;-)

Try it some time with the 32 keywords and 45 operators that make ANSI C.

How is this different to converting to assembler?

Also try implementing the entire stdlib with out a single line of assembly on ANY target.

I’m not sure what you are trying to say here – weren’t we talking about porting C to assembler? Actually, I would imagine it would be possible to implement stdlib in C without assembler – at least under RISC OS with a wide range of OS routines to call using _kernel_swi() – however doesn’t that rather defeat the purpose of a library?

There are not many USABLE HLL/Mid level programming languages that compile to machine obect code that do not support pointers, and pointers to functions.

You have to bend over backwards to get object pointers out of VB – and they’re only there because parts of the Win32 API require it.
Pointers to functions and calling functions by pointer (and not name)? Is that doable?

Pity the book didn’t mention that C++ was originally a preprocessor stage feeding existing C compilers.

I remember CFront. Its code output was…interesting.
No, my uncle was quite derogatory to the C lurking inside C++ so I’m sure he’d want to gloss over that. ;-)

It’s just that certain tasks are easier in certain languages.

I’ll await a bootloader written in Ruby. ;-)

What I think is more amusing is that is written in C.

Logically the first was written in code until it was capable of compiling itself, and then cross compilation, and…

Although personally I prefer the “chicken or egg” conundrum. It’s more fun.

I should add, a long time ago I wrote a broken, horrid, partial C interpreter in BASIC. T’was the product of too much free time…

Now I relize that this thread is now way way off topic. So lets get back to Scratch and its sound.

Good idea :-)
Squeak sound is functional now, including being able to play a 30+ midi track file of Tubular Bells without glitching, whilst synthesising a dozen or more instruments on the fly. I’m quite impressed with that, dunno about you.
Right now I’m working on a small extension that replaces a (sort of) busy wait with a (sort of) interrupt driven wait on spare buffer space. That in turn lets Squeak work out when no more sound is coming and shut things down to save a little cpu. I’ve no idea if it will make a major difference on RISC OS but it was a big improvement on unix.

The next part, and one that may well not be possible any time soon, is getting sound input to Squeak. Anybody have clue about that? Bonus points if it can be done using any of the nice stream and buffer management code John Duffell provided for the output, because that is nice code.

Squeak sound is functional now, including being able to play a 30+ midi track file of Tubular Bells without glitching, whilst synthesising a dozen or more instruments on the fly. I’m quite impressed with that, dunno about you.

Whoa.
Nice.

Could you try this MIDI file and let me know how it plays? http://www.mediafire.com/?apana50y9sqhkey

Also: Sheet music (PDF), the transcriber’s website, and a YouTube of the guy playing it on his piano – epic win (let’s just say I reckon I’ll never be that good…).

It is simpler than a many-instrument MIDI, however some of the notation is pretty fast – as can be seen from the sheet (you don’t have to be able to read music, just look at all those lumpy things piled on top of each other!).

Right now I’m working on a small extension that replaces a (sort of) busy wait with a (sort of) interrupt driven wait on spare buffer space.

That makes a lot more sense. Busy-waits are optimal if your system if running at full capacity. For instance, the little I have looked at the FileStore E01S code, it appears to busy-wait floppy accesses because there’s a danger of losing data if the system has to rely on interrupts.
However, when your system is much faster than the event you’re waiting for, it makes a lot more sense to have the events interrupt the machine as and when, instead of wasting a lot of time saying “you done yet? you done yet? you done yet? you done yet? you done yet? you done yet? you done yet?” like an impetuous child (<cough> voice of experience, here ☺).

The next part, and one that may well not be possible any time soon, is getting sound input to Squeak.

Well, the first thought is that it will depend upon the hardware. For instance, the Beagle has an audio input. The RPi does not. Of the audio input, this sort of presupposes something in the OMAP3 (or that JackOfAllTrades helper chip!) is capable of accepting audio input, which means there may well be a defined API like “set up some registers and await the thing interrupting to read out raw sample data”.
On the Pi? Do any of the accessible GPIOs connect to an ADC? Does it run fast enough to make 44.1kHz sampling viable?

Bonus points if it can be done using any of the nice stream and buffer management code John Duffell provided for the output, because that is nice code.

Don’t know this code (never looked). If the API is extensible/open enough to cater for input as well as output, it may be possible?

Ok Rick,I’ll give your midi file a go tomorrow. Assuming that I can get past whatever stupid bug is making things annoying this evening. I’ve been trying to hook up the (supposed) pollword stuff and I’ve clearly grabbed the wrong stick, let alone the wrong end.
I request a pollword pointer from StreamManager, use it to check for sm declaring some buffer space is available, and zero out the pollword; boom, assorted lockups. If I don’t clear it, the system works sorta-ok but definitely not correctly. Weird.

And for DavidS, there isn’t any sort of official Scratch for RISC OS yet. I’ve seen reports of a few people trying the unix image out on ancient Squeak virtual machines with some apparent success but once I’ve got his sound sorted out I’ll release a more set up system. I got the Scratch support code working yesterday, which makes a few graphics operations faster, supports Scratch’s rather odd idea of where files live, lets it open URLs in Netsurf and change the window title to match your project name. Nothing big but it stops some silly bugs that the Scratch guys could have handled a lot better with some thought. Just a thought – your tutorials really ought to mention at least in passing that there has been 25 years of Smalltalk on RISC OS! All my fault…

I’ve been trying to hook up the (supposed) pollword stuff and I’ve clearly grabbed the wrong stick, let alone the wrong end.

Are you it using a module-supplied pollword, or an application-supplied one? If the latter case, remember the pollword must be allocated in the module area (so it can be set even when your application has been paged out).

Tim: are you being given a pollword, or a pointer to a pollword? Are you nulling a pointer?

I’m (trying ) using the module provided pollword, which on examining the doc provided more carefully is described as ‘should be treated as an opaque word and only compared with 0’. So with code changed to not zero it after polling, less goes wrong.
My problem is really that the module’s poll word usage isn’t quite a match for what I need and working out how to get around that is tedious. My incoming interface is -

if (available space < smallish number of samples) { wait until ReadySemaphore is signalled}
load up Buffer with one or more sound streams, mixed, merged and reverberated as specified
write buffer contents to sound system
repeat until no more incoming sounds

The problem with the current poll word setting scheme is that the sound system sets it when an internal buffer has been read – i.e. there is now at least one buffer available.
That is a good time for me to signal the semaphore, which then allows the Squeak code to take another peek for free space (which we’d expect at this stage to reveal a buffers-worth of free space, of course)
BUT if the poll word has to stay non-0 then the next poll will think that another signal needs to be sent to the semaphore. Since semaphores keep track of how often the’y been signalled this can result in the space querying loop going around and around when it ought not. Now this doesn’t actually crash anything but it does completely bypass the entire point of haven a semaphore to stop you wasting time going around and around querying!
So my guess right now is that if use my own poll word (os_module_alloc I guess) and tell the module to use that (one can specify the bit to set, which is nice) then at least I should be able to zero out that without crashing anything!

Which reminds of another faintly related problem that should probably go in another thread – I have a small module that works with Rik Griffin’s HALTimer (see relevant thread on the fun we had with that) to keep a millisecond timer up to date. I lost the source code BASIC file. I can’t find any simple explanation or tutorial on writing a trivial module. I can’t compile any of the example module code in the nutPi DDE examples because some libraries are not provided. Any advice? Anyon by any chance stashed away a copy of the source BASIC prog for ‘MillisecondTimer’ ?

I’m (trying ) using the module provided pollword, which on examining the doc provided more carefully is described as ‘should be treated as an opaque word and only compared with 0’. So with code changed to not zero it after polling, less goes wrong.

Yes, I see that there is an HTML document that is better than the text file:

This SWI sets up the poll word used by the specified stream. The poll word bit will be set when blocks are removed from the buffer, it will be cleared when a block cannot be fitted into the buffer. If the poll word is supplied by the module, it should be treated as an opaque word, and only compared with zero.

The poll word can be changed as often as is necessary.

Does John not fully understand what a PollWord is for? Non-zero means the foreground application is polled, zero means it is not. Things signalled by the pollword can be specified by the pollword value (specific bits, etc). When the action has been performed, the pollword should be reset to zero or else, as you noticed:

BUT if the poll word has to stay non-0 then the next poll will think that another signal needs to be sent to the semaphore.

[reference: https://www.riscosopen.org/wiki/documentation/show/PollWord_NonZero ]

As the sources are provided, I would suggest that you botchpatch the module so that it sets a pollword to a specific value (bit 0 is this, bit 1 is that, etc) when events need to be signalled to the foreground, and ensure that the module never needs to rely on the state of the pollword itself.

Something that concerns me is “it will be cleared when a block cannot be fitted into the buffer” – surely this is something you want to notify to the foreground application? Clearing the pollword will result in the foreground application not being polled.

I can’t find any simple explanation or tutorial on writing a trivial module.

Pure assembler: http://www.heyrick.co.uk/blog/index.php?diary=20120528

I have a small module that works with Rik Griffin’s HALTimer (see relevant thread on the fun we had with that) to keep a millisecond timer up to date. I lost the source code BASIC file. I can’t find any simple explanation or tutorial on writing a trivial module. I can’t compile any of the example module code in the nutPi DDE examples because some libraries are not provided. Any advice? Anyon by any chance stashed away a copy of the source BASIC prog for ‘MillisecondTimer’ ?

I have a little something for you…

I was bored and forgot I had Chihayafuru to watch, so I figured a smallish module shouldn’t take to long to unpick.
Ha ha.
Actually, the raw transcription took about half an hour (slow typing as I checked each line twice!). What took the remaining HOURS (!) was adding all of the commentary.
This is how I write code – the code should explain itself, so if you load n into register x prior to a SWI, there absolutely must be some sort of indication of what this is for. All registers to API should be described, and so on. Plus good use of whitespace and formatting to enhance clarity. Anything less is unacceptable to me.

[whinge]It annoys the hell out of me when you are spending half the time looking at code and half the time looking in literature and half the time trying to work out where loops and other constructs begin and end as the formatting is crappy (one of my pet hates is the school of C programming where the braces are on the same line as the code, like “int myfunc(void) {”. Yuck! Yuck! Yuck! I use the Allman style; the K&R style is horrible IMHO). And yes, I know I listed three halves. That’s what it is like reading unclear code!
Oh, and nobody give me the “I am the programmer, I know this stuff” excuse, for firstly you are assuming nobody else will ever see the code and (more importantly) that you will be capable of remembering its intricacies in numerous years of not having looked at it. I myself have been “out” of the RISC OS scene for a looong time (say 2004-2011ish?) and I think it is thanks to a simple clear API and the clarify of my own code that I have been able to get back into the swing of things. Sure, it takes longer to write, but I believe it pays dividends in the future…[/whinge]

Anyway, Tim, here’s the start…

REM >MillisecondTimerReassembly
REM
REM Unpicked from assembled module
REM by Rick Murray 2012/01/26
REM
REM I was bored and forget I had Chihayafuru to watch. ;-)
REM
REM NOTE: *UNTESTED* - written on a non-HAL emulator with an older
REM       version of RISC OS. The files "look" the same; sadly Acorn's
REM       diff doesn't cope with binary files so I haven't checked it
REM       for parity with the original...
REM

ON ERROR PRINT REPORT$+" at "+STR$(ERL/10) : END

DIM code% 1024

FOR pass% = 4 TO 7 STEP 3
P% = 0
O% = code%

[  OPT    pass%                      ; using offset assembly as it is a module!

.beginning
   EQUD   0                          ; Start offset
   EQUD   (init  - beginning)        ; Initialisation offset
   EQUD   (fini  - beginning)        ; Finalisation offset
   EQUD   0                          ; Service call handler offset
   EQUD   (title - beginning)        ; Title string offset
   EQUD   (help  - beginning)        ; Help string offset
   EQUD   (hlpcmd- beginning)        ; Help/Command Keyword table offset
   EQUD   &58100                     ; SWI chunk base
   EQUD   (swi   - beginning)        ; SWI handler code offset
   EQUD   (switbl- beginning)        ; SWI decoding table offset
   EQUD   0                          ; SWI decoding code offset
   EQUD   0                          ; Messages filename offset
   EQUD   (flags - beginning)        ; Flags word offset

.flags
   EQUD   1                          ; Bit zero set = 32 bit compliant 


; ### TITLES AND SUCH ###

.title
   EQUS   "MillisecondTimer"+CHR(0)
   ALIGN

Interested? You’ll find the rest here:

http://www.heyrick.co.uk/random/MillisecondTimerReassemblyText.txt

TEXTLOAD it into BASIC and run it, it should create a module that matches the original.

Note 1: I can’t guarantee the MSR syntax is correct for BASIC. I’m using an emulator with a much older RISC OS (doesn’t do MSR at all!) so I used EQUD to drop in the instruction coding directly.
This also means that the module is untested.

Note 2: All those (annoying?) “##TODO##” markers are things in the code that seem “unusual”. Explanations given. I just dropped these in as I was transcribing it from a raw disassembly. Feel free to ignore the commentary. ;-)

Have fun!

Wow, thanks Rick. Umm, doesn’t/didn’t ARMalyser do some of the “making vaguely sensible ASM file” part of unpicking a module/aif ?

The good news is this is a really simple module with a whole not (or two? I forget) SWIs and a just one command. At least we don’t need to unpickSharedStreamBuffer :-) What’s really scary to recall is that I used to be able to make reasonable sense of ARM object code in hex. Worse yet, for a short while in the mid 90s I could debug PPC hex code – I had to do that once at Apple HQ in order to get a version of our Smalltalk product running on the newer memory model; no source code to hand, find where something went wrong, recognise the pattern, recall the earlier talk about the change, manually insert the correct bytes to fix the instruction and… it worked. Scary what a mind can manage at times.

So progress today is curious; I cleaned up a load of code and made a RMA allocation for my very own pollword space, tried to remember the details of what &(int **)foo might mean and.. it didn’t work properly. Much swearing and debugging later, my subconscious decided to remind me that I had in fact looked at the ask code for this part of the module and maybe I should check it again; yup – the flag usage for "module supplies pollword " vs “user supplies address of their poll word” was flipped in the doc. Sigh.

RIght now it’s running a lot more smoothly but I’ve broken something to do with pausing the system when there is no more to play and then restarting when new sounds come in. Oh well. And yes, I agree about proper documentation. My old boss – a formidable lady by the name of Adele Goldberg, who could stop Jobs in his tracks with a glance – used to point out that “if it isn’t documented it might as well not exist and if it doesn’t exist then why, exactly, did we pay you?”

More progress tomorrow.

Ahem. Just downloaded Rick’s code as I’m trying to get back into ARM assembler again after a similar break of time. In case others are downloading the full code, there appear to be a couple of very minor typos in Rick’s code. Missing “$” on one “CHR” and an extra “$” on another CHR$. These are just normal BBC BASIC functions but used in the assembler to insert a character.

.title
EQUS "MillisecondTimer"+CHR(0)

CHR should be CHR$(0)

later…

CHR$$(0) should be CHR$(0)

Apart from that, the module appears to be created when the programme is run from BASIC (I’ve not checked the actual module in any way).

Ralph

Wow, thanks Rick.

You’re welcome.

Umm, doesn’t/didn’t ARMalyser do some of the “making vaguely sensible ASM file” part of unpicking a module/aif ?

Yes, but it is only good for large projects where manual work is unfeasible. If you look at my code vs ARMalyser, you’ll be able to get on better with mine – things have sensible names (instead of being labelled by address) and there is a much deeper level of commentary as I can see what API calls are being made.

Or, in short, there is a vast gulf between seeing the code and understanding the code. ;-)

The good news is this is a really simple module with a whole not (or two? I forget) SWIs and a just one command.

True. That’s why I did it.

At least we don’t need to unpickSharedStreamBuffer :-)

Hehe, I’m having enough trouble reading the source thanks to K&R formatting.

What’s really scary to recall is that I used to be able to make reasonable sense of ARM object code in hex.

Whoa! Impressive!
I discovered Zap pretty early on. Never had a need to learn anything in hex.

I did know some 6502 in hex, namely where to fiddle comparisons and insert NOPs. But not being word-aligned and not having as powerful disassembly tools, it was necessary to do more in your head.

Scary what a mind can manage at times.

Anybody who can speak a foreign language dissimilar to their own is impressive. Double points if they are able to read/write Japanese/Chinese (ideographic languages).

Those people who can “hear” something once and then play it correctly on the instrument of their preference.
Not to mention those who can take a melody and arrange it for a full orchestra.

We program the ARM. A whole different class of awesome are the people who make the ARM.

Lastly, but not least, anybody who delves into Quantum Physics and doesn’t freak out within the first hour when they realise their perceptions of reality are a thin illusion.

Yeah, there’re a ton of people way smarter than me. ;-) Pretty amazing what can happen inside one person’s brain.

…but, have you ever had one of those dreams with a cast of dozens and dozens of people all working autonomously (like real people) and you wake up and think “who the hell were they?!”?

tried to remember the details of what &(int **)foo might mean

Hehe… I try hard to avoid stuff like that in my code. Err… the address of a pointer-to-a-pointer pointed to by “foo” (which is cast as an int)?
If I needed to know, I’d be inclined to compile it and look at the code to see what was actually going on. However, as I said, I try to avoid complicated pointer assignments where possible.

module and maybe I should check it again; yup – the flag usage for "module supplies pollword " vs “user supplies address of their poll word” was flipped in the doc. Sigh.

Oh, yes. The “documentation errors”. The bane of programmers everywhere.

In case others are downloading the full code, there appear to be a couple of very minor typos in Rick’s code.

Fixed. ;-)

<excuse mode="on">
Since I was working with RISC OS 3.7 on a RiscPC class emulator, the source I assembled while checking everything worked was a different program to that which you see at the above link – namely the MSR was not recognised so I inserted the opcodes directly, minor stuff like that. When something was corrected in the BASIC working file, I corrected it also in the text version. Obviously, I missed a couple of things. :-( It was three o’clock in the morning by the time I finished! [and that includes a lot of reading the code from the original and my version side-by-side in Zap windows to look for disparities!]
</excuse>

Ugh. Well, I think sound is now working with all the plausible combinations that Squeak can throw at it. I’m not entirely convinced that there isn’t a pointer to the RMA space I’m using for the poll word getting, shall we say, a little confused. A few times I’ve had a ‘not a heap block’ error come up and it isn’t very easy to trace. There’s also a chance it is a buglet in the sound stream/buffer code but let’s see what happens to other users.

It plays the SparklingDaydream midi with no problems and in fact copes perfectly well with simultaneously playing that, tubular bells, poker face and random hits on the piano keyboard. Not a noise you want to hear too often!

A testable package coming soon. Ish.

Righty-ho; try http://www.rowledge.org/tim/squeak/Squeak3-9c-RISCOS.zip to download a bundle of the entire squeak setup, including the DeepKeys and SharedSoundBuffer modules, the Squeak .source file already installed and the image/changes file ready to go.

For a very sketchy Scratch try-out, try downloading http://www.rowledge.org/tim/squeak/Scratch-RISCOS.zip – but you’ll need to have grabbed theSqueak package first in order to have the deepkeys/ssb modules.

Let me know how it works on your machines…

Rick frothed:

one of my pet hates is the school of C programming where the braces are on the same line as the code

Well, that’s what style guides are for. Brace yourself.

In my experience, anyone whinging about where braces are doesn’t know perl. In fact, anyone complaining about any language that isn’t perl, doesn’t know perl.

In my experience, anyone whinging about where braces are doesn’t know perl. In fact, anyone complaining about any language that isn’t perl, doesn’t know perl.

Don’t know it, just keep having to do things with it.
I alternate between “this is dead easy” and “I think my mind just tied into a knot”

I swear the Perl FAQ is longer than the RO documentation.

perl’s great crime is having slightly more utility than its copious faults, so it sits there as though butter wouldn’t melt in its mouth promising “use me, I’ll make that job so easy” while maintaining the total amount of entropy in the universe by substituting the difficulty of the job for the difficulty of its syntax.

Well, that’s what style guides are for.

No, that’s what Holy Wars are for. ;-)

Brace yourself.

Boom-boom!

I take it perl is an obnoxious language?

It could be worse. The Funge98 version of Befunge is apparently Turing Complete – imagine if utility scripts for Internet things looked like this:

#1#3#5#7#9#b#d#f; init ;a8+y00p>:00gg' -v   v        +1_:20p:1+*1-00g\-30p00g1+v
1              1               ^      +1_10p>:00g1-g'|-^  vp06:+g01p05:+g01p04:<
2              2v ; build lists ;  p0a0p09+1p08:+1p07:+g01<
3              3>01p11p>01g:20g/+11g:20g/+30g+g:' -!v
4123456789abcde4   >   ^          _v#p10:%g01+1g10<v_ ; identify symbol ; 021p:v
v17z'p16 ; main ; _^#!p11:%g01+1g11< vp+g11g05g12;  mark in lists ; $_21g1+21p:v
p     >1g:20g/+11g:20g/+30g+g' -v    >21g60g01g+p2 1g40g01g20g/+11gv ^!-gg00g12<
8     0       v>#               _v                ^      p+*g02/g02<
>1p51p^        0  > 60g01g+g51g40 g01g20g/+11g20v  >a0g+v
6  v< ^           ^g15g+g11g05g15<              g ^ $p0a<
p  ;^;^_#;<    |p15:%g01+1g15pg09g15!`0**g+*g02/<

It is actually part of a Sudoku solver. Full version here (and dig that domain name).

My head hurts.

You were saying what about perl? ;-)

Bah, could be worse ;-P

R1.1(V0[:sig]) => R0
R1.2(V0[:m x sig]) => R0
0 => i |m + 1 = > j
[W [ i < j→ [R1.1(V0[i: m x sig]) 0> R0 | i + 1 0> i ] ] ]
END
R1.3() => R0
‘H’;‘e’;’l’;‘l’;’o’;‘,’;’ ‘;’w’;’o’;’r’;’l’;’d’;’!’ => Z0[: m x sig]
R1.2(Z0) 0> R0
END