CALENDRIC & TEMPORAL PROGRAMMING

[BigEd]

We should compare the length of your code, BDD, with JGH's modified code!

[BigDumbDinosaur]

BigEd wrote:

We should compare the length of your code, BDD, with JGH's modified code!

Well, you can’t get something for nothing!

His is limited to a relatively small date range. Granted, most of us won’t alive and kicking by the time 2100 rolls around, so I suppose range isn’t everything. Then again, no one was paying attention to date ranges in the 1970s and the next thing you knew, it was 1999 and all that old code was a problem. The 32-bit UNIX year 2038 problem is only 15 years away. Jus’ sayin’.

[jgharston]

BigDumbDinosaur wrote:

Have you looked at this?

Ooo, that's a bit humongous. It uses a general-purpose division routine to divide by 4 when that's so simple with two right shifts. I didn't realise what the code was doing until I realised it. I would never have thought to do it that way.

I was cleaning up my general-purpose DayOfWeek routines yesterday, and they use shift-right-2, divide-by-25, shift-right-2. I had two versions, and couldn't work out which I prefered, so I've uploaded both! One initially reduces the year MOD 400 before doing any calculations, so works up to the year 65535, but gets slower fairly quickly, the other just goes straight into the shift/div25/shift so over/under-flows at around year 52000, but is faster but slightly longer code.

BigDumbDinosaur wrote:

BigEd wrote:

We should compare the length of your code, BDD, with JGH's modified code!

Well, you can’t get something for nothing!

His is limited to a relatively small date range. Granted, most of us won’t alive and kicking by the time 2100 rolls around, so I suppose range isn’t everything. Then again, no one was paying attention to date ranges in the 1970s and the next thing you knew, it was 1999 and all that old code was a problem. The 32-bit UNIX year 2038 problem is only 15 years away. Jus’ sayin’.

Yes, the 8-bit version is limited to an 8-bit year range, I use a modified version of it for the DOS-like 7-bit year range 1980-2107 in my code. For completeness I wanted to get it working back to 01-01-1900 as the RISC OS date epoch is 1900.

I'm sure there's probably a bit more optimisation that can be done.

[BigDumbDinosaur]

It’s been a while since I posted anything to this topic, but that doesn’t mean it’s dead.  I have been working on improvements to my calendric library, as well as my 64-bit integer math library, and have re-spun the date program to use the new-and-improved™ libraries.  The assembly listing is attached.

date_listing.txt

Assembly Listing for date Program

(480.9 KiB) Downloaded 60 times

[GlennSmith]

I was so impressed when I saw "broken-down-time", "at last", I said to myself, "a real calendar that takes into account of all my patched-up hardware that doesn't work as expected all of the time !"
Good work, and super documentation!

[BigDumbDinosaur]

GlennSmith wrote:

I was so impressed when I saw "broken-down-time", "at last", I said to myself, "a real calendar that takes into account of all my patched-up hardware that doesn't work as expected all of the time !"

Thanks!  You should know that the author of the date program is also “broken down.”

Quote:

Good work, and super documentation!

I try to be lucid with documentation, especially with non-obvious operations.  Of course, I don’t do silly things such as...

Code: Select all

          CLC          ;clear carry

What you don’t see in that listing are the technical notes I often add to the ends of the library files.  They are placed after the .END pseudo-op in the file so they aren’t added to (and greatly lengthen) the assembly listing.  I’ve attached the source code for libtime.2, which is the calendric library, so you can see what I mean.

I’ve also attached the main source file for the date program itself—it’s more macros than code, with much of the grunt work being done in the libraries.    The macros take care of stack frames, distinguishing different addressing methods (“near”, “far”, etc.) and generally trying to catch errors that could end up messing up the stack and crashing the system.

libtime.2.asm

libtime.2 Calendric Library

(97.61 KiB) Downloaded 63 times

date.asm

date Program Main Source File

(15.68 KiB) Downloaded 59 times