Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.sys.apple2.programmer > #3836 > unrolled thread

Max line length of a 6502 source

Back to article view | Back to comp.sys.apple2.programmer

Contents

  Max line length of a 6502 source roger.shimada@gmail.com - 2017-08-24 20:10 -0700
    Re: Max line length of a 6502 source mmphosis <mmphosis@macgui.com> - 2017-08-25 19:08 +0000
    Re: Max line length of a 6502 source Michael J. Mahon <mjmahon@aol.com> - 2017-08-25 15:46 -0500
      Re: Max line length of a 6502 source roger.shimada@gmail.com - 2017-08-26 07:48 -0700
      Re: Max line length of a 6502 source Michael Pohoreski <michael.pohoreski@gmail.com> - 2017-08-28 07:35 -0700
    Re: Max line length of a 6502 source Hugh Hood <hughhood@earthlink.net> - 2017-08-26 10:53 -0500
    Re: Max line length of a 6502 source James Davis <JPD.Enterprises@outlook.com> - 2017-08-26 17:08 -0700
      Re: Max line length of a 6502 source Michael Barry <barrym95838@yahoo.com> - 2017-08-26 21:15 -0700
        Re: Max line length of a 6502 source Brian Patrie <bpatrie@bellsouth.spamisicky.net> - 2017-08-27 00:48 -0500
          Re: Max line length of a 6502 source Michael J. Mahon <mjmahon@aol.com> - 2017-08-27 01:54 -0500
        Re: Max line length of a 6502 source "James Davis" <JPD.Enterprises@Live.com> - 2017-08-27 08:49 -0700
    Re: Max line length of a 6502 source John Brooks <jbrooks@blueshiftinc.com> - 2017-08-27 12:42 -0700
      Re: Max line length of a 6502 source Hugh Hood <hughhood@earthlink.net> - 2017-08-27 18:45 -0500
        Re: Max line length of a 6502 source John Brooks <jbrooks@blueshiftinc.com> - 2017-08-27 21:30 -0700
          Re: Max line length of a 6502 source Hugh Hood <hughhood@earthlink.net> - 2017-08-28 22:42 -0500
            Re: Max line length of a 6502 source John Brooks <jbrooks@blueshiftinc.com> - 2017-08-28 21:40 -0700
              Re: Max line length of a 6502 source Hugh Hood <hughhood@earthlink.net> - 2017-08-29 00:58 -0500
            Re: Max line length of a 6502 source Michael Pohoreski <michael.pohoreski@gmail.com> - 2017-08-29 09:47 -0700
    Re: Max line length of a 6502 source David Schmenk <dschmenk@gmail.com> - 2017-08-28 10:42 -0700
      Re: Max line length of a 6502 source Michael Pohoreski <michael.pohoreski@gmail.com> - 2017-08-28 11:34 -0700
      Re: Max line length of a 6502 source gids.rs@sasktel.net - 2017-08-28 14:43 -0700
        Re: Max line length of a 6502 source Michael Pohoreski <michael.pohoreski@gmail.com> - 2017-08-29 09:27 -0700
          Re: Max line length of a 6502 source gids.rs@sasktel.net - 2017-08-29 21:15 -0700
            Re: Max line length of a 6502 source Michael Pohoreski <michael.pohoreski@gmail.com> - 2017-08-29 23:45 -0700
            Re: Max line length of a 6502 source Michael J. Mahon <mjmahon@aol.com> - 2017-08-30 02:04 -0500
              Re: Max line length of a 6502 source gids.rs@sasktel.net - 2017-08-30 11:35 -0700
                Re: Max line length of a 6502 source Michael Pohoreski <michael.pohoreski@gmail.com> - 2017-08-30 22:30 -0700
                  Re: Max line length of a 6502 source Michael J. Mahon <mjmahon@aol.com> - 2017-08-31 01:09 -0500
                    Re: Max line length of a 6502 source Andrew Roughan <andrew.roughan@writeme.com> - 2017-09-05 11:08 +0000
                Re: Max line length of a 6502 source Michael J. Mahon <mjmahon@aol.com> - 2017-08-31 01:09 -0500
        Re: Max line length of a 6502 source ewerst@msn.com - 2017-08-29 10:11 -0700
          Re: Max line length of a 6502 source gids.rs@sasktel.net - 2017-08-29 21:20 -0700
            Re: Max line length of a 6502 source Michael Pohoreski <michael.pohoreski@gmail.com> - 2017-08-29 23:18 -0700
            Re: Max line length of a 6502 source Michael J. Mahon <mjmahon@aol.com> - 2017-08-30 02:04 -0500

