Brass - 1.0.5.3 update [06/02/2014]

Post by **benryves** » Fri 07 Jul, 2006 3:19 pm

Further minor fixes (same 'special' link as above) plus it now evaluates ternaries from left->right rather than from right->left like the other expressions. Right->left might seem odd but is correct - consider the following:

Code: Select all

1-1-1 = -1
[1]-[1-1] (working left->right) = +1 (wrong)
[1-1]-[1] (working right->left) = -1 (correct)

Hopefully a 1.0.5.0 can be officially released soon with the various large and small parsing bugs ironed out. Sorry for the inconvenience.

King Harold · Post by **King Harold** » Sun 20 Aug, 2006 9:35 am

is this a bug?

(Huge screenshot)

in case you cant see the pic (blocked or whatever) it doesnt like

Code: Select all

b_callnz(_Arc_Unarc)

b_callnz would appear black (should be orange) and _Arc_Unarc purple
I dont know whether its latenite or brass, but tasm+notepad doesnt mind b_callnz and compiled it just fine.
latenite + brass is way cool anyway

Edit by benryves: linked large image.

Andy_J · Post by **Andy_J** » Sun 20 Aug, 2006 5:04 pm

Just a stab in the dark, but by looking at that screenshot I would think it might be bcall_nz, since it's bcall instead of b_call. Try that, and if it doesn't work let Ben figure something out with it.

King Harold · Post by **King Harold** » Sun 20 Aug, 2006 5:40 pm

Funny you should mention that, my Ti83+ inc file said it was b_call and i had to put in "bcall" manually..
i was lazy and didnt put bcallnz in, so my source had b_callnz..
BUT i allready knew that so i tried bcallnz, didnt work either

Post by **benryves** » Mon 21 Aug, 2006 10:56 am

If in doubt, look in headers.asm:

Code: Select all

.define bcall(label) rst rBR_CALL \ .dw label
.define bcallz(label) jr nz,$+5 \ rst rBR_CALL \ .dw label
.define bcallnz(label) jr z,$+5 \ rst rBR_CALL \ .dw label
.define bcallc(label) jr nc,$+5 \ rst rBR_CALL \ .dw label
.define bcallnc(label) jr c,$+5 \ rst rBR_CALL \ .dw label
.define bjump(label) call 50h \ .dw label	
.define bjumpz(label) jr nz,$+7 \ call 50h \ .dw label
.define bjumpnz(label) jr z,$+7 \ call 50h \ .dw label
.define bjumpc(label) jr nc,$+7 \ call 50h \ .dw label
.define bjumpnc(label) jr c,$+7 \ call 50h \ .dw label

No underscores.

More importantly - a major bug in Brass <= 1.0.4.5 has been identified (none of the ZIDX instructions will work properly!)

Please update to Brass 1.0.4.6

If using Latenite, copy it over Brass.exe in the .\Compile directory.

Post by **benryves** » Wed 30 Aug, 2006 9:20 am

Some minor tweaks to Brass:

.ds directive - this just does the same thing as .fill, but defaults to fill with $00 instead of $FF.
Check validity of labels before adding - that way, if you forget a macro definition you can't end up having bcall(_whatever) as a label. It will try and guess what is wrong and display a slightly more helpful error message.
DateTime.TryParse replaced with my own DateTimeTryParse - this was causing a crash (unsupported) under Mono.
Modified a few file functions - these were affecting file systems that were picky over case or difference between / and \.

I have kept stating "it works in Mono!" in the past, but hadn't done too extensive testing - I just assumed that as it ran and assembled some basic test cases, it was fine (though I knew about the DateTime glitch after AndySoft alerted me to it).

As you are probably aware, I know approximately this much -><- about Linux. I don't have the capability to download large distributions for testing purposes, but did remember I had a Knoppix disk lying around so had a go with that.

There we go, it assembles CoBB's pinball.asm quite merrily. No comments about my running as root or choice of text editor, please.

Nostromo, which is a huge project and uses a lot of the advanced features of Brass (enumerations, structures, nested modules, variables and so on) also assembles fine under Mono.

I hope to test more and more under Linux/Mono to ensure that it is a viable option for those use using non-Windows operating systems.

CoBB · Post by **CoBB** » Wed 30 Aug, 2006 9:45 am

benryves wrote:As you are probably aware, I know approximately this much -><- about Linux. I don't have the capability to download large distributions for testing purposes, but did remember I had a Knoppix disk lying around so had a go with that.

Again, use coLinux, if you don't need a GUI (although that's also possible with the help of an X server running on Cygwin). You can save the hassle of rebooting then. I used it with success for my thesis project to run the Hume compiler that's only available as a Linux binary. Just grab a Debian image (a 1-gig one should be sufficient, although you might want a bigger one for safety), set up your apt sources to unstable (Mono is available there to my knowledge) and just apt-get dist-upgrade to make sure everything works properly before installing the mono package.

Post by **kv83** » Wed 30 Aug, 2006 9:59 am

He has no i-net connection @home, and he can't download that large files on school I guess

That's why he didn't used it till now

