When It's Done. Soon, hopefully (for testing). Still a few missing features (like reusable labels) and poorly implemented ones (eg loading two plugins with the same name).Timendus wrote:I understand I can safely throw my implementation out of the window as soon as Brass 3 comes out When do you plan/hope to release it?
I wouldn't recommend throwing out your implementation, though. The more the merrier
The compilation process is reset state->first pass->reset state->second pass->generate output file->generate listing files. So, if a listing file generator (like the "veradoc" plugin) raises an error it won't affect the output of a valid binary.This should be an error (as it produces incorrect documentation for case-sensitive compilers)Documented name doesn't match compiled name (console.xyz in documentation, Console.XYZ in source).
This should be a warning though; I don't think it shouldn't compile just because there's no end of file marker - people outside our project will not like that kind of behaviour from their compilerFile doesn't have an end of file marker.
Yes, that's exactly how I saw it, though your comment raised another point; are "saferams" really variables? In some instances they are (plotsscreen and savesscreen are both bitmap variables). :\ Maybe have them as variables but call their type "scratchpad" or something?Concerning the routine, variable, constant thing; are we sure that those are the three things we want? Is that a logical distinction to make? In a way we now have "file" and "routine", it would make sense to add predefined memory locations to it (like saferams), I suppose that's what you have in mind with "variables"? And "constants" are things like val = 123 that don't point to locations in memory but define some value (link port writes, things like flags and stuff)?
Yes, that would make sense (and to logically extend it to routines as well).It would be fairly annoying to have to define every constant like this:Especially if we have a lot of them in something like vera.inc. And it would be completely pointless, seeing that most of the information is already in the statement LINKPORT = 0. Maybe we could allow that, but also allow to abbreviate that a bit to something like:Code: Select all
;; ### LINKPORT ### ;; ;; Defines the port that you need to write to for changing the ;; current of the link port lines ;; ;; Value: ;; 0 LINKPORT = 0
And have the docgen extract the name and the value automagically?Code: Select all
;; -###- ;; Defines the port that you need to write to for changing the ;; current of the link port lines LINKPORT = 0
Indeed(Of course, this would be hell for my parser, but seeing that Brass parses everything anyway..?)