Page 2 of 2 — ← Prev page 1 [2]

#3856

On Monday, August 28, 2017 at 11:42:58 AM UTC-6, David Schmenk wrote:
> On Thursday, August 24, 2017 at 8:10:55 PM UTC-7, roger....@gmail.com wrote:
> > Hi folks,
> > 
> > I'll be posting a 6502 program on comp.sys.apple2 soon. It's under $80 bytes long, so I will include the source in the post.
> > 
> > I use a cross assembler and have a self-imposed line length limit of 79 columns.
> > 
> > If that's too wide, what's the max line length of assemblers that any of you are _currently_ using?
> > 
> > Thanks for your thoughts.
> 
> To throw another wrench in the discussion, I went to 16 character tab stops years ago in my assembly code. I really appreciate the extra room for descriptive labels. I'm tired of trying to decipher 7 character label meanings. Instead of including listing directly into usenet posts, I'd use a link to the file on GitHub.
> 
> Dave...


I am the exact opposite.

There is a little known punctuation character that allows to type a remark.  My biggest pet peeve is these big long labels that annoy the hell out of me and make the source listing bloated.

And talking about remarks, WTF!  Why do people have to encircle their remarks with tons of dashes or star symbols?  This does not make that little heading stand out any better.  Again, more bloat ware.  I always spend a couple of days on source just to get rid of that excess bloat.

Has no-one heard of the term KISS (keep it simple stupid)?

[toc] | [prev] | [next] | [standalone]

#3864

> And talking about remarks, WTF!  Why do people have to encircle their remarks with tons of dashes or star symbols? 

Because some of us like to separate the _macro_ from the _micro._

When we read a physical book the physical _page_ size is a spatial "break".  It is the reason we place each new chapter on a NEW page -- to break up the signal.  I coined the term "anti-noise" because S:N is an incomplete term.  I use the term S:N:~N where ~N means anti-noise.  WTF is anti-noise? **Whitespace.**  Whitespace is JUST as important as the signal.

Youdon'treadsentanceswithoutanyspaces,doyou?

QED.

I don't anyone who enjoys reading a WALL of TEXT without any line breaks.  We use blank lines to BREAK up the signal into "visible groupings"

Same thing for code.  The _last_ thing I want to read is one long "page" of visual vommit:

Foo:
    lda
    sta
    rts
Bar:
    lda
    sta
    lda
    sta
    rts
Qux:
    lda
    sta
    rts

Blank lines are better ...

Foo:
    lda
    sta
    rts

Bar:
    lda
    sta
    lda
    sta
    rts

Qux:
    lda
    sta
    rts

... but from a macro POV everything STILL blends together.

Instead by introducing _whitespace_ along with a LINE separator it breaks up the _macro_ to be MUCH more readable:

; ==========
Foo:
    lda
    sta
    rts

; ==========
Bar:
    lda
    sta
    lda
    sta
    rts

; ==========
Qux:
    lda
    sta
    rts


> This does not make that little heading stand out any better.

Maybe not for _you_ but for me and others it does GREATLY -- it is like night and day.


>  I always spend a couple of days on source just to get rid of that excess bloat. 

And I'll spend 5 mins to ADD it back in. :-)

[toc] | [prev] | [next] | [standalone]

#3868

