6502.org Forum  Projects  Code  Documents  Tools  Forum
It is currently Sun Nov 10, 2024 4:27 am

All times are UTC




Post new topic Reply to topic  [ 28 posts ]  Go to page 1, 2  Next
Author Message
 Post subject: ANN: HXA v0.200
PostPosted: Mon Aug 26, 2013 4:09 pm 
Offline

Joined: Sun Nov 08, 2009 1:56 am
Posts: 410
Location: Minnesota
I think I managed to upload everything new to:

http://www.home.earthlink.net/~hxa

The "big" new thing is a built-in string stack, a feature I'm not aware of in any other assembler. I put it in to make implementing Garth's structured macros easier, and indeed they are much easier. http://home.earthlink.net/~hxa/demo/demo115.a is all of them implemented in a non-nesting, exhaustively commented manner. http://home.earthlink.net/~hxa/demo/demo115b.a uses macro nesting and minimal comments, but performs the same job in about in about 1/3 the file size. Perhaps there may be other uses for a string stack as well (it would be nice!).

There are a couple of other improvements of the "why didn't I do this before?" variety. A bug fix in Intel Hex output files (one which my test programs always told me was there but which I did not properly appreciate). That pesky 64K offset thing...I see why people like the Motorola S-file format, which can't suffer these problems.


Top
 Profile  
Reply with quote  
 Post subject: Re: ANN: HXA v0.200
PostPosted: Mon Aug 26, 2013 5:15 pm 
Offline
User avatar

Joined: Sun Jun 30, 2013 10:26 pm
Posts: 1948
Location: Sacramento, CA, USA
I've never used awk before, but it doesn't look impossible for me to understand (rather c-like, which I have used). Your source excites me into thinking that I might be able to write a template for my 65m32. But, first things first ... SPECS, SPECS, SPECS!!!

Thanks,

Mike


Top
 Profile  
Reply with quote  
 Post subject: Re: ANN: HXA v0.200
PostPosted: Mon Aug 26, 2013 5:55 pm 
Offline
User avatar

Joined: Thu May 28, 2009 9:46 pm
Posts: 8479
Location: Midwestern USA
teamtempest wrote:
I think I managed to upload everything new to:

http://www.home.earthlink.net/~hxa

