| |
Sasq
Registered: Apr 2004
Posts: 155 |
Wanted: Source codes (for badass)
In order to improve my assembler it would be great to try it on existing projects.
So if you have sources for demos/intros/games that you don't mind sharing it would be kind if you could send them my way, and I'll try to get them working in bass.
They need to be buildable the normal way (Kickass, Acme or whatever) so I can compare the output binaries...
(this also means that if your type of demos requires special tools there is a greater chance I will include such functionality in bass).
-- sasq64@gmail.com |
|
... 65 posts hidden. Click here to view all posts....
|
| |
JackAsser
Registered: Jun 2002
Posts: 1995 |
Quote: Sure, what you call the suffix is no too important :)
Probably .8 .b .zp .z should all be synonyms
And .w .16 .abs
Hear hear |
| |
Peiselulli
Registered: Oct 2006
Posts: 81 |
ACME :
You can force ACME to use a specific addressing mode by adding "+1",
"+2" or "+3" to the assembler mnemonic. Each one of these postfixes
sets the relevant "Force Bit" in ACME's result. If Force Bit 3 is set,
ACME will use 24-bit addressing. Force Bit 2 means 16-bit addressing
and Force Bit 1 means 8-bit addressing. Higher Force Bits have higher
priorities.
Here's an (overly complicated) example:
symbol1 = $fb
symbol2 = $fd
symbol3+3 = $ff ; set Force Bit 3 and store in symbol's flags
ldx $fa
ldy+2 $fc ; set Force Bit 2 (16-bit addressing)
lda+3 $fe ; set Force Bit 3 (24-bit addressing)
stx symbol1
sty+2 symbol2 ; set Force Bit 2 (16-bit addressing)
sta symbol3 ; no need to set Force Bit 3 as it is
; already set in "symbol3".
will be assembled to
a6 fa ; ldx $fa
ac fc 00 ; ldy $00fc
af fe 00 00 ; lda $0000fe
86 fb ; stx $fb
8c fd 00 ; sty $00fd
8f ff 00 00 ; sta $0000ff
from:
https://github.com/meonwax/acme/blob/master/docs/AddrModes.txt |
| |
Krill
Registered: Apr 2002
Posts: 2855 |
ACME never ceases to amaze me over and over again with its creative syntax. =) |
| |
tlr
Registered: Sep 2003
Posts: 1728 |
I'm pondering a bit about syntax for referencing symbols in different scopes... towards inner scopes I guess 'outer.inner.symbol'... is a reasonable syntax, but what about the parent scope, or an absolute reference, i.e from the global scope?
Python3 uses .global and .nonlocal key words to specify the bindings of variables in the current scope, but I'd personally prefer something directly in the symbol reference.
Parent scope could be @p.symbol and global @g.symbol perhaps? Not entierly happy with that though.
Any personal favorites here?
(Maybe this should be in a new thread as it's a generic assembly syntax question, but it's useful for the discussion here as well.) |
| |
Krill
Registered: Apr 2002
Posts: 2855 |
Quoting tlrwhat about the parent scope, or an absolute reference, i.e from the global scope? Just a quick shot without thinking much about it, but what about a ".." prefix to go up/out one scope, similar to traversing folder structures? Would be something like "..outer.inner" to reach a same-level scope's inner symbol. Could be enhanced for "..." to go up two scopes, etc.
A fully qualified path starting from the global scope could be prefixed with ":", e.g., ":scope.child.grandchild".
@p.* and @g.* sure are not pretty. :) |
| |
tlr
Registered: Sep 2003
Posts: 1728 |
Quote: Quoting tlrwhat about the parent scope, or an absolute reference, i.e from the global scope? Just a quick shot without thinking much about it, but what about a ".." prefix to go up/out one scope, similar to traversing folder structures? Would be something like "..outer.inner" to reach a same-level scope's inner symbol. Could be enhanced for "..." to go up two scopes, etc.
A fully qualified path starting from the global scope could be prefixed with ":", e.g., ":scope.child.grandchild".
@p.* and @g.* sure are not pretty. :)
I've thought about '..' as well. Somewhat analogous to file system paths but I'm not fully happy with that either. In 64tass '..' is the string concatenation operator, and that's quite nice.
':' would be similar to Amiga OS path specifiers I guess. An alternative would be a '/' analogous to a *nix path. I prefer ':' though.
I couldn't find a good comparison on how this works in different languages. |
| |
Krill
Registered: Apr 2002
Posts: 2855 |
Quoting tlrI couldn't find a good comparison on how this works in different languages. ":" is more "languagy" compared to "/". :) See https://en.wikipedia.org/wiki/Scope_resolution_operator and maybe also https://erlang.org/doc/reference_manual/expressions.html#functi.. or https://www.w3.org/TR/1999/REC-xml-names-19990114/#ns-qualnames.
".." for string concatenation... hmm, does "+" not work due to ambiguities or so? :) |
| |
tlr
Registered: Sep 2003
Posts: 1728 |
Quote: Quoting tlrI couldn't find a good comparison on how this works in different languages. ":" is more "languagy" compared to "/". :) See https://en.wikipedia.org/wiki/Scope_resolution_operator and maybe also https://erlang.org/doc/reference_manual/expressions.html#functi.. or https://www.w3.org/TR/1999/REC-xml-names-19990114/#ns-qualnames.
".." for string concatenation... hmm, does "+" not work due to ambiguities or so? :)
Thanks for the links!
Do you mean languagy (<- is that even a word :) as in computer languagy? I've never seen '..' used for this purpose. Feels a bit messy syntax-wise to me as the scope separator uses the same descriptor as the reference to the parent scope, especially if referencing to parents higher up, e.g '....scope1.scope2.label', etc...
I guess that could be relieved with something like '(..).scope1' or similar. Maybe (/).scope1 would work for global?
I believe '+' does not work for that purpose in 64tass because constants may be (always?) 'bit strings'. This means concatenation is a valid operation and is different from addition.
Soci might be able to elaborate on this. |
| |
soci
Registered: Sep 2003
Posts: 474 |
"+" is for numerical sum only because calculations may be performed with strings. For example 1 - 'a' + 'z' is 26 (if letters are encoded in a sequence). Therefore concatenation must have a different operator.
As for means of access to a specific parent scope (without using it's name) I see little value in that. It's a good idea to name labels meant for cross-scope access unique while stacking up scopes. That way there's no confusion over which label or scope in which parent scope is referenced in a child.
If there's an "lp2" two levels up which needs access but there's another "lp2" in the current or the immediate parent and writing "something.lp2" isn't an option either (as "something" was reused too) then adding an unnamed parent access on top of that won't really improve the situation in my opinion. |
| |
tlr
Registered: Sep 2003
Posts: 1728 |
Quoting sociAs for means of access to a specific parent scope (without using it's name) I see little value in that. It's a good idea to name labels meant for cross-scope access unique while stacking up scopes. That way there's no confusion over which label or scope in which parent scope is referenced in a child.
I'm thinking this might be useful for exporting a label beyond something akin to your .block or .proc scope, e.g having an entry point different than the first byte in the block.
But having said that, how to you access a named parent scope in 64tass? |
| Previous - 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 - Next |