On Tuesday, August 29, 2017 at 10:27:22 AM UTC-6, Michael Pohoreski wrote:
> > And talking about remarks, WTF!  Why do people have to encircle their remarks with tons of dashes or star symbols? 
> 
> Because some of us like to separate the _macro_ from the _micro._
> 
> When we read a physical book the physical _page_ size is a spatial "break".  It is the reason we place each new chapter on a NEW page -- to break up the signal.  I coined the term "anti-noise" because S:N is an incomplete term.  I use the term S:N:~N where ~N means anti-noise.  WTF is anti-noise? **Whitespace.**  Whitespace is JUST as important as the signal.
> 
> Youdon'treadsentanceswithoutanyspaces,doyou?


This example is pretty much the very reason I don't do Macros.  Macros are like trying to read a line without spaces.  And I am relating to when the Macro is being used and not when it is being defined.


> 
> QED.
> 
> I don't anyone who enjoys reading a WALL of TEXT without any line breaks.  We use blank lines to BREAK up the signal into "visible groupings"

FTR, I didn't say anything about not using line breaks or spaces.


> Same thing for code.  The _last_ thing I want to read is one long "page" of visual vommit:
> 
> Foo:
>     lda
>     sta
>     rts
> Bar:
>     lda
>     sta
>     lda
>     sta
>     rts
> Qux:
>     lda
>     sta
>     rts
> 
> Blank lines are better ...
> 
> Foo:
>     lda
>     sta
>     rts
> 
> Bar:
>     lda
>     sta
>     lda
>     sta
>     rts
> 
> Qux:
>     lda
>     sta
>     rts
> 
> ... but from a macro POV everything STILL blends together.
> 
> Instead by introducing _whitespace_ along with a LINE separator it breaks up the _macro_ to be MUCH more readable:
> 
> ; ==========
> Foo:
>     lda
>     sta
>     rts
> 
> ; ==========
> Bar:
>     lda
>     sta
>     lda
>     sta
>     rts
> 
> ; ==========
> Qux:
>     lda
>     sta
>     rts
>
>
> > This does not make that little heading stand out any better.
> 
> Maybe not for _you_ but for me and others it does GREATLY -- it is like night and day.

You're right!  It is more like night.  I can't see the code but maybe some can see better in the dark.  :)


>
> >  I always spend a couple of days on source just to get rid of that excess bloat. 
> 
> And I'll spend 5 mins to ADD it back in. :-)

Life would be so much simpler if we all thought the same way, wouldn't it?


From my POV, making a heading remark also breaks up the code, and I do do this.
This way says something meaningful about the code between headings.


; stands for foolish code
Foo:
    lda
    sta
    rts

; trying to set the bar higher
Bar:
    lda
    sta
    lda
    sta
    rts

; repeat foolish code -_-
Qux:
    lda
    sta
    rts

[toc] | [prev] | [next] | [standalone]

#3871

On Tuesday, August 29, 2017 at 9:15:03 PM UTC-7, gid...@sasktel.net wrote:
> Life would be so much simpler if we all thought the same way, wouldn't it?

/sarcasm Yeah, it would be nice if everyone thought like me. :-)

Joking aside, at first glance one would tend to think so but with someone analysis:

In the short term, yes. In the long run, no.

There are *both* pros & cons for:

* being homogeneous
* being heterogeneous

It doesn't really matter which one you pick.  You can _always_ find strengths and weaknesses to every system (or philosophy.)

Probably one of the best modern examples is CPU vs GPU processing.  CPU's excel at certain tasks (random access pointer deference) and suck for others (parallelization)  GPU's tend to the exact opposite -- completely suck at random access and dominate at parallelization.

Other examples are male & female, but you get the point.

That's what makes engineering such a complex topic.  You are balancing different trade-offs.

In code we see the same thing with brace / indent style. 
* https://en.wikipedia.org/wiki/Indent_style

Some want to cram as many lines of text as possible so they use the crappy verbose "the one true brace style" style, or worse, that Whitesmiths garbage.


> From my POV, making a heading remark also breaks up the code, and I do[n't] do this. 

That was the point though :-) It is like a "chapter break".