A bit of amusing pedantry: the "sharp ('#') character" when used in telephony or computing is commonly referred to as an octothorpe (side-note: the Hayes AT command set used to control high end modems has a series of commands referred to as the octothorpe commands, so-named because each command has # in it). A sharp is an entirely different symbol: , as most musicians would be quick to note. :)

Use of an octothorpe as a pseudo-op prepend could create an interesting conflict in certain cases, as the octothorpe is used in syntax-compliant 6502 assembly language to denote immediate mode addressing. For example, what happens in HXA if I write and subsequently assemble LDA #ASSERT? How does (or can) HXA disambiguate ASSERT the pseudo-op from ASSERT the symbol?

Quote:
The "big" new thing is a built-in string stack, a feature I'm not aware of in any other assembler.

Nice feature.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!


Top
 Profile  
Reply with quote  
 Post subject: Re: ANN: HXA v0.200
PostPosted: Mon Aug 26, 2013 6:12 pm 
Offline
User avatar

Joined: Thu Dec 11, 2008 1:28 pm
Posts: 10975
Location: England
I think "hash" is the more usual name, although the # character does go by several names.
(With ref to http://home.earthlink.net/~hxa/hxa.htm#l49)
Cheers
Ed


Top
 Profile  
Reply with quote  
 Post subject: Re: ANN: HXA v0.200
PostPosted: Mon Aug 26, 2013 6:45 pm 
Offline
User avatar

Joined: Thu May 28, 2009 9:46 pm
Posts: 8479
Location: Midwestern USA
BigEd wrote:
I think "hash" is the more usual name, although the # character does go by several names.
(With ref to http://home.earthlink.net/~hxa/hxa.htm#l49)
Cheers
Ed

"Hash" seems to be quite common in the UK and Europe, and of course, there's the ubiquitous "hashtag" on Twitter. Over here, "pound" is occasionally used (as in "a gallon of water weighs 8#") or more commonly, "number" (e.g., #4 in a list). The octothorpe term (originally "octatherp") was said to have been coined at Bell Labs in the 1960s to avoid ambiguity vis a vis hash, pound, number, etc. Merriam-Webster attests the word c. 1971. I recall it from the late 1970s in modem technical literature (it's mentioned in the old Bell 103 standard).

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!


Last edited by BigDumbDinosaur on Wed Aug 28, 2013 4:15 am, edited 1 time in total.

Top
 Profile  
Reply with quote  
 Post subject: Re: ANN: HXA v0.200
PostPosted: Tue Aug 27, 2013 1:10 am 
Offline

Joined: Sun Nov 08, 2009 1:56 am
Posts: 410
Location: Minnesota
Thanks for the link Ed; it took me a bit to understand what BDD was driving at:

Code:
Use of an octothorpe as a pseudo-op prepend could create an interesting conflict in certain cases, as the octothorpe is used in syntax-compliant 6502 assembly language to denote immediate mode addressing. For example, what happens in HXA if I write and subsequently assemble LDA #ASSERT? How does (or can) HXA disambiguate ASSERT the pseudo-op from ASSERT the symbol?


The symbol with so many names is allowed because it's so C-ish - you can write "#include" rather than ".include" (or simply "include"), if you so desire.

Disambiguation is straightforward and, I imagine, pretty much the same between all assemblers, as they all have to deal with the problem of labels that match built-in or user-defined names.

In this case, once HXA identifies "LDA" as a cpu mnemonic, it treats the remainder of the line as the operand of "LDA". It will identify the "#" as flagging immediate mode, but "ASSERT" will have no special meaning.

"ASSERT" will also most likely not be a defined symbol - or at least I can't see how you could assign a value to it to get it into the symbol table in the first place. Trying to use it in an equate, as in "ASSERT = some_expr", and you'll get a message saying "= some_expr" can't be parsed. HXA sees "ASSERT" in the expression as a pseudo op, so the remainder of the line is supposed to be a conditional expression constituting whatever test is appropriate. Same thing if you try to use it before a macro name or CPU mnemonic. Try to use a line consisting of just "ASSERT", which normally assigns the current program counter value to a label, gets you an "unexpected blank field" message, as again HXA wants to see a conditional expression following this pseudo op.

So "LDA #ASSERT" would be treated as a forward reference, to be resolved during the second pass, when the value of "ASSERT" is known. Since that will never happen, there will eventually be a "name not found" message.

Of course the ultimate test of whether I'm right is to try it and see :wink:


Top
 Profile  
Reply with quote  
 Post subject: Re: ANN: HXA v0.200
PostPosted: Tue Aug 27, 2013 7:08 am 
Offline
User avatar

Joined: Thu May 28, 2009 9:46 pm
Posts: 8479
Location: Midwestern USA
teamtempest wrote:
Thanks for the link Ed; it took me a bit to understand what BDD was driving at:

Code:
Use of an octothorpe as a pseudo-op prepend could create an interesting conflict in certain cases, as the octothorpe is used in syntax-compliant 6502 assembly language to denote immediate mode addressing. For example, what happens in HXA if I write and subsequently assemble LDA #ASSERT? How does (or can) HXA disambiguate ASSERT the pseudo-op from ASSERT the symbol?

The symbol with so many names is allowed because it's so C-ish - you can write "#include" rather than ".include" (or simply "include"), if you so desire.

I'm just a big dumb dinosaur who primarily writes assembly language for the 65xx family, so I don't consider C-ish features to be of any value unless I'm writing something in C (which I do fairly regularly). Since # has been the operator used by both Motorola and MOS Technology reference assemblers to denote immediate mode addressing, using it in an unrelated way in the same source code seems to be somewhat confusing. In other words, mixing language elements may inadvertently make for a more difficult environment in which to work, or at the least, cause one to incur a learning curve that is not entirely warranted. This may not be an issue with someone who is just starting out with 6502 assembly language—they don't have a point of reference, but it can become one with someone who is familiar with and has worked with the official standards on which countless of lines of code have been developed (I estimate I've written at least a half million lines of 6502 assembly language over the years—POC's ROM has some 12,000 lines alone, and a project I did on the Commodore 128/Lt. Kernal combination was close to 100,000 lines).

Quote:
Disambiguation is straightforward and, I imagine, pretty much the same between all assemblers, as they all have to deal with the problem of labels that match built-in or user-defined names.

Not really. I've used assemblers of one sort or another for over 43 years (6502 assemblers since 1977) and the commercially-developed ones have always been careful to disambiguate things like pseudo-ops, macros and symbols. The old IBM assembler used on some mainframes used a dot to prepend pseudo-ops, which feature got carried into C programs (e.g., .TEXT, .DATA, .BSS, etc.). The assembler used on MAI Basic Four minis, as well as Point 4 minis, also used a dot to distinguish pseudo-ops from symbols, macros and mnemonics. Ditto for the two popular Commodore-developed 8-bit assemblers: MADS and DevPak. Also, ditto for the Kowalski assembler, André Fachat's XA assembler and others.

Quote:
In this case, once HXA identifies "LDA" as a cpu mnemonic, it treats the remainder of the line as the operand of "LDA". It will identify the "#" as flagging immediate mode, but "ASSERT" will have no special meaning.

"ASSERT" will also most likely not be a defined symbol - or at least I can't see how you could assign a value to it to get it into the symbol table in the first place. Trying to use it in an equate, as in "ASSERT = some_expr", and you'll get a message saying "= some_expr" can't be parsed. HXA sees "ASSERT" in the expression as a pseudo op, so the remainder of the line is supposed to be a conditional expression constituting whatever test is appropriate. Same thing if you try to use it before a macro name or CPU mnemonic. Try to use a line consisting of just "ASSERT", which normally assigns the current program counter value to a label, gets you an "unexpected blank field" message, as again HXA wants to see a conditional expression following this pseudo op.

So "LDA #ASSERT" would be treated as a forward reference, to be resolved during the second pass, when the value of "ASSERT" is known. Since that will never happen, there will eventually be a "name not found" message.

Of course the ultimate test of whether I'm right is to try it and see :wink:

I bring all this up not to bust your chops in any way (anyone that can write a comprehensive macro assembler is not an average programmer) but to highlight grey areas where something may not act as it one might, from experience, expect. A programmer should be free to use any symbol name s/he wants, as long as it is not an MPU instruction mnemonic and complies with the structure and length defined by the assembler. Conceivably, ASSERT could be used to define, say, a bit pattern that might control hardware in some way (e.g., "assert" a signal). As ASSERT is a pseudo-op in HXA and can be used without a prepend, the unsuspecting programmer could be driven to drink trying to use ASSERT as a symbol, since there is no obvious reason why it shouldn't work. I suspect more than a few programmers would classify that as a bug.

If it were me, I'd enforce the requirement that all pseudo-ops be prepended with a dot, as that has been the formal standard since the earliest days of the 6502—and well before the microprocessor even existed. This would eliminate the name collision part, since the assembler could not possibly mistake .ASSERT (for example) with ASSERT.

I have not tried out your assembler as yet, but I am also curious about how it behaves if a macro and a symbol happen to share the same name. For example, in my integer math library that I've put together, I have a function (subroutine) called IMEMFACA, which copies an integer from memory to an accumulator. I also have a macro of the same name that is structured to assemble the mumbo-jumbo needed to call IMEMFACA. The Kowalski assembler cheerfully accepts the fact that a macro and a subroutine both have the name IMEMFACA (in fact, IMEMFACA the macro invokes IMEMFACA the subroutine), and does not get confused, since the macro table is separate from the symbol table. This capability is of sufficient importance to me that I would not use an assembler at all that couldn't differentiate between macros and symbols of the same name.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!


Top
 Profile  
Reply with quote  
 Post subject: Re: ANN: HXA v0.200
PostPosted: Tue Aug 27, 2013 7:37 am 
Offline
User avatar

Joined: Fri Aug 30, 2002 1:09 am
Posts: 8538
Location: Southern California
Quote:
If it were me, I'd enforce the requirement that all pseudo-ops be prepended with a dot

I would prefer a choice. Vertical alignment, indentation, white space, etc. are very important for visual factoring; but where you want a group of things to start in the same column, a dot in front of one or more of them makes it look at first glance like they're indented slightly. After the short time it takes to look right at it and determine that it was not intentionally indented, it just looks messy. I suppose it could be backed up one space so the dot is out in the margin, but it again looks messy. Fortunately it's easy to tell assembler directives apart from 6502 mnemonics though since the latter are always three letters and the former usually aren't.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?


Top
 Profile  
Reply with quote  
 Post subject: Re: ANN: HXA v0.200
PostPosted: Tue Aug 27, 2013 2:07 pm 
Offline
User avatar

Joined: Sun Jun 30, 2013 10:26 pm
Posts: 1948
Location: Sacramento, CA, USA
BigEd wrote:
I think "hash" is the more usual name, although the # character does go by several names.


A friend of mine from college used to call it 'mesh', and it caught on with me at the time (he was a far superior coder, and was probably doing it as an inside joke, referring to INTERCAL). Today, I use 'pound' more than anything else, but I don't know if it's a regional thing (California) or simply an idiosyncrasy.

If you look up INTERCAL, be prepared to smile at its intentional ridiculousness.

Mike


Top
 Profile  
Reply with quote  
 Post subject: Re: ANN: HXA v0.200
PostPosted: Tue Aug 27, 2013 3:30 pm 
Offline

Joined: Sun Nov 08, 2009 1:56 am
Posts: 410
Location: Minnesota
Quote:
I've used assemblers of one sort or another for over 43 years (6502 assemblers since 1977) and the commercially-developed ones have always been careful to disambiguate things like pseudo-ops, macros and symbols.


I confess I have not investigated thoroughly, but my impression after writing my own assembler is that conventions along those lines - labels must start in column one or must end with a colon, for example - apply to disambiguation only in the sense that it's faster and easier to figure out what a token represents if there's only one way to write it (it also makes the assembler itself easier to write). Whether it makes the user's task easier is a separate consideration, although certainly after working with a particular assembler's conventions long enough, reading source code meant for it becomes "natural".

One reason HXA tries to be a bit accomodating of different conventions is to permit potential converts write in a style that they're used to, rather than force them to learn a whole new set. That's why it accepts numeric literals in any of Motorola or Intel or C formats (eg, '$FF' or '0FFH' or '0xFF'), for instance.

But one can adapt to a new style. I was influenced by the Merlin assemblers, whose pseudo ops are all three characters (sorry, Garth!) and do not use a period prefix. But I've decided I like the period prefix, so for my own code that's what I use. Heck, I stole a lot of things from other assemblers that I decided I liked :D

Quote:
the unsuspecting programmer could be driven to drink trying to use ASSERT as a symbol, since there is no obvious reason why it shouldn't work.


I would hope not - any attempt to define it as a symbol should generate an error message, and any attempt to use it without defining it should also generate an error message. In fact...

Quote:
This capability is of sufficient importance to me that I would not use an assembler at all that couldn't differentiate between macros and symbols of the same name


Oh, I'm afraid you wouldn't like HXA very much then. Using the same name for two different things seems to me a great source of potential confusion on the part of anyone who doesn't know exactly how such things are resolved by a particular assembler. That the names are in separate tables doesn't matter; that the assembler itself doesn't lose track doesn't matter; what matters is that people aren't nearly as good at it as computers. So when it's possible I explicitly disallow it:

Code:
# verify global name is unique

global function CKgoodname(this) {

    # all current callers have done this already

#    this = toupper( this )

    if ( this !~ SYMglobal ) {
        UMerror( "NeedGlb", this )
        return( FALSE )
    }

    if ( SYMexists(this) || PSOPispseudo(this) || \
            MACismacro(this) || INSisop(this) || EXPisfunc(this) ) {
        UMdupname( this )
        return( FALSE )
    }

    return( TRUE )
}


"People" in this context includes "people who did not write what they are reading", eg., other programmers. Maintainers perhaps, or the merely curious, but in any case people who may not know what the conventions of the assembler used are. They may not have heard of it, or can't find its documentation. Even so, they ought to be afforded a fighting chance of understanding what they're reading.

Alas, then, to use your macro to set up a function call in HXA, you'd have to disambiguate them :D


Top
 Profile  
Reply with quote  
 Post subject: Re: ANN: HXA v0.200
PostPosted: Tue Aug 27, 2013 6:44 pm 
Offline
User avatar

Joined: Thu Dec 11, 2008 1:28 pm
Posts: 10975
Location: England
(Do people say, for example, pound-include rather than hash-include? I've never heard it, but of course I live in deepest hash-land. Anyone ever been heard to say octothorpe-include? Seems unlikely to me...)


Top
 Profile  
Reply with quote  
 Post subject: Re: ANN: HXA v0.200
PostPosted: Tue Aug 27, 2013 6:52 pm 
Offline

Joined: Sat Dec 13, 2003 3:37 pm
Posts: 1004
BigEd wrote:
(Do people say, for example, pound-include rather than hash-include? I've never heard it, but of course I live in deepest hash-land. Anyone ever been heard to say octothorpe-include? Seems unlikely to me...)


I'm of the "pound include" camp.

Octothorpe doesn't quite roll of the tongue.


Top
 Profile  
Reply with quote  
 Post subject: Re: ANN: HXA v0.200
PostPosted: Tue Aug 27, 2013 7:01 pm 
Offline
User avatar

Joined: Thu May 28, 2009 9:46 pm
Posts: 8479
Location: Midwestern USA
BigEd wrote:
(Do people say, for example, pound-include rather than hash-include? I've never heard it, but of course I live in deepest hash-land. Anyone ever been heard to say octothorpe-include? Seems unlikely to me...)

At least when talking about C programs, I just say "include." If talking about assembly language I say "load immediate" for something like LDA #$12. It seems # is just one of those symbols that makes for awkward speech. :roll: Most of the use I've seen of octothorpe is in hardware technical literature—as wartung noted, the word tends to be a tongue-tripper.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!


Top
 Profile  
Reply with quote  
 Post subject: Re: ANN: HXA v0.200
PostPosted: Tue Aug 27, 2013 7:15 pm 
Offline
User avatar

Joined: Thu Dec 11, 2008 1:28 pm
Posts: 10975
Location: England
Indeed, it's a long name. I've no objection to anyone preferring it, but it seems a shame to perpetrate that name into a document...

Cheers
Ed


Top
 Profile  
Reply with quote  
 Post subject: Re: ANN: HXA v0.200
PostPosted: Tue Aug 27, 2013 8:22 pm 
Offline
User avatar

Joined: Fri Aug 30, 2002 1:09 am
Posts: 8538
Location: Southern California
I have never heard of the word "octothorpe." The Forth number-conversion words <# # #S and #> are pronounced "less-sharp," "sharp," "sharp-ess," and "sharp-greater" though.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?


Top
 Profile  
Reply with quote  
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 28 posts ]  Go to page 1, 2  Next

All times are UTC


Who is online

Users browsing this forum: No registered users and 4 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to: