Brass - 1.0.5.3 update [06/02/2014]

[King Harold]

That's what I was asking: did you only fix the ASCII bug or did you implement experimental syntax highlighting right away. And

Brass 1 will never provide that functionality.

makes it quite clear: you only fixed the bug.
So, good luck with Brass 2

[King Harold]

I found a bug and it's nasty.

http://www.freewebs.com/lawcompany/ret%20p.PNG
Mod edit: Linkified picture. (You need ClearType).

when I go around it with jp m the next conditionally uses P will make a strange error. And no earlier versions did not do this.
Very odd..
P is not redefined, and sorry for breaking the layout a little it will get right after some posts anyway.

[benryves]

The reason is simple enough.

This should really not be done this way, it's a bad use of macros, and you've demonstrated why:

Code: Select all

.define p+	$70B8

(Last line).

That expands "ret p" into "ret + $70B8".

Don't use macros (designed for text replacement) for labels - use labels. Also, don't use operators in label or macro names.

*insert usual blurb about bullet-proof, centralised text parsing that is in Brass 2 that would have caught the invalid macro names earlier*

[King Harold]

eh weird, why doesnt it replace "p+" by $70B8..
Anyway, I replaced it with "p_+" just after I uploaded (and didnt upload the new one, sorry) bur its still doing this. Shouldn't it be trying to replace P by _+$70B8? which doesnt make sence?
(i'll just delete those lines and there I go..)
PS: whats with the linkified picture? I dont mind but.. why?

[benryves]

The macro name is a string, so it reads up until it finds the end of the name (in this case, "p"). The addition operator isn't a valid character for a name, so it assumes that everything after this is part of the macro.

Rename the label "pPlus" or "pAddition" or something along those lines. Do not use operators inside names. An operator is generally viewed as a seperator between two items. Hence kX-1 can cause problems - is that "kX-1" or is it "kX" - 1?

As for linking the picture; it's wide enough to cause a horizontal scrollbar on lower resolutions, or people not running their browser full-screen. This means that lines of text are broken off the end of the page, as this forum software isn't bright enough to allow for scrollable areas inside each post.

[King Harold]

Well, I changed them and it works. I feel like the idiot I am now.

[benryves]

Heh, no worries. Brass has a lousy expression/text parser hence it getting a bit confused.

I've reworked the new text parser (as described above) for Brass 2 and updated the plugin classes; now the Z80 assembler is starting to actually work properly. (It's > 8000 lines of code, automatically generated from a TASM table file, so rather scary to work with). Given that it's a vast list of switch/case blocks, rather than a primitive string-based matching system, the accuracy and performance increase should be worth it (imagine being able to use IXSomething as a label name and not get it picked up incorrectly by "ld a,(ix*)").

I'm trying to establish the best way to tie commands together. A LinkedList<Parser.Command> would be the best overall solution, but that loses the granularity of breaking commands into individual lines/files. Hmm. Maybe a SourceLine would be a List<LinkedListNode<Parser.Command>> or something. I'll have to figure something out.

[CoBB]

By the way, it might be a good idea to agree on Brass 2 syntax and features before the implementation really takes off. In other words, you should write the reference first.

[benryves]

What syntax are we talking about exactly here? Assembler syntax, directive syntax, all syntax, ...?

[CoBB]

Everything, of course, both to prevent the divergence of the documentation and the code and to have some peer review before committing yourself to some spec.

[KermMartian]

(Now I see what you meant about listing breaking, Ben. It gives me a dictionary/key error now that I upgraded to 1.0.4.6.)

[benryves]

There is no centralised, sensible way of breaking down source code into what I'm now calling 'commands', hence the list file stuff is a convoluted mess. Brass 2 will support list file plugins which can inspect the broken down commands/expressions/tokens.

Something for CoBB, and anyone else who is interested: syntax.txt

It's a work-in-progress, and needs to cover the interface between directive/assembler plugins more clearly. However, it does explain the workings of the expression parser, which is responsible for label generation.

[CoBB]

Thank you. I definitely agree with treating . and # equally as a directive marker. They don’t conflict with anything, so why not? Fast questions:

