| |
Slammer
Registered: Feb 2004 Posts: 416 |
Kick Assembler Thread 2
The previous thread took a little long to load, so this is a new fresh one.. |
|
... 592 posts hidden. Click here to view all posts.... |
| |
chatGPZ
Registered: Dec 2001 Posts: 11150 |
you cant - fucked up workarounds are needed as i said (and be sure you only have two possibilites as in your example - if you have three or more things become *really* fucking ugly =P)
one that works for two is to write it like this (yes its annoying)
blabla = DEBUG == 1 ? $1234 : $5678 |
| |
Cruzer
Registered: Dec 2001 Posts: 1048 |
How about this:
.var SomeVar1 = 0
.var SomeVar2 = 0
.if (DEBUG == 1) {
.eval SomeVar1 = $4000
.eval SomeVar2 = $4800
} else {
.eval SomeVar1 = $5000
.eval SomeVar2 = $5800
} Unless there's something consts can that vars can't. |
| |
Cruzer
Registered: Dec 2001 Posts: 1048 |
Making a label visible outside requires a workaround like this:
.var label = 0
.if (true) {
label2: nop
.eval label = label2
}
jmp label
Doesn't work if you wanna access it before though, which I gotta agree is quite annoying. |
| |
Slammer
Registered: Feb 2004 Posts: 416 |
Can you give me some 'real world' examples. I see two roads:
1. Create the possibility of multiple var declarations in the same var to ease the declarations outside the scope. Eg: .var a,b,c,d
2. Create some preparse commands, but I'm afraid to confuse people by having (Almost) the same functionality twice so I will need some code that shows how big the need are. |
| |
Frantic
Registered: Mar 2003 Posts: 1633 |
What about adding something kind of handling of scope levels? ...such as being able to define lables with global scope within a sub-scope, as well as making a variable visible in its parent scope(s).
.if (CONDITION1) {
.if (CONDITION2) {
.var @0SomeVar1 = $4000 ;Make visible in global scope
.var @-1SomeVar2 = $4800 ;Make visible in parent scope
.var @-2SomeVar3 = $5000 ;Make visible in two levels of parent scope
} else {
.var @0SomeVar1 = $8000 ;Make visible in global scope
.var @-1SomeVar2 = $8800 ;Make visible in parent scope
.var @-2SomeVar3 = $9000 ;Make visible in two levels of parent scope
}
.var @0SomeVar4 = SomeVar2*2
}
More or less this is how it works in a few other assemblers I have tried. ..and it also resembles common keywords in all sorts of languages like putting the "global" keyword in front of variable declarations within a scope (e.g. "global int SomeVar = 0x04800;". |
| |
Slammer
Registered: Feb 2004 Posts: 416 |
Frantic, That is a possibility. The notation is a bit cryptic but i will do the job. |
| |
Cruzer
Registered: Dec 2001 Posts: 1048 |
I still don't get why people wanna declare vars inside if-blocks. Can't they just assign them? Of course it requires more typing to declare them before, but as Slammer suggested, it might help if you could declare multiple vars in one statement. I don't think this is worth introducing a new notation for.
Accessing labels inside if-blocks I can see the need for, although it's very seldom that I have actually needed it. But it would be nice to be able to use them like any other local labels inside blocks:block:
.if (true) {
label: nop
}
jmp block.label Of course there should be an error if the if-condition is false, but that would be like any other reference to a non-existing label I guess. |
| |
Slammer
Registered: Feb 2004 Posts: 416 |
Yes. Examples is important to see whats nice or not. If xyz.myvar does the job then making hashtables implement this kind of notation is a nice solution.
.var opt = Hashtable()
.if(something)
.eval opt.myvar = 1234
else
.eval opt.myvar = 6789
jmp opt.myvar
It depends on the context in which the variables are used. |
| |
chatGPZ
Registered: Dec 2001 Posts: 11150 |
sorry to say, but this looks needlessly overcomplicated. you guys really never used .if/.endif like they were supposed to be used in any other assembler? i somehow cant believe this =) |
| |
Slammer
Registered: Feb 2004 Posts: 416 |
Its modelled after java/c++ and in this context it makes sence. There is also some evaluation concerns involved. You can evaluate a lot more with .if than a preparse #if and I guess if we make preparsing people will automaticly assume that you can put anything in the #if condition. Im not against preparsing and its absolutely a possibility, but I don't want to rush things and get alot of fixes that solves specific problems instead of one clean concept that can solve them all.
Can I see the code contructs you are using? Is it labels or options you are setting up this way?
Btw I just got a letter in my mailbox saying that I should demand tags on csdb in return for preparsing. :-)
Nothing is certain yet, but right now i'm considering a Kick Ass 4:
1. More flexible parse mekanism (Possiblity for ; as line comment,* instead of .pc and normal paranthesis instead of [] and leaving out : in front of macros/pseudocommands)
2. Possible to do 'skins' so you can support other assembler formats
3. Possibility to cover other processor types (while keeping the script language)
4. Making small constrains in the evaluations mekasnism to simplify the code in order to go open source.
5. Point 2 and 3 should be doable by plugins/ 3rd party development
So send me an example of 'ugly code' and preparsing will be taken into consideration.
|
Previous - 1 | ... | 33 | 34 | 35 | 36 | 37 | 38 | 39 | 40 | 41 | 42 | 43 | ... | 61 - Next |