Back in the day when dinosaurs still roamed the earth and programmers still knew how to use a card punch, there were printers. Not your desktop printer of today but huge big, noisy things with all the characters on a chain, a ‘ribbon’ as wide as the paper that fed vertically on rollers and a a row of hammers that stuck the correct character as it went past on the chain, if you got it setup right that is! These things also used a paper loop for carriage control that told it where various spots where on the page, in particular the top of the page. Happy days!
In those days your program listing got printed out, so to make it more readable you’d put EJECT statements into the source code, usually before a subroutine so that the subroutine and all the comments about what it did, its inputs and outputs etc; (you did document all that stuff didn’t you?) were at the top of a page.
Fast (or not) forward to today and I doubt anyone actually prints program listings anymore. If you are anything like me it’s all online, either in SDSF, sent to a member of a ‘listings’ dataset or, if your source is off platform, your tool set grabs the output after the assembly has run and FTPs it back to your workstation/PC where again, you can view it online.
So, since the output is now all just one big stream, why would you bother putting EJECT statements into your source, other than from habit?
Now I will admit that I did this from habit until I got to thinking about it (hence this post!) and there is actually a very good reason to include EJECT statements in your source, especially before the start of a subroutine.
Here’s a little test program:
TEST CSECT BAKR 14,0 LR R10,R15 USING TEST,R10 USING WSA,R2 * * XR R15,R15 PR LTORG * SUB1 DS 0H LA R1,FIELD1 XR R15,R15 BR R14 * LTORG * WSA DSECT FIELD1 DS F'0' FIELD2 DS F'0' * END
If you assemble this, the output looks like this:
20 TEST RMODE ANY 000000 00000 00018 21 TEST CSECT 000000 B240 00E0 22 BAKR 14,0 000004 18AF 23 LR R10,R15 R:A 00000 24 USING TEST,R10 R:2 00000 25 USING WSA,R2 26 * 27 * 000006 17FF 28 XR R15,R15 000008 0101 29 PR 000010 30 LTORG 31 * 000010 32 SUB1 DS 0H 000010 4110 2000 00000 33 LA R1,FIELD1 000014 17FF 34 XR R15,R15 000016 07FE 35 BR R14 36 * 000018 37 LTORG 38 * 000000 00000 00008 39 WSA DSECT 000000 40 FIELD1 DS F'0' 000004 41 FIELD2 DS F'0' 42 * 43 END
In this code, I have let the using for WSA in the main line code ‘fall through’ into the sub routine (something I normally hate to do except for working storage based on R13). The only way you can tell that the LA,R1,FIELD1 instruction in the subroutine is using R2 as a base register for WSA is by looking at the assembled instruction.
However, if you add an EJECT before the SUB1 label like this:
EJECT SUB1 DS 0H LA R1,FIELD1
The output now looks like this:
000000 00000 00018 21 TEST CSECT 000000 B240 00E0 22 BAKR 14,0 000004 18AF 23 LR R10,R15 R:A 00000 24 USING TEST,R10 R:2 00000 25 USING WSA,R2 26 * 27 * 000006 17FF 28 XR R15,R15 000008 0101 29 PR 000010 30 LTORG 31 * Active Usings: WSA(X'1000'),R2 TEST(X'1000'),R10 Loc Object Code Addr1 Addr2 Stmt Source Statement 000010 33 SUB1 DS 0H 000010 4110 2000 00000 34 LA R1,FIELD1 000014 17FF 35 XR R15,R15 000016 07FE 36 BR R14 37 * 000018 38 LTORG 39 * 000000 00000 00008 40 WSA DSECT 000000 41 FIELD1 DS F'0' 000004 42 FIELD2 DS F'0' 43 * 44 END
The difference is that you now get one or more lines (depends on how many usings are active) that show the current usings in effect at the very start of the subroutine. As a result I can see exactly which usings are active and whether I have inadvertently ‘inherited’ one from an earlier routine that should have been dropped.
As a matter of coding style, I prefer to always drop all active usings, including code base regs except for working storage that is based on R13, at the end of each routine. That way I
know I am using the correct registers and usings in each routine and by putting an EJECT statement in the source before each routine, I can easily see from the listing that I am not inadvertently inheriting a using from an earlier block of code that may allow the code to assemble but ultimately fail when it runs because I picked up the wrong base register.
Since I’m a mainframe guy I’ve spent most of my career writing REXX whenever I needed a quick script which means that I know REXX pretty well. Lately I’ve been playing with REXX on Windows thanks to an implementation of REXX called Regina Rexx, see here.
Of course, one of the things you can do on Windows is drag and drop so I wanted to be able to drop a file onto a Regina REXX program and have the REXX program then process the file.
Typically you access input parms in a REXX exec by using the “parse arg varname” statement but I found that this did not work when dropping a file onto a Rexx exec on my Windows machine.
After some research I found that I needed to create a shortcut to the Regina REXX.EXE program with a parameter that is the path and name to the REXX program to run. You then have to drop your files onto the SHORTCUT.
So let’s say I have the following exec called “test.rexx” on my desktop:
parse arg parms say parms say "Press enter to end" parse pull .
I then create a shortcut on my desktop that looks like this:
"C:\Program Files\rexx.org\Regina\rexx.exe" "C:\Users\ltlfrari\Desktop\test.rexx"
So if I drop a file called “test.txt” onto the shortcut, this is the output that I see:
Basically the exec receives the full path and file name as an input argument.
I shall be at Share in Orlando next week so if you seem me (picture on my about page), please do say hi.
I know I have not posted anything here for almost a year but I have not died! I’ve just been very busy learning new products and product architectures.
I have to say though that it has been are really fabulous year for me that I have thoroughly enjoyed. With a bit of luck (and time) I’ll get back to posting a few things from time to time here.
Having ‘completed’ my Arduino ‘stomp box’ project I immediately realized that I needed it to do more (of course!). Originally my intention was to have one switch control the wet/dry mix on my effects unit and the other to control the selected patch, flip flopping between them, all pretty simple stuff. But then I thought about ‘soloing’. My MIDI keyboard controller (a keytar) does not send MIDI volume information, nor can I program it to do so, so I needed some way to be able to easily switch from normal playing mode (medium volume) to solo playing mode (boosted volume). Guitar players usually have a pedal they just stomp on to boost the signal to a pre set level for solos so I figured it’d be useful to be able to do that using my stomp box.
The two switches gives me four conditions, although because you cannot really use the normal (I.E. not pressed) state that leaves three conditions. Left button pressed, right button pressed or both pressed. Since I was using the first two conditions already that left the ‘both buttons pressed’ condition to use to switch between normal and solo mode.
Well that turned out to be a lot more complex that you’d think. I could not simply look at the switches and wait for them both to be pressed because the chances of my foot hitting them both at the exact same time is pretty much nil so the code would always detect one or the other on it’s own initially and I was using that state to switch the mix or patch. Waiting to see if the other switch was pressed was not really an option because how long do you wait?
What is interesting though is that a binary switch has more than just an on or off state. It also has the ‘changed state’ condition. I.E. It was open but is now closed and it was closed but is now open, often referred to as leading and trailing edge (of a square wave which is what you’d see on an oscilloscope if you tracked the voltage on the switch contacts).
So what I did was to switch the mix and patch selects to work on the trailing edge signal, that is when you release the switch and I made the volume switch occur on the leading edge, that is when both switches closed. That way I could distinguish between the events quite easily.
But wait, there’s more!
Originally I hard coded the normal volume level but than I thought, well what if I want to change it for a particular setup (I figured leaving the ‘solo’ setting at max all the time was fine), I’ve only got two switches and I’ve used them all and how do I indicate what is going on to the user, I’ve only got two LEDs?
Well it turns out a switch can have yet another state and that is how long it has been pressed. Since the mix setting now triggers on the switch release, I can now time how long a single switch has been pressed and if it exceeds a certain time (I figured five seconds was a good value, not too long, not too short) then I put the unit into ‘program’ mode. To indicate this to the user I made the LED next to the switch flash.
Once in ‘program’ mode I can listen for the other switch being pressed and each time it is pressed, increase the ‘volume’ setting. Rather than have the user step through 127 values I figured having ten steps would be enough that I convert into MIDI signal levels by multiplying by 12 which gives me ten settings of 12 through 120.
To indicate the current volume ‘setting’ I make the second LED flash using a slow setting for the lowest volume and increasing the speed for each click up to ten at which point it cycles around back to the lowest setting.
Pressing the first switch again takes it out of program mode and saves any new volume setting.
But wait, there’s even more!
The chip on the Arduino has 1024 bytes of EEPROM that can be used to save data even when the device is turned off. So after setting a new volume I now save the setting in the EEPROM so that when the device is switched on I can restore the volume setting from the save value in the EEPROM. I also flash the second LED one to ten times (depending on the save volume level) at switch on to indicate to the user (me!) the current ‘normal’ volume level in use.
I have been very impressed with the quality of the Arduino IDE and the programming libraries available for it. In the past I have done micro processor (PIC) programming but used assembler. That’s fine but you have to do EVERYTHING yourself and testing can be ‘interesting’ to say the least. Writing in C and using existing libraries made development and testing very easy and speedy, especially when used in conjunction with the Arduino IDE’s ‘serial monitor’ and loads of debugging messages in the code (wrapped in #if defined statements so I can easily remove them for the ‘live’ code).
If I have on criticism of the Arduino IDE (or rather the doc) it is that as well as the extensive Arduino specific libraries you can also use code from the AVR project, which I wanted to do for the EEPROM support since it has more function (block read/write) than the Arduino library. However even though the AVR library is included in the Arduino IDE, it is not very well documented in the Arduino doc. It was only by chance (thank you Google) that I even came across the AVR library and I then spent quite a long time trying to figure out how to add it to the Arduino IDE before I found that it was already there.
This has been around a while but I’ve only just seen it. I’m pretty sure I’ve been on this call…!
I was recently browsing my local county recycling center web site and it seems they now accept amongst other things “main frames”!
Got an old z196 you no longer need, just recycle it here.
I do have to wonder how many “main frames” they actually get though, or even why it is on there!