Version Numbers in Code?

[diyhouse]

Not sure where to place this question but this seems as good a place as any...

So,.. how Can I add a version number that auto increments each time I run the assembler.

I am using the tass64 assembler, and I was hoping to be able to add a number that increments each time I run the assembler to create a binary file, and automatically add the newly incremented number into the binary at a defined place..

I guess the number has to have a range to 0-9999,.. thinking outside the box and further what about stamping the code with date and time,.. or is that a stretch too far,...

Has anyone else played with this concept with the TASS assembler.

Many thanks for any feedback
kind regards

[Klaus2m5]

Don't know tass64, but other assemblers. I would create a batch/script file as a frontend to the assembler. The batch would then echo a .db "Version" into a file called version.inc and execute the assembler afterwards. The assembler source in turn must have an .include version.inc.

The "Version" string can then be an increment to the existing version.inc or even better a string with the file date and time of the assembler source.

note: .db = .text = .byte - whatever tass64 takes as a string directive

[whartung]

Actually, what most folks do is not increment for every compile, but rather increment for every "release", for whatever reading of "release" you want. In practice this tends to be facilitated by the Version Control system.

In many VC systems, you can place special tokens in your code. Then, when the code is checked out, the VC system replaces that token with version information (and you can do what you like with that number, notably stick it in a string or whatever).

So, mechanically, what happens is that your code version is incremented every time the code is changed and actually checked in to the VC system. Since the VC version of the code is the "source of truth", this tends to work well in practice. When someone has an issue with their code, you can have them report the version information, and (ideally) pull out that exact source code (and build instructions, etc.) from your VC and try to duplicate the problem.

[BigDumbDinosaur]

whartung wrote:

Actually, what most folks do is not increment for every compile, but rather increment for every "release", for whatever reading of "release" you want. In practice this tends to be facilitated by the Version Control system.

That's what I do: change the version and revision numbers only when a significant code change occurs, e.g., adding, modifying or removing a feature. However, as I'm testing changes I increment a sequence number before I assemble the program (note: one does not compile assembly language programs) so I know where I am with the changes as I track down and fix errors.

POC's ROM displays a version number at boot time, it being of the following format:

Code: Select all

1.1.2.20120917-05
| | | |||||||| ||
| | | |||||||| ++———> assembly sequence number
| | | ++++++++——————> assembly date
| | +———————————————> revision number
| +—————————————————> minor version number
+———————————————————> major version number

Together, the assembly date and sequence number constitute the ROM "serial number." At the beginning of the source code I have a set of macros into which I input these values. Here are the macros from POC V1's BIOS ROM source code:

Code: Select all

;	* * * * * * * * * * * *
;	* VERSION INFORMATION *
;	* * * * * * * * * * * *
;
hardvers .macro                ;hardware version
         .byte "1"             ;major
         .byte "."
         .byte "5"             ;minor
         .endm
;
hwdate   .macro                ;hardware revision date
         .byte "2012"          ;year (YYYY)
         .byte "/"
         .byte "04"            ;month (01-12)
         .byte "/"
         .byte "28"            ;day (01-31)
         .endm
;
softvers .macro                ;software version 
         .byte "1"             ;major
         .byte "."
         .byte "1"             ;minor
         .byte "."
         .byte "2"             ;revision
         .endm
;
romsnum  .macro                ;ROM "serial number"
         .byte "20120917"
         .byte "-"
         .byte "05"
         .endm

Later on in the source file that has the boot-time display data code, I use the above macros to insert the relevant text:

Code: Select all

;SYSTEM INITIALIZATION TEXT STRINGS
;
si_bannr cpos 2,1              ;@(2,1)
         .byte "* * * POC SINGLE BOARD COMPUTER * * *"
         cpos 3,2              ;@(3,2)
         .byte "Designed by  BCS Technology Limited"
         cpos 9,3              ;@(9,3)
         .byte "128KB Static RAM System"
         cpos 4,5              ;@(4,5)
         .byte "Main Processor  : WDC W65C816S-14"
         cpos 4,6              ;@(4,6)
         .byte "Hardware Version: "
         hardvers
         .byte " ("
         hwdate                ;hardware date
         .byte ")"
         cpos 0,23             ;@(0,23)
         .byte "Copyright (C)1991-2012 "
         g0                    ;horizontal line
         g0
         .byte " BIOS Version "
         softvers
         .byte "."
         romsnum
         .byte 0