CoBB · Post by **CoBB** » Wed 30 Aug, 2006 11:25 am

There's no need for that. He can prepare an image anywhere with a fast connection, and use it offline.

Post by **benryves** » Wed 30 Aug, 2006 11:31 am

CoBB wrote:Again, use coLinux, if you don't need a GUI (although that's also possible with the help of an X server running on Cygwin).

I downloaded it, but the installer needs to download a disk image once it's running (and without an internet connection, that was pretty difficult). If I knew exactly which bits and pieces I needed to run it, I'd gladly do so (as long as the entire thing is < 100MB).

I'm not rebooting, I'm running Knoppix in the (now freeware) Virtual PC 2004.

CoBB · Post by **CoBB** » Wed 30 Aug, 2006 1:01 pm

benryves wrote:I downloaded it, but the installer needs to download a disk image once it's running (and without an internet connection, that was pretty difficult). If I knew exactly which bits and pieces I needed to run it, I'd gladly do so (as long as the entire thing is < 100MB).

That's unlikely, since you'd need to install a 'full enough' Linux distribution on it.

benryves wrote:I'm not rebooting, I'm running Knoppix in the (now freeware) Virtual PC 2004.

Well, if it's fast enough, then there's no need to change indeed.

Post by **benryves** » Tue 26 Sep, 2006 5:45 pm

OK, I've been planning a few things for Brass 2 (to go alongside Latenite 2). There are many changes, hopefully you'll approve

Future of Brass

Brass is not in a great shape. It started well, but has steadily degenerated into an unmaintainable mess. This is not good.

Sure enough, it does a lot, and I have tried hard to keep it a good assembler. It works, but there are several things that really should be addressed.

Much like Latenite 2, it has started development, but is going very slowly due to my current workload. At least I can (hopefully!) tell you what my plans are for a new version, so that you can add your input and thoughts.

Plugin-Driven Design

Brass.exe currently does everything. This means that if you want a new feature, you have to ask me. How about this, instead - all Brass.exe does is parse the basic syntax of the source files, provides an expression parser and handles modules and labels for you. It delegates all the actual assembling, data insertion and output generation into a variety of external programs.

Brass is a .NET application, which means that the plugins could be developed in any .NET-friendly language (C#, C++, VB, J# and so on). Hopefully this would encourage people to develop their own plugins. There would be a number of basic plugins that would be important to Brass...

Assembler Plugin

This plugin would perform the actual assembling of a source file. Brass.exe would take a line of code (eg "ld a,10"), split it into tokens (in this case, something like { "LD", "A", Comma, "10" }), and pass it to a function in the assembler. The assembler would examine it, and return that yes, it could handle that sort of thing and it's of type LdAImmediate, it's 2 bytes in size and it would like you to evaluate and pass back the fourth token next time, please. Brass.exe has no idea what 'LdAImmediate' means, but when it runs pass two it sends this back along with the fourth token evaluated as requested and the plugin passes back a byte array { 0x3E, 0x0A }.

The way expressions are passed to the assembler needs a bit of thought - for example, when you have "ld a,(ix+1)" the assembler needs to know you have { "LD", "A", OpenParen, "IX", AdditionOperator, "1", CloseParen } - but it could demand to have tokens AdditionOperator and "1" fused as a single expression and, and use this as the value it needs.

The advantages of this sort of layout are huge! Speed is the big one. Currently, Brass is abysmally slow for a number of idiotic reasons. For example, when it runs two passes, it parses the entire source layout twice! This way it would only have to parse it once. Even better, it could cache the syntax layout of a source file in a temporary file and load this if it detects the file hasn't changed.

This will be extremely important when I put real-time syntax highlighting and error detection (talking to the assembler) in Latenite 2's new text editor. In fact, Latenite 2 shouldn't even need a build button... just a save one, and the output binary is built as you go. Groovy.

Output Plugin

So, we've use our assembler plugin to generate some sort of binary... we need to write it do disk, somehow! Enter the output plugin. At the end of a successful build, Brass sends a list of pages, on each of which is a list of byte ranges (in each of which is a list of the bytes to output), and the output plugin turns these into a file.

Data Plugin

Need to include data from your own bizarre file format? Want to apply your own special compression to a particular binary? Write a data plugin for it.

...and so on. Hopefully that makes sense.

If you have any ideas, questions, or comments, I'd be glad to hear them.

Development is still at very early stages (crude parser, not even any assembling being done), due to the workload.

KermMartian · Post by **KermMartian** » Tue 26 Sep, 2006 6:08 pm

/me requests a more manageable list format (one that doesn't make a 1.2mb HTML file for my shell's list file). Perhaps a selectable html/textonly option? Also, label display in the list file would be nice. Otherwise, I have no complaints with this excellent assembler.

Post by **benryves** » Tue 26 Sep, 2006 6:22 pm

The list file generation is pretty broken anyway, if it's generating anything you're one of the lucky few who don't breathe too hard to stop it working

KermMartian · Post by **KermMartian** » Tue 26 Sep, 2006 6:32 pm

Hehe, nice. Well, I look forward to these excellent-sounding improvements then.