The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
From: michael@kjorling.se (Michael Kjörling)
Subject: [TUHS] Discuss of style and design of computer programs from a
Date: Sat, 6 May 2017 15:20:53 +0000	[thread overview]
Message-ID: <20170506152053.GI12539@yeono.kjorling.se> (raw)
In-Reply-To: <20170506150913.57571411A@lod.com>

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1959 bytes --]

On 6 May 2017 08:09 -0700, from corey at lod.com (Corey Lindsly):
> Anyway, I reached one point in the assembly code that I simply could not 
> understand. It seemed like a mistake, and I went through it again and 
> again until I finally realized what it was doing. There was a branch/loop 
> that jumped to the middle of a multi-byte machine instruction, so that 
> branch had to be disassembled and stepped separately until it "synced" up 
> with the other branch again. Maybe this is standard practice in 
> programming (I don't know) but at the time I thought, what kind of evil 
> genius devised this to save a few bytes of memory?

IIRC, that _was_ a common trick at least on machines of that class. It
did have the potential to save a few bytes, yes (more if the
instructions were such that you'd get some _other, desired_, behavior
by jumping into the middle of one with some specific state), but it
also foiled lots of disassemblers: Simply disassembling a binary from
start to finish would yield nonsense in those locations, as you
experienced. It thus basically forced you to single-step those
instructions to figure out what was going on from the binary.

I'm pretty sure it works on every architecture with variable-length
instructions and arbitrary jump capability, as long as you have
control over the specific machine instructions generated (such as if
you are programming in assembler). Of course, it _is_ also a total
nightmare to maintain such code.

I would absolutely not say that doing something like that is standard
practice in modern programming. Even in microcontrollers, where
program and data memory can be scarce even today, I would argue that
the costs would not outweigh the benefits by a long shot.

-- 
Michael Kjörling • https://michael.kjorling.se • michael at kjorling.se
                 “People who think they know everything really annoy
                 those of us who know we don’t.” (Bjarne Stroustrup)


  reply	other threads:[~2017-05-06 15:20 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-05-05 15:20 [TUHS] Discuss of style and design of computer programs from a user stand point [was dmr note on BSD's sins] Clem Cole
2017-05-05 15:37 ` Bakul Shah
2017-05-06  2:16   ` Noel Hunt
2017-05-06  2:40     ` Toby Thain
2017-05-06  6:07     ` Bakul Shah
2017-05-06 22:11       ` Steve Johnson
2017-05-06 23:35         ` Larry McVoy
2017-05-07  4:06       ` Dan Cross
2017-05-07 13:49         ` [TUHS] Discuss of style and design of computer programs from a user stand point Michael Kjörling
2017-05-06  2:02 ` [TUHS] Discuss of style and design of computer programs from a user stand point [was dmr note on BSD's sins] Doug McIlroy
2017-05-06  5:33   ` Steve Johnson
2017-05-06  9:18     ` [TUHS] Discuss of style and design of computer programs from a user stand point Michael Kjörling
2017-05-06 13:09       ` Nemo
2017-05-06 13:44         ` Michael Kjörling
2017-05-06 14:40       ` Larry McVoy
2017-05-06 15:09         ` [TUHS] Discuss of style and design of computer programs from a Corey Lindsly
2017-05-06 15:20           ` Michael Kjörling [this message]
2017-05-06 15:24             ` Larry McVoy
2017-05-06 15:51               ` Michael Kjörling
2017-05-06 15:53                 ` Larry McVoy
2017-05-06 20:00             ` Steve Nickolas
2017-05-06 21:45               ` Michael Kjörling
2017-05-07  7:42                 ` Stephen Kitt
2017-05-06 15:23           ` ron minnich
2017-05-06 15:44             ` Michael Kjörling
2017-05-06 18:43         ` [TUHS] Discuss of style and design of computer programs from a user stand point Dave Horsfall
2017-05-06 19:50           ` Bakul Shah
2017-05-07  1:15             ` Warner Losh
2017-05-07  1:42               ` Noel Hunt
2017-05-07 13:54                 ` Michael Kjörling
2017-05-07 14:58                   ` arnold
2017-05-07 16:33                     ` Michael Kjörling
2017-05-07 15:13                 ` Warner Losh
2017-05-06 16:40       ` Kurt H Maier
2017-05-06 14:16     ` [TUHS] The Elements of Programming Style (book) - was Re: Discuss of style and design of computer programs Toby Thain
2017-05-07  0:51 [TUHS] Discuss of style and design of computer programs from a Nemo
2017-05-08 13:39 ` Tony Finch
2017-05-08 16:21   ` Steve Johnson
2017-05-08 17:01     ` Dan Cross

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20170506152053.GI12539@yeono.kjorling.se \
    --to=michael@kjorling.se \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).