1. What characters are allowed in names? I presume that the same rules apply to labels, directives, module names and so on.
2. Is case insensitivity unicode aware or only applied to English letters?
3. How do you distinguish between expression commands and assembler commands? How do you determine their borders?
4. Will you allow * to denote the program counter? I hope not. I don’t think I’ve ever seen it used by anyone, fortunately.

[benryves]

Thank you. I definitely agree with treating . and # equally as a directive marker. They don’t conflict with anything, so why not? Fast questions:

1. What characters are allowed in names? I presume that the same rules apply to labels, directives, module names and so on.
2. Is case insensitivity unicode aware or only applied to English letters?
3. How do you distinguish between expression commands and assembler commands? How do you determine their borders?
4. Will you allow * to denote the program counter? I hope not. I don’t think I’ve ever seen it used by anyone, fortunately.

(1) is a point I should have addressed early on, but didn't get around to it. I'd rather have a list of characters which are not allowed rather than a list of characters that are allowed. Characters which would not be allowed would include any whitespace (tab or space), any character used in an operator, any character that is seen as punctuation ( ) [ ] , \, directive marker (# or .) and constant prefixes ($ % @). This is quickly off the top of my head, so if you can think of any further items that are definite no-nos, please tell me!

With regards to (2), all string and character manipulation is handled directly by the .NET framework, so it's in Microsoft's hands. I'd have thought that they'd implemented it within the framework, but I haven't verified it. I'll check up on that.

On a similar note; all text parsing will be forced to use the invariant culture. This means that the radix point is '.' regardless of machine locale.

For (3), hopefully this will become more apparent when I outline the methods an assembler/directive plugin has to expose. In a nutshell, the assembler plugin is passed an array of expressions and has to report back if it can match it (and also return some information relevant to assembling, such as instruction size). If this isn't matched, and the first expression in the array is seen to be an expression, this is seen as a new label statement (and so executed) and the rest of the command, minus the first label declaration, is sent back to the assembler plugin to try again.

I haven't covered this yet. I'll describe it in much finer detail with examples of the methods used in the text document.

For (4), no. $ is the instruction pointer, and given that all labels can have : stuck in front of them to return their page, I don't think # (current page) will return either.

With regard to labels, I also need to sort out modules. Chances are I'll use the . syntax (module.module.label) again, but I don't think I'll use TASM-style _ local labels. Reusable (+, -) labels too need looking into. I don't know if I'll drop the need to put { } around reusable labels - your thoughts on whether it makes the code too ugly or not would be valued!

I'll repost when I've updated the text file.

[CoBB]

Characters which would not be allowed would include any whitespace (tab or space), any character used in an operator, any character that is seen as punctuation ( ) [ ] , \, directive marker (# or .) and constant prefixes ($ % @). This is quickly off the top of my head, so if you can think of any further items that are definite no-nos, please tell me!

The tricky part is thinking in unicode again. You should exclude every kind of punctuation and white space, only allowing underscore and apostrophe (which is needed for shadow registers with your tokeniser; by the way, doesn’t that cause trouble with single-quoted literals?).

This means that the radix point is '.' regardless of machine locale.

This is a must. Also, keep in mind that even case conversions can be handled differently depending on locale (check dotted and dotless i in Tukic languages). You should exclude that too.

With regard to labels, I also need to sort out modules. Chances are I'll use the . syntax (module.module.label) again, but I don't think I'll use TASM-style _ local labels. Reusable (+, -) labels too need looking into. I don't know if I'll drop the need to put { } around reusable labels - your thoughts on whether it makes the code too ugly or not would be valued!

I’m not sure know if using . for module notation is the best solution, since it is already used for directives, and it’s probably not a good idea to allow them inside name literals. On the other hand, it’s the most appealing choice when it comes to visuals. Am I right to think that you’ll canonise label names internally as soon as they are parsed?

As for reusables, you could perhaps prefix them too with a special char, e.g. with backquote. That would take care of parsing difficulties.

Also, I’m still not convinced that an unknown name should be allowed to be implicitly defined as a label to the current PC. Sure, you’re thinking in terms of a sufficiently clever IDE, but it’s always an advantage if errors can be caught at language level.