Jump to content
FALCOR4

What was the best assembly code you've ever seen?

Recommended Posts

I was cleaning up my desk at work today and came across this cartoon a friend of mine gave me years ago after discovering I enjoyed programming assembly language on the TI.  It was in fun and I certainly didn't take any offense but it got me thinking about structure in assembly language programming.  So, do we have examples of what "good" assembly language programming looks like?  And, why is it "good?" If you do, I'd love to see it and hear your philosophies about it.

 

 

Self taught programmers.jpg

  • Like 2
  • Thanks 1
  • Haha 2

Share this post


Link to post
Share on other sites

XKCD says it all. . .but I really have no idea what the best TI code would look like. I am personally much more focused on what the code actually does and how well it performs that function. Seen from that angle, there is an awful lot of "best" code out there.

Share this post


Link to post
Share on other sites

Just comment it. Uncommented assembly code might as well be Martian. Even if you can tell what he's saying, you've no idea what he's talking about. ;)

 

Avoiding fancy tricks, break the code up into functions... nothing so different from what makes any other code good. ;)

 

It ultimately depends on what your goal is - if you want other people to read it, code like you mean it. ;)

 

  • Like 5
  • Thanks 1

Share this post


Link to post
Share on other sites
On 1/7/2021 at 8:43 PM, Tursi said:

 

Just comment it. Uncommented assembly code might as well be Martian.

 

An especially frustrating example of non-commented Martian-Assembly is the Boone MBX code.

Help @Tursi if you get bored and need a new TI project ;)

Share this post


Link to post
Share on other sites

@Tursi's Multicart code.  Bar none, some of the most impressive assembly work to this day that I've seen.    Simple, concise, and works extremely well.  The code scans all 8K banks on a bank switched ROM within the console's 256 bytes of scratchpad RAM, generates a menu on the fly, and then launches the ROM.  No 32K Expansion required.   Also, had a super cool font.

 

Completely blew me away on how he accomplished it, and still impresses me to this day.

 

  • Like 3

Share this post


Link to post
Share on other sites

Well, very few people have looked at the code for MDOS, however in my opinion, it is probably one of the finest examples out there.  Until you really start digging into it, and boy do you have to dig into it, but it is truly amazing everything that is in the code.

 

The code requires approximately 22 x 8K pages of memory with 6 memory overlays of extended libraries that can talk to the other libraries, a "Shell" called the Command Line Interpreter or MDOS prompt that can do just about any disk management feature one can imagine, and supports TI/Myarc/CC FDC's, RS232's, a SCSI card, and soon to be released IDE and TIPI cards as well.

 

Some of the code can be difficult to follow as there is so much memory paging involved and several examples of various object files using the same label code in their sources that can be confusing, however, IT WORKS, and it works well.  It has a single DSR while in "TI-99/4A mode" that pretty much if you can plug it into the PEBox, it will talk to it with very few exceptions of incompatible hardware.  That same DSR is smart enough to know whether you are calling it from TI-99/4A mode, or MDOS mode.  And in MDOS mode it can really unleash its power.

 

Imagine in about 5 lines of code, being able to change to any of the text or graphic modes, load or save a file, or call any of a hundred or more routines without adding all the extra VMBW, VSBR, DSRLNK, etc. code to your source.  If you want to write text to a graphics screen, you don't need to figure out the character pattern and where to write each pixel.  You just give it the string and call the library function and MDOS does it for you.

 

If anyone ever wanted to learn assembly language, I would tell them to start off with programming in MDOS mode on the Geneve as those XOP (library) calls gets you well on your way with minimal effort as you learn more about assembly.

 

Anyways, my 2 cents.  Am I a bit biased, perhaps <grin>.

 

Beery

  • Like 2

Share this post


Link to post
Share on other sites

One of the most impressive pieces of code that I saw was Thierry's bootstrap code for his IDE card, using the NVRAM of the real-time clock RTC-65271. The RAM of the clock is organized as 128 pages of 32 bytes, so you really cannot write longer sequences of code, and you always have to map into the next page. Nevertheless, he managed to install a bootloader from several of these 32-byte pages into main memory which downloaded a second-stage bootloader, which in turn pulled the DSR from the IDE drive into the IDE DSR space, and then comes the Master title screen. By that concept, the IDE card does not need any EPROM or FlashROM.

 

See also this posting:

 

  • Like 2

Share this post


Link to post
Share on other sites
On 1/8/2021 at 12:34 AM, Airshack said:

An especially frustrating example of non-commented Martian-Assembly is the Boone MBX code.

Help @Tursi if you get bored and need a new TI project ;)

You obviously have not tried his archiver code! 😃

 

Share this post


Link to post
Share on other sites

Two examples of very read-able code our Edgar Dohmann (data biotics) and Ken Culp - Simplified Assembler.

Share this post


Link to post
Share on other sites
1 hour ago, dhe said:

You obviously have not tried his archiver code! 😃

Nah! I’m just trying to get others to help with deciding the MBX code. Not at all being critical of Boone as a programmer. Just, the MBX code is frustratingly challenging due to no comments.

  • Like 1

Share this post


Link to post
Share on other sites

... but I've heard real programmers use machine code...

 

 

1247970838_MachineCode.thumb.png.c9d1aabc8e72a5af64ea116635c5ac34.png

 

... not confusing things like... 

 

Perl.thumb.png.89f8745da3b8d7cea5902fc1517ae1e2.png

 

...but me, what the heck do I know, I'm just a lowly...

 

 

BASIC.thumb.png.10b8b58b2b8385c15ad269621dbe0dde.png

 

... and I can't wrap my head around ...

 

forth-lisp-snobol-cartoon.thumb.png.625516cb9d8af3b847d787209628b150.png

 

  • Like 4

Share this post


Link to post
Share on other sites
On 1/7/2021 at 9:43 PM, Tursi said:

Just comment it. Uncommented assembly code might as well be Martian. Even if you can tell what he's saying, you've no idea what he's talking about. ;)

 

Avoiding fancy tricks, break the code up into functions... nothing so different from what makes any other code good. ;)

 

It ultimately depends on what your goal is - if you want other people to read it, code like you mean it. ;)

 

Well said!

 

For me, comments explaining how the code works are more important than explaining the instructions.   Long ago when I was first dabbling in assembly, someone in our Milwaukee user group shared his commented code with me.  I didn't get much value from comments like "LI R0,1    * load register 0 with 1" or "C  R0,R1  *compare R0 to R1" but I did glean a lot from how he documented the routines and the expected operation.

 

I'm not sure I agree with avoiding fancy tricks, especially when commented well ;) 

 

  • Like 2

Share this post


Link to post
Share on other sites

Comments should describe what you intend to do, and why. They shall not describe what you are doing, since anybody who knows coding can see that by reading the instructions. Those who don't know coding aren't likely to read your program anyway.

This is true for any language, by the way.

  • Like 2

Share this post


Link to post
Share on other sites
1 hour ago, apersson850 said:

Comments should describe what you intend to do, and why. They shall not describe what you are doing, since anybody who knows coding can see that by reading the instructions. Those who don't know coding aren't likely to read your program anyway.

This is true for any language, by the way.

Ideally it should do both, in case you are using some esoteric method that is such spaghetti code that t cannot be unwound easily

assume the next person that maintains your code will be looking at it 20 years later, and is not comfortable in the dialect of the code you are running

(been there, currently doing that, should order the t-shirt)

  • Like 3

Share this post


Link to post
Share on other sites
3 hours ago, InsaneMultitasker said:

Well said!

 

For me, comments explaining how the code works are more important than explaining the instructions.   Long ago when I was first dabbling in assembly, someone in our Milwaukee user group shared his commented code with me.  I didn't get much value from comments like "LI R0,1    * load register 0 with 1" or "C  R0,R1  *compare R0 to R1" but I did glean a lot from how he documented the routines and the expected operation.

 

I'm not sure I agree with avoiding fancy tricks, especially when commented well ;) 

 

The competent programmer is fully aware of the strictly limited size of his own skull; therefore he approaches the programming task in full humility, and among other things he avoids clever tricks like the plague.

  • Like 5

Share this post


Link to post
Share on other sites
3 hours ago, TheBF said:

The competent programmer is fully aware of the strictly limited size of his own skull; therefore he approaches the programming task in full humility, and among other things he avoids clever tricks like the plague.

That was a very interesting lecture to read, thank you for linking that.   Somewhat to the point, I wasn't thinking about tricks as code written to intentionally obfuscate its own purpose nor to proclaim its greatness.  The 9900 allows for some neat things like self-modifying code and speed-enhancing qualities e.g. running routines from scratchpad, which some including myself might never have even considered without seeing working, commented code from others that went beyond what the self-learning books offered.  For quite some time I even thought the E/A Utility subprograms (VSBW, VMWB, KSCAN) were the only proper methods to access video and keyboard; seeing home-spun, faster routines was to me quite a feat/trick that I would probably not have considered - were it not for commented code.  

  • Like 1

Share this post


Link to post
Share on other sites
8 hours ago, InsaneMultitasker said:

I'm not sure I agree with avoiding fancy tricks, especially when commented well ;) 

If you are writing your code to be /readable/, then yes, avoid fancy tricks. Fancy tricks are not readable code. That's why they are called "fancy tricks".

 

However, when you DO use fancy tricks, comment the hell out of them. "Avoid" doesn't mean "Never". GOTO all you like. Just explain why. ;)

 

  • Like 1

Share this post


Link to post
Share on other sites

Another way to put it is my favorite old one on debugging:

 

"Debugging is twice as hard as coding. Therefore, if you code as cleverly as possible, you are not, by definition, clever enough to debug your own code." ;)

 

  • Like 3
  • Haha 1

Share this post


Link to post
Share on other sites
12 hours ago, apersson850 said:

Comments should describe what you intend to do, and why. They shall not describe what you are doing, since anybody who knows coding can see that by reading the instructions. Those who don't know coding aren't likely to read your program anyway.

This is true for any language, by the way.

Indeed! Hear Hear! Totally agree!

  • Like 1

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...