> This way says something meaningful about the code between headings. 
>
>; stands for foolish code 
>Foo: 
>   lda 
>   sta 
>    rts 
>
>; trying to set the bar higher 
>Bar: 
>    lda 
>    sta 
>    lda 
>    sta 
>    rts 
>
>; repeat foolish code -_- 
>Qux: 
>    lda 
>    sta 
>    rts 

Yup, that's not too bad.

Better, IMHO, is a (non-whitespace) visual separator as I feel whitespace doesn't do enough to break up the monotony.

[toc] | [prev] | [next] | [standalone]

#3873

<gids.rs@sasktel.net> wrote:
> On Tuesday, August 29, 2017 at 10:27:22 AM UTC-6, Michael Pohoreski wrote:
>>> And talking about remarks, WTF!  Why do people have to encircle their
>>> remarks with tons of dashes or star symbols? 
>> 
>> Because some of us like to separate the _macro_ from the _micro._
>> 
>> When we read a physical book the physical _page_ size is a spatial
>> "break".  It is the reason we place each new chapter on a NEW page -- to
>> break up the signal.  I coined the term "anti-noise" because S:N is an
>> incomplete term.  I use the term S:N:~N where ~N means anti-noise.  WTF
>> is anti-noise? **Whitespace.**  Whitespace is JUST as important as the signal.
>> 
>> Youdon'treadsentanceswithoutanyspaces,doyou?
> 
> 
> This example is pretty much the very reason I don't do Macros.  Macros
> are like trying to read a line without spaces.  And I am relating to when
> the Macro is being used and not when it is being defined.

I don't understand your point. Merlin expands macros one line per line, so
the parameter-substituted macro body is listed following the macro
invocation just as it would have been listed if it were not a macro,
followed by ENDM (in my usage). 

-- 
-michael - NadaNet 3.1 and AppleCrate II:  http://michaeljmahon.com

[toc] | [prev] | [next] | [standalone]

#3874

On Wednesday, August 30, 2017 at 1:04:10 AM UTC-6, mjm...@aol.com wrote:
> <Rob> wrote:
> > On Tuesday, August 29, 2017 at 10:27:22 AM UTC-6, Michael Pohoreski wrote:
> >>> And talking about remarks, WTF!  Why do people have to encircle their
> >>> remarks with tons of dashes or star symbols? 
> >> 
> >> Because some of us like to separate the _macro_ from the _micro._
> >> 
> >> When we read a physical book the physical _page_ size is a spatial
> >> "break".  It is the reason we place each new chapter on a NEW page -- to
> >> break up the signal.  I coined the term "anti-noise" because S:N is an
> >> incomplete term.  I use the term S:N:~N where ~N means anti-noise.  WTF
> >> is anti-noise? **Whitespace.**  Whitespace is JUST as important as the signal.
> >> 
> >> Youdon'treadsentanceswithoutanyspaces,doyou?
> > 
> > 
> > This example is pretty much the very reason I don't do Macros.  Macros
> > are like trying to read a line without spaces.  And I am relating to when
> > the Macro is being used and not when it is being defined.
> 
> I don't understand your point. Merlin expands macros one line per line, so
> the parameter-substituted macro body is listed following the macro
> invocation just as it would have been listed if it were not a macro,
> followed by ENDM (in my usage). 
> 
> -- 
> -michael - NadaNet 3.1 and AppleCrate II:  http://michaeljmahon.com


Most Macros I see are just separated by a semi-colon when more than one address or byte is used and no spaces such as

 mov byte;ZPadr

This gets especially hard to read since the semi-colon is already used as a remark indicator.  I see quite a bit of this in source listings.

 mov byte;ZPadr;just saving a byte to zero page


Granted there may be TAB characters in the listing or some other space separator, but this forces one to use a specific assembler.

[toc] | [prev] | [next] | [standalone]

#3875

On Wednesday, August 30, 2017 at 11:35:15 AM UTC-7, gid...@sasktel.net wrote:
byte is used and no spaces such as
> 
>  mov byte;ZPadr

I concur -- that's horrible!  Put some bloody whitespace in there to separates the comments from the mnemonics.  Plus it wouldn't hurt to align the comments in column X as well.

[toc] | [prev] | [next] | [standalone]