Omitted in the above code snippet are the instructions that generate a graphic box that is part of the display.

During assembly and macro expansion, the version data is automatically inserted into the text strings that get printed to the console screen. The cpos macros in the source code position the cursor to col,row. The above, along with instructions to draw a graphic box, would result in the following:

Code: Select all

+———————————————————————————————————————+
| * * * POC SINGLE BOARD COMPUTER * * * |
|  Designed by  BCS Technology Limited  |
|        128KB Static RAM System        |
|———————————————————————————————————————|
|   Main Processor  : WDC W65C816S-14   |
|   Hardware Version: 1.5 (2012/04/28)  |
+———————————————————————————————————————+















Copyright (C)1991-2012 —— BIOS Version 1.1.2.20120917-05

display being printed to the screen at boot-time (the + is actually a graphic corner—I can't put these into the text).

I haven't figured out a satisfactory way in which to update the ROM serial number data at assembly time, as the Kowalski simulator's assembler doesn't have any means by which to do so.

[teamtempest]

Quote:

I am using the tass64 assembler, and I was hoping to be able to add a number that increments each time I run the assembler to create a binary file, and automatically add the newly incremented number into the binary at a defined place..

I guess the number has to have a range to 0-9999,.. thinking outside the box and further what about stamping the code with date and time,.. or is that a stretch too far,...

Don't know about other assemblers, but HXA has a time$() function that returns the system date and time as a string (which can then be chopped up as desired). It's basically just a wrapper for the TAWK ctime() function (which in turn is probably just a wrapper for the 'C' standard library's ctime() function).

But notice that in essence what happens is that a value is being retrieved that is (a) stored outside the assembler itself and (b) is maintained by "something" outside the assembler as well. Those mechanisms already exist, and accessing them is trivial.

An "assembly number" that increases with each run is like time and date in that it has to be stored and maintained outside the assembler itself. BDD does it with hand-coded macros in the source code, for instance. In any case it's something you'll have to implement yourself. The idea of doing with a batch file or other script language that writes (or reads, slightly alters and then re-writes) an "include" file and then executes the assembler seems a reasonable alternative approach.

Even if an assembler was capable of incrementing a run number by itself, there still would have to be some kind of external persistent storage to let the assembler know what the next value should be. And you'd probably want it to increment each different source file with its own sequence, so if you assembled file "a" and then file "b" and then file "a" again, "a"'s run number would go up by only two instead of three. So there would have to be a way of associating file names and run numbers.

I suppose there could exist something like a getrun$() function that looked for a particular file name (most likely the file name that contains the getrun$() call with a different extension), read it, returned the value and then re-wrote the file with an incremented value. If the file didn't exist, return 1 and write the file with a value of 2. In the source code it would look something like:

Code: Select all

.string getrun$()

and one of BDD's macros would look like:

Code: Select all

romsnum  .macro                ;ROM "serial number"
         .string "20120917"
         .string "-"
         .string mid$( "00000" getrun$(), -2)
         .endm

That expression just concatenates the run number onto a string of "0" characters and then chops off everything but the last two characters, so runs 1-9 come out "01" to "09". Unless they were written that way in the first place, but is a fixed format the best approach?

I dunno. I can see its use, but it's sort of a specialized thing.

[whartung]

I was going to suggest the idea of using a date function (though I didn't know of any assemblers that happened to have one), but the problem with something like that possibly becomes that there is no way to determine that the source you are working with is the source code in the ROM. You could compare the assembler listing (which would have the correct information), but, not the source itself. This sort of defeats the purpose I think.

Version Control is so cheap and ubiquitous, that I think it would be better to simply commit every build to a branch and use the VC mechanism. When you're done with a chunk of work, you can merge the branch work up in to the main development branch. Have to play with the workflow though.

[GARTHWILSON]

Quote:

I was going to suggest the idea of using a date function (though I didn't know of any assemblers that happened to have one)

The 2500AD 6502/65c02 assembler I used in the late 80's and early 90's does have it. I just looked at the manual for C32 which I now use and it does not seem to have that kind of thing. I think I would just increment the version manually in the source code.

[BigDumbDinosaur]

GARTHWILSON wrote:

Quote:

I was going to suggest the idea of using a date function (though I didn't know of any assemblers that happened to have one)

The 2500AD 6502/65c02 assembler I used in the late 80's and early 90's does have it. I just looked at the manual for C32 which I now use and it does not seem to have that kind of thing. I think I would just increment the version manually in the source code.

Considering that any good C compiler will do date- and time-stamps that can be embedded into compiled strings, you'd think this would be a standard feature of all commercial grade assemblers. Guess not.

[diyhouse]

Thanks for the feedback guys,.. just catching up with the final comments posted.
Clearly TASS64 does not do these things, as I suspected,.. but I think I will explore the options of doing some external scripts and doing and import of some description.

Many thanks to all
Mark

[8BIT]

diyhouse wrote:

Not sure where to place this question but this seems as good a place as any...

So,.. how Can I add a version number that auto increments each time I run the assembler.

I am using the tass64 assembler, and I was hoping to be able to add a number that increments each time I run the assembler to create a binary file, and automatically add the newly incremented number into the binary at a defined place..

I guess the number has to have a range to 0-9999,.. thinking outside the box and further what about stamping the code with date and time,.. or is that a stretch too far,...

Has anyone else played with this concept with the TASS assembler.

Many thanks for any feedback
kind regards

64tass has the -D command line option to assign a value to a label name. I spend a little time today playing with Windows 7 batch files. I have developed a way to provide the incremented number as label value. You could place that value in the object file as you see fit. It works with two batch files. One simply contains a "SET vers=1" command. This is used to initialize and keep the count. The other batch file calls the first, increments the count, erases and replaces th first with the new count. It then calls the 64tass assember with the -D command line parameter. You will need to modify that line to suite your particular 64tass needs.

1.bat looks like this:

Code: Select all

call 2.bat
del 2.bat
set /A vers += 1
echo set vers=%vers% > 2.bat
call 64tass -D vers=%vers% %1
pause

The %1 at the end of call 64tass... line could contain the source file. i.e.,
"1.bat mycode.asm" would call 64tass to assemble mycode.asm Alternatively, you can just hard code the command line as you need (my preferred method).

2.bat looks like this initially:

Code: Select all

set vers=1 

This will probably work with older windows too, but you will have to experiment. Try it by placing the two batch files in an empty folder and clicking on the 1.bat file 3 or 4 times. Then edit the 2.bat file. It should have the incremented count if all works correctly.

I have attached the files too. Be sure to rename to 1.bat and 2.bat (drop the .txt)

Enjoy!

Daryl

[jgharston]

I use the assembler built into BBC BASIC, so my code starts along the lines of:
ver$="1.00 ("+MID$(TIME$,5,11)+")"

which then later goes in as:
EQUS "name":EQUB 0
EQUS ver$:EQUB 0
etc.

[diyhouse]

As way of completeness,.. I will add my final entry to this post,....

Bottom line success!!!,.. with thanks to all for their input.

I eventually adapted the above scripts from "8Bit" to end up with a compile script that looks as follows:-

echo %time%
call 2.bat
del 2.bat
del vers.inc
set /A vers += 1
echo set Vers=%vers% > 2.bat
echo vers .word %vers% > vers.inc
@ECHO OFF
FOR /F "tokens=*" %%A IN ('TIME/T') DO SET Now=%%A
ECHO It's %Now% now
echo TM %now% > tim_date.txt
@ECHO OFF
FOR /F "tokens=*" %%A IN ('DATE/T') DO FOR %%B IN (%%~A) DO SET Today=%%B
ECHO It's %Today% today
echo DT %today% >> tim_date.txt

64tass light.asm -L lights.lst -o a-lights.obj -b -l labels.txt
echo %time%

and a file Vers.inc which looks as follows;-
vers .word 3893

This uses 64tass directives to include a number with a range up to 65000, ( so should keep me going on versions for a while

and 2.bat which looks as follows:-
vers .word 3893

So for a simple explanation,.. c.bat runs calls some other batch files which create a new vers.inc file, this is then included in the compiled files as well as one called tim_date.txt which contains the current date and time..
So with some nimble settings in memory of where things load,.. I now have a new compile versions as well as the date and time the compile was run included into the binary object code....

many thanks once again

Regards