MaxCoderz

for your 1 bit pleasure!

All times are UTC




Post new topic Reply to topic  [ 299 posts ]  Go to page Previous  1 ... 14, 15, 16, 17, 18, 19, 20  Next
Author Message
 Post subject:
PostPosted: Mon 16 Oct, 2006 4:51 pm 
Offline
Calc King

Joined: Sat 05 Aug, 2006 7:22 am
Posts: 1513
That's what I was asking: did you only fix the ASCII bug or did you implement experimental syntax highlighting right away. And
Quote:
Brass 1 will never provide that functionality.
makes it quite clear: you only fixed the bug.
So, good luck with Brass 2 :)


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Tue 17 Oct, 2006 2:51 pm 
Offline
Calc King

Joined: Sat 05 Aug, 2006 7:22 am
Posts: 1513
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.


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Tue 17 Oct, 2006 3:20 pm 
Offline
Maxcoderz Staff
User avatar

Joined: Thu 16 Dec, 2004 10:06 pm
Posts: 3064
Location: Croydon, England
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:
.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*


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Tue 17 Oct, 2006 5:45 pm 
Offline
Calc King

Joined: Sat 05 Aug, 2006 7:22 am
Posts: 1513
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?


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Tue 17 Oct, 2006 6:09 pm 
Offline
Maxcoderz Staff
User avatar

Joined: Thu 16 Dec, 2004 10:06 pm
Posts: 3064
Location: Croydon, England
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.


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Wed 18 Oct, 2006 7:48 am 
Offline
Calc King

Joined: Sat 05 Aug, 2006 7:22 am
Posts: 1513
Well, I changed them and it works. I feel like the idiot I am now.


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Wed 18 Oct, 2006 4:32 pm 
Offline
Maxcoderz Staff
User avatar

Joined: Thu 16 Dec, 2004 10:06 pm
Posts: 3064
Location: Croydon, England
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. ;)


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Wed 18 Oct, 2006 4:54 pm 
Offline
MCF Legend

Joined: Mon 20 Dec, 2004 8:45 am
Posts: 1601
Location: Budapest, Absurdistan
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. :)

_________________
The Independent Z80 Assembly Guide
Acelgoyobis
PindurTI


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Wed 18 Oct, 2006 5:05 pm 
Offline
Maxcoderz Staff
User avatar

Joined: Thu 16 Dec, 2004 10:06 pm
Posts: 3064
Location: Croydon, England
What syntax are we talking about exactly here? Assembler syntax, directive syntax, all syntax, ...?


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Wed 18 Oct, 2006 5:34 pm 
Offline
MCF Legend

Joined: Mon 20 Dec, 2004 8:45 am
Posts: 1601
Location: Budapest, Absurdistan
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.

_________________
The Independent Z80 Assembly Guide
Acelgoyobis
PindurTI


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Wed 18 Oct, 2006 10:02 pm 
Offline
Calc Wizard
User avatar

Joined: Tue 05 Jul, 2005 11:28 pm
Posts: 549
(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.)

_________________
Image Image Image


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Thu 19 Oct, 2006 10:27 am 
Offline
Maxcoderz Staff
User avatar

Joined: Thu 16 Dec, 2004 10:06 pm
Posts: 3064
Location: Croydon, England
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.


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Thu 19 Oct, 2006 4:29 pm 
Offline
MCF Legend

Joined: Mon 20 Dec, 2004 8:45 am
Posts: 1601
Location: Budapest, Absurdistan
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. :P I don’t think I’ve ever seen it used by anyone, fortunately.

_________________
The Independent Z80 Assembly Guide
Acelgoyobis
PindurTI


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Thu 19 Oct, 2006 5:21 pm 
Offline
Maxcoderz Staff
User avatar

Joined: Thu 16 Dec, 2004 10:06 pm
Posts: 3064
Location: Croydon, England
CoBB wrote:
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. :P 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.


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Thu 19 Oct, 2006 6:11 pm 
Offline
MCF Legend

Joined: Mon 20 Dec, 2004 8:45 am
Posts: 1601
Location: Budapest, Absurdistan
benryves wrote:
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?).

benryves wrote:
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.

benryves wrote:
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.

_________________
The Independent Z80 Assembly Guide
Acelgoyobis
PindurTI


Top
 Profile  
Reply with quote  
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 299 posts ]  Go to page Previous  1 ... 14, 15, 16, 17, 18, 19, 20  Next

All times are UTC


Who is online

Users browsing this forum: No registered users and 1 guest


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:  
cron
Powered by phpBB ® Forum Software © phpBB Group | DVGFX2 by: Matt