#3876

IMichael Pohoreski <michael.pohoreski@gmail.com> wrote:
> On Wednesday, August 30, 2017 at 11:35:15 AM UTC-7, gid...@sasktel.net wrote:
> byte is used and no spaces such as
>> 
>> mov byte;ZPadr
> 
> I concur -- that's horrible!  Put some bloody whitespace in there to
> separates the comments from the mnemonics.  Plus it wouldn't hurt to
> align the comments in column X as well.

That's not a comment, that is a macro call with two parameters. A comment
must be separated from the operand field by whitespace (and a semicolon if
there is no operand field). 

And parameters to macros are always separated by *some* punctuation, not
whitespace. 

I would have preferred something other than a semicolon, but comma was
rejected because it was expected to appear within parameters like (foo),y. 


Most well-developed macro schemes have a kind of "quote" that can enclose a
parameter that is stripped prior to substitution, allowing almost arbitrary
parameters, but Merlin doesn't have this capability. (I actually have quite
a long list of deficiencies in Merlin's macro capability, but that's a
different topic.)

Although semicolon is an annoying parameter separator, consider that in
practice many macros have zero or one parameter, requiring no separator. 

Mathematical function calls use (a,b,c) for parameter lists, and few
complain about that!

-- 
-michael - NadaNet 3.1 and AppleCrate II:  http://michaeljmahon.com

[toc] | [prev] | [next] | [standalone]

#3911

Michael J. Mahon <mjmahon@aol.com> wrote:
> Although semicolon is an annoying parameter separator, consider that in
> practice many macros have zero or one parameter, requiring no separator. 

An example of multiple parameters that springs to mind is Apple IIgs tool
calls using the super macros.

[toc] | [prev] | [next] | [standalone]

#3877

<gids.rs@sasktel.net> wrote:
> On Wednesday, August 30, 2017 at 1:04:10 AM UTC-6, mjm...@aol.com wrote:
>> <Rob> wrote:
>>> On Tuesday, August 29, 2017 at 10:27:22 AM UTC-6, Michael Pohoreski wrote:
>>>>> And talking about remarks, WTF!  Why do people have to encircle their
>>>>> remarks with tons of dashes or star symbols? 
>>>> 
>>>> Because some of us like to separate the _macro_ from the _micro._
>>>> 
>>>> When we read a physical book the physical _page_ size is a spatial
>>>> "break".  It is the reason we place each new chapter on a NEW page -- to
>>>> break up the signal.  I coined the term "anti-noise" because S:N is an
>>>> incomplete term.  I use the term S:N:~N where ~N means anti-noise.  WTF
>>>> is anti-noise? **Whitespace.**  Whitespace is JUST as important as the signal.
>>>> 
>>>> Youdon'treadsentanceswithoutanyspaces,doyou?
>>> 
>>> 
>>> This example is pretty much the very reason I don't do Macros.  Macros
>>> are like trying to read a line without spaces.  And I am relating to when
>>> the Macro is being used and not when it is being defined.
>> 
>> I don't understand your point. Merlin expands macros one line per line, so
>> the parameter-substituted macro body is listed following the macro
>> invocation just as it would have been listed if it were not a macro,
>> followed by ENDM (in my usage). 
>> 
>> -- 
>> -michael - NadaNet 3.1 and AppleCrate II:  http://michaeljmahon.com
> 
> 
> Most Macros I see are just separated by a semi-colon when more than one
> address or byte is used and no spaces such as
> 
>  mov byte;ZPadr
> 
> This gets especially hard to read since the semi-colon is already used as
> a remark indicator.  I see quite a bit of this in source listings.
> 
>  mov byte;ZPadr;just saving a byte to zero page

In Merlin, a comment requires whitespace prior to the "comment" semicolon.
Your example actually passes "just" as a third parameter to the macro. 

The operand field is terminated by the first blank/tab not in a quoted
string. The semicolon preceding a comment is, in fact, optional if there is
a non-blank operand field terminated by whitespace. 

-- 
-michael - NadaNet 3.1 and AppleCrate II:  http://michaeljmahon.com

