Brass 3.0.0.0 Beta 10 wrote:Historically, the source has been assembled twice, and plugins decide what action to take based on the pass (typically creating labels and incrementing the program counter in the first pass, then writing output in the second pass). The result is that each plugin gets called twice and has to maintain its state. This can cause headaches for plugins that control the flow through the assembler, as they might do one thing on one pass, then a label will have been created or assigned differently the next time they're run which makes them take a different decision.
The new design is that everything happens in the first pass, so functions and directives only get invoked once. However, this causes a different problem - how can we, for example, jump forwards if the label we wish to jump to hasn't been created yet? The solution is to be able to write dynamic output data. This writes an empty chunk of data, but lets the plugin writing the data register a delegate that will be called after compilation so it can go back and write the data it needs to.
This has not been extensively tested, so consider this experimental. Let me know if you have problems with invalid or erroneous output.
The contiguous data plugin has been removed. Something offering similar functionality will need to be added.
Compiler.Compile() no longer throws exceptions, storing all error data in the error list.
Compiler.FindFreeMemoryBlock() handles output data larger than one byte correctly.
Internal fix to label resolution to prevent the internal label from being accidentally set to a null reference (this caused the error-reporting code to throw a null reference exception instead of the missing label's name).
Exception is spelled, well, exception. Only one of the new exception types was spelled correctly (all the others were spelled "Expection"). Cheers to gameprograma for spotting this!
Brass 3.0.0.0 Beta 13
- benryves
- Maxcoderz Staff
- Posts: 3088
- Joined: Thu 16 Dec, 2004 10:06 pm
- Location: Croydon, England
- Contact:
Thank God, proof that Ben is still human!benryves wrote:Exception is spelled, well, exception. Only one of the new exception types was spelled correctly (all the others were spelled "Expection"). Cheers to gameprograma for spotting this!
http://clap.timendus.com/ - The Calculator Link Alternative Protocol
http://api.timendus.com/ - Make your life easier, leave the coding to the API
http://vera.timendus.com/ - The calc lover's OS
http://api.timendus.com/ - Make your life easier, leave the coding to the API
http://vera.timendus.com/ - The calc lover's OS
- benryves
- Maxcoderz Staff
- Posts: 3088
- Joined: Thu 16 Dec, 2004 10:06 pm
- Location: Croydon, England
- Contact:
Lots of fixes; get it here. (I hope the new project builder is to your liking, driesguldolf).Brass 3.0.0.0 Beta 11 wrote:Replacement of the old GUI builder application with a new project builder.
A label resolution bug has been fixed.
Some error messages were being reported as always occuring on the last line of the last file that was assembled. This has been corrected.
The IntelHex output writer plugin has been fixed to work with data output more than one byte at a time. This fixes plugins that rely on IntelHex too (such as the TI application ones).
The TI application plugins (.appheader and .branch) have been rewritten (they weren't functional in the last beta).
.while now supports assignments in its conditional.
Fixed a bug where Compiler.GetUniquePageIndices() was returning an empty array.
I have replaced the zip utilty class with one I wrote myself.
All namespaces for Brass 3 itself have been moved into a parent BeeDevelopment namespace.
Unicode arrow characters were removed from the .asciimap directive documentation.
- driesguldolf
- Extreme Poster
- Posts: 395
- Joined: Thu 17 May, 2007 4:49 pm
- Location: $4080
- Contact:
-
- Calc King
- Posts: 1513
- Joined: Sat 05 Aug, 2006 7:22 am
- benryves
- Maxcoderz Staff
- Posts: 3088
- Joined: Thu 16 Dec, 2004 10:06 pm
- Location: Croydon, England
- Contact:
If you mean the project builder, then that was written from scratch (apart from the HTML outputting stuff).King Harold wrote:That was there already, wasn't it? (for a very long time, too)
Hm, not a cryptic message about IOutputWriter not being in assembly Brass.exe is it? It sometimes appears when running the help viewer in Release mode from within Visual Studio on my machine (never in Debug nor running the Release version from Explorer). I'm not sure why; could be a working directory bug?I get an error when I click on Brass Help (or press F1), the help thing immediately errors and dies, apart from that, nice
-
- Calc King
- Posts: 1513
- Joined: Sat 05 Aug, 2006 7:22 am
- benryves
- Maxcoderz Staff
- Posts: 3088
- Joined: Thu 16 Dec, 2004 10:06 pm
- Location: Croydon, England
- Contact:
Hm, probably because it's not being run alongside a debugger (ie, VS). I'll see if I can fix it.
I only released the new website on the first of this month, so it's pretty new.
I only released the new website on the first of this month, so it's pretty new.
-
- Calc King
- Posts: 1513
- Joined: Sat 05 Aug, 2006 7:22 am
- driesguldolf
- Extreme Poster
- Posts: 395
- Joined: Thu 17 May, 2007 4:49 pm
- Location: $4080
- Contact:
Strange things are going on here...
Image:
The bugs don't occur when I do this (though it does double the error):
But they do with this code: (no label from below is defined at this point)
Image:
The bugs don't occur when I do this (though it does double the error):
Code: Select all
a=b
c=b+3
Code: Select all
updatelcd = sysvarsa
updatelcd.addr = updatelcd+1
copyerase = sysvarsa+3
copyerase.addr = copyerase+1
- benryves
- Maxcoderz Staff
- Posts: 3088
- Joined: Thu 16 Dec, 2004 10:06 pm
- Location: Croydon, England
- Contact:
Cheers for the bug report. Looks like there are still more bugs and quirks to fix in the error reporting stage, then, should be pretty easy to fix.
I discovered the cause of the help viewer crashing (at least on my PC) - older plugins that are no longer in development or use that are sitting in the application directory that try and reference long-dead (or changed) interfaces. Try deleting all .dll files from the Brass install directory, then reinstalling. (The next version of the help viewer handles this problem more gracefully, with a dialog telling you it couldn't load plugin Plugin.dll).
I've noted that keyboard shortcuts don't work properly in the project builder (they get stolen by IE); I've also started adding rudimentary debugging capabilities (so far it's a case of hit F5 and it'll run a program of your choice passing the name of the compiled file as a command-line argument).
I discovered the cause of the help viewer crashing (at least on my PC) - older plugins that are no longer in development or use that are sitting in the application directory that try and reference long-dead (or changed) interfaces. Try deleting all .dll files from the Brass install directory, then reinstalling. (The next version of the help viewer handles this problem more gracefully, with a dialog telling you it couldn't load plugin Plugin.dll).
I've noted that keyboard shortcuts don't work properly in the project builder (they get stolen by IE); I've also started adding rudimentary debugging capabilities (so far it's a case of hit F5 and it'll run a program of your choice passing the name of the compiled file as a command-line argument).
- driesguldolf
- Extreme Poster
- Posts: 395
- Joined: Thu 17 May, 2007 4:49 pm
- Location: $4080
- Contact:
Luckily it's only in the error reporting, everything worked after fixing the mistakes.benryves wrote:Cheers for the bug report. Looks like there are still more bugs and quirks to fix in the error reporting stage, then, should be pretty easy to fix.
So we can make a batch file and immediately send it to an emulator? Sounds very useful!benryves wrote:I've also started adding rudimentary debugging capabilities (so far it's a case of hit F5 and it'll run a program of your choice passing the name of the compiled file as a command-line argument).
I'm also missing the .global and .local directives... Of course a workaround is easy (redefine them on top level in case of .global), it isn't really aesthetic.
And because they are defined twice, this could cause an error where you accidentally change one of the labels causing infinite headaches
- benryves
- Maxcoderz Staff
- Posts: 3088
- Joined: Thu 16 Dec, 2004 10:06 pm
- Location: Croydon, England
- Contact:
The idea behind debugging is that after a build, a plugin of your own invention can be run, and is passed an instance of the compiler that just built the project. It can therefore use this to access all of the information about the program you just built.
For the moment, the only debugger I've written looks for two labels - Debugger.Path and Debugger.Args (can be set in the project file or your code) then launches Debugger.Path with Debugger.Args, so you can load your project in the project builder, hit F5 and your program is built and loaded in an external program.
For the moment, the only debugger I've written looks for two labels - Debugger.Path and Debugger.Args (can be set in the project file or your code) then launches Debugger.Path with Debugger.Args, so you can load your project in the project builder, hit F5 and your program is built and loaded in an external program.
- driesguldolf
- Extreme Poster
- Posts: 395
- Joined: Thu 17 May, 2007 4:49 pm
- Location: $4080
- Contact:
And this confirms my narrow knowledge of computer programming... (and yet I program for a calc, hehe)benryves wrote:The idea behind debugging is that after a build, a plugin of your own invention can be run, and is passed an instance of the compiler that just built the project. It can therefore use this to access all of the information about the program you just built.
This is of course way better applicable then my simple idea.
But still, what happened to .global and .local?
- benryves
- Maxcoderz Staff
- Posts: 3088
- Joined: Thu 16 Dec, 2004 10:06 pm
- Location: Croydon, England
- Contact:
I guess I never got around to writing them. Feel free to do so yourself, that's the basic idea here!driesguldolf wrote:But still, what happened to .global and .local?
.local isn't required (or practical) given the new entirely-modular label system. .global would be rather useful, though, I can see that.