[toc] | [prev] | [next] | [standalone]

#3866

> 
> I am the exact opposite.
> 
> There is a little known punctuation character that allows to type a remark.  My biggest pet peeve is these big long labels that annoy the hell out of me and make the source listing bloated.

Labels are like people.
Some are verbose without saying much.
Some are concise without saying enough.
The poet is concise yet verbose.

Tommy

[toc] | [prev] | [next] | [standalone]

#3869

On Tuesday, August 29, 2017 at 11:11:53 AM UTC-6, ewe...@msn.com wrote:
> > 
> > I am the exact opposite.
> > 
> > There is a little known punctuation character that allows to type a remark.  My biggest pet peeve is these big long labels that annoy the hell out of me and make the source listing bloated.
> 
> Labels are like people.
> Some are verbose without saying much.
> Some are concise without saying enough.
> The poet is concise yet verbose.
> 
> Tommy


And source code is like poetry?  What's your point?  :)

[toc] | [prev] | [next] | [standalone]

#3870

On Tuesday, August 29, 2017 at 9:20:00 PM UTC-7, gid...@sasktel.net wrote:
> And source code is like poetry?  What's your point?  :)

Tommy's beautifully written point was that:

* There is a balance to verbosity and compactness,
* Amateurs see code as just "text",
* Professionals see code as an art form -- the form is JUST as important as the function (because you write code for people to read,)
* Nirvana is when you can do more with less without general loss of readability.

Consider Boost's shit C++ code:
* http://www.boost.org/doc/libs/1_64_0/boost/crc.hpp

1,109 lines of typical bloated, over-engineered Crap++ when a mere -25- lines would do the same thing.  Whoever wrote that garbage needs to be taken out back and forced to use Cobol for the rest of their life.

If one isn't constantly thinking about how to express code in a clear, concise, compact manner then you're just an amateur code monkey.  (I'm not saying _you_ are -- I haven't seen enough of your code to know.)

[toc] | [prev] | [next] | [standalone]

#3872

<gids.rs@sasktel.net> wrote:
> On Tuesday, August 29, 2017 at 11:11:53 AM UTC-6, ewe...@msn.com wrote:
>>> 
>>> I am the exact opposite.
>>> 
>>> There is a little known punctuation character that allows to type a
>>> remark.  My biggest pet peeve is these big long labels that annoy the
>>> hell out of me and make the source listing bloated.
>> 
>> Labels are like people.
>> Some are verbose without saying much.
>> Some are concise without saying enough.
>> The poet is concise yet verbose.
>> 
>> Tommy
> 
> 
> And source code is like poetry?  What's your point?  :)
> 

Well-written source code is indeed like poetry! ;-)

Dijkstra (and others) have pointed out that most "well-documented" program
listings are like the visible part of an iceberg. The full specification of
the problem being solved and the derivation of the algorithm (and, for
Dijkstra, the proof that the algorithm actually satisfies the
specification) is usually much longer than the code itself. 

This is why most line-by-line comments in source code provide only handy
hints about what's going on and why.  (And often "how" the code is
implementing the algorithm needs documentation, too--not just "why".) 

Knuth has made the same point about "literate programming" and even wrote
programs to support combining the detailed documentation of the code with
the (extractable) source code. 

The source code for IBM's FORTRAN H compiler for the System 360 actually
prefixed a high-level algorithm description and mathematical derivation to
each procedure of the compiler, but that is one of the few programs I've
seen that provided such comprehensive "merged" documentation. 

Most interleaved commentary provides (and is expected to provide) only
hints and reminders of the correspondence between the code and the problem
being solved.  

The effectiveness of the comments can only be determined when someone who
has marginal familiarity with the code and the problem it purports to solve
(often the original author!) attempts to understand the code and modify it.


Whitespace (indentation, paragraphing, and pagination), naming, and
grouping are all important documentation tools, and I wouldn't want to lose
any of them. 

-- 
-michael - NadaNet 3.1 and AppleCrate II:  http://michaeljmahon.com

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | comp.sys.apple2.programmer

csiph-web