Yes, and in C, it is bitwise-AND. But those are when it's a binary operator. As a unary operator we can make it do something else. Assuming I can get my parser to cooperate.
It was just a thought anyway. Non-C people might be more confused by & than by @@@. I know I used to think & was an odd choice for address-of.
"Anyone have suggestions for alternatives to @@@?"
Yep. On my Finnish keyboard shift-4 produces a symbol that looks like some kind of rocket coming straight at me.
It is this ¤
I don't even remember now if that exists on "normal" USA/UK keyboards.
Thing is it really looks like it's telling me that something is "at" this point. Perhaps you could be the first to create any kind of language compiler that uses that symbol.
Does anyone know what that symbol is called and/or what it is actually supposed to mean?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
and if I remember it first come in ABC80 Swedish 8 Bit Z80 based computer.
Ps. Talar du svenska?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Nothing is impossible, there are only different degrees of difficulty. For every stupid question there is at least one intelligent answer If you don't ask you wont know If your gonna construct something, make it·as simple as·possible yet as versatile as posible
Sounds perfect for the job at hand, but I don't know if those outside Scandinavia can generate it easily.
I'm actually English but I've been camped out here in Helsinki for some years and never found anyone who could tell me what that ¤ is. No svenska sadly and my Finnish is still "ei hyvä"
Any other Propeller users in Helsinki or around out there ?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
In End of it Can You ad memory usage else after every obiect.
With to Big program....
Maybe compile that in adress range to big for Prop > 32Kb and generate Labels adresses But Not generate Binary image.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Nothing is impossible, there are only different degrees of difficulty. For every stupid question there is at least one intelligent answer If you don't ask you wont know If your gonna construct something, make it·as simple as·possible yet as versatile as posible
It can be very handy to optimize objects to Fit in memory.
Not in al circumstances objects must have al PRI routines. And that can help to find them.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Nothing is impossible, there are only different degrees of difficulty. For every stupid question there is at least one intelligent answer If you don't ask you wont know If your gonna construct something, make it·as simple as·possible yet as versatile as posible
Cluso99 said...
Since @@Label is invalid in pasm, I wonder if this is any use??
In fact, the line in spin
x := long[noparse][[/noparse]@Label]
gives the correct data if
DAT
Label mov x,y
but
DAT
xyz wrlong zzz,@Label
does not unless you use
xyz wrlong zzz,(@Label+$10)
and the $10 may vary???
so maybe we could do
DAT
xyz wrlong zzz,@@Label
Any comments??
PS Iam grateful for anything that works
That is an interesting thought. Of course @@ works in Spin, as the interpreter does it for you. Perhaps just making @@ work in PASM as a constant and leaving the spin operator as is would do the job ?
I thought I'd run my regression test on homespun to see if anything else in the obex crashed it out, but there is no option to specify the library search dir like Propellent has.
Is that something you are possibly investigating adding? At the moment I can't compile about 90% of the files as they reference something in the Parallax standard library and homespun can't find them.
hippy said...
I'd vote for &, but @@ has an appeal. @@@ I could live with. I think @| etc are just going to be difficult to remember.
As long as you don't need the constant in a spin block..
ie..
PUB AAA | J[noparse][[/noparse]@@@fred]
.. and that'd be a very odd use, then I reckon @@ makes the most sense as it retains logical compatibility with the runtime behavior in Spin.
I just think using & is likely to get confusing for newbies if they do something dumb and the compiler does not kick and scream..
DAT
i long 123
aaaa long i & j
mov i, &j
I can just see potential for confusion when the code refuses to do what is expected of it because the operator has been used as a unary instead of binary (or vice versa).
At least with @@ it's less likely to happen, and the behaviour in DAT will be effectively identical to the behaviour in Spin.
BradC said...
I thought I'd run my regression test on homespun to see if anything else in the obex crashed it out, but there is no option to specify the library search dir like Propellent has.
Is that something you are possibly investigating adding?
Yes, for sure. I was thinking environment variable rather than compiler option, but whatever. Do people have a preference?
I like what you were saying in another thread about multiple search directories and doing away with the "full pathname" incompatibility. I think that's definitely the way to go.
BradC said...
I thought I'd run my regression test on homespun to see if anything else in the obex crashed it out, but there is no option to specify the library search dir like Propellent has.
Is that something you are possibly investigating adding?
Yes, for sure. I was thinking environment variable rather than compiler option, but whatever. Do people have a preference?
I like what you were saying in another thread about multiple search directories and doing away with the "full pathname" incompatibility. I think that's definitely the way to go.
My preference is for a command line option. Environment variables are rarely properly portable across operating systems. In addition a command line option makes it easier for those that want to script the compiler into an IDE.
On another note, I've managed to duplicate your @@@ behaviour in my compiler. Because I'm a terrible programmer and an awful software architect it took a lot of massaging to make it work! I dunno how many LOC you have in Homespun, but I've cracked 9.2k here now..
My automated regression test compiles nearly 800 spin files at the moment. If you can get a library path option in there I can run homespun against the same set of files..
If you want to talk about bad code and architecture, I think Homespun will give you a run for your money. There's a reason I'm not sharing source code!
What does your library path option look like? Something along these lines? /lib dir1;dir2;dir3
(I don't know if that's even legal; maybe it needs quotes.)
If you want to talk about bad code and architecture, I think Homespun will give you a run for your money. There's a reason I'm not sharing source code!
I'm a pretty horrid architect. I've had to re-write the code generator twice after painting myself into a corner. But then I've never written a tokeniser/parser before either.
I dunno how you implemented the @@@ operator, but I ended up completely sequentially re-compiling my DAT and SPIN blocks until they stop moving about as the PBASE on each object changes. It's ugly but it works.
mpark said...
What does your library path option look like? Something along these lines? /lib dir1;dir2;dir3
(I don't know if that's even legal; maybe it needs quotes.)
Yeah, I've not fleshed out the lib path on Windows yet.. but my linux and MacOS paths are separated with colons.
/home/brad/lib1:/opt/ParallaxLib:/tmp/lib
Which is perfectly legal on Linux..
I guess it'd have to be ';' on Windows. I've got a long flight coming up in a fortnight, so I'll have plenty of time to play with windows oddities.
OwenS said...
I'd vote for the unary & operator, since that makes most sense to me (as a C programmer)
(It should be implementable with similar code to the unary - operator as well)
Hi Owen,
In your assembler you use @ to mean what we're calling @@@. Did you ever consider using & instead of @?
No. While I could have done it, I did @ since the original definition of @ could not be supported by PASM (It's very hard to find the offset from the start of a Spin object which doesn't exist ). When I was writing the RE2C for the scanner I was mostly cloning the operators from the Propeller Manual, and precedent from other assmeblers.
My choice of & over @@@ is mainly because @@@ is overly long.
mpark said...
I dunno how you implemented the @@@ operator, but I ended up completely sequentially re-compiling my DAT and SPIN blocks until they stop moving about as the PBASE on each object changes. It's ugly but it works.
PLink does pretty much the same thing when it's linking object files. It lays out all of the code into the buffer, which PASM has generated using the smallest size instructions it can generate (This only applies to LMM and VMM modes), then points all the symbols, before pointing all the relocations. If relocations don't fit, it enlarges the fragment and the instruction within and then repeats the process.
As for library paths, my preference would be to do both an env var and an option. The environment variable would probably be soemthing like SPINLIB, and the option something like -Lpath, which may be repeated as many times as needed (This is how I intend to do it in PLink)
mpark said...
If you want to talk about bad code and architecture, I think Homespun will give you a run for your money. There's a reason I'm not sharing source code!
I'm in the midst of the third re-write of the tools to handle C bytecode from LCC which is why it's all gone quiet on that front
I'd also argue for command line options over environment variables; makes it so much easier for people to write simple and 'thrown together' IDE's using Visual Basic etc using "Shell" to call it without having to get into incredibly complex stuff for people who aren't experts.
Most of my re-write has been driven by making that as simple as possible and better dividing up the tool components.
Hippy, would it be possible for you to provide me with some information on how LCC bytecodes map to your VM's instructions and such? I'd love to add it as a mode for PASM (and support for the resultant relocations to plink)
It's quite straight forward, two main categories; multi-byte constant loads ($80-$8F), single byte operations which work on the stack ($C0-$FF). On top of that single byte opcodes $00-$7F are optimised constant loads and $9x, $Ax and $Bx are additional optimised constants.
There is some complexity though. Operations are dynamically allocated opcode values and both variables and constant load instructions can be automatically aligned to suitable word/long addresses to get the speed up. The kernel is dynamically built depending on what the needs of the bytecode is.
More than anything it's a matter of being in the right frame of mind to document it.
Oh - so it's a customized kernel like JDForth? That pretty much would make it very difficult to add support to it to PASM (Especially since I'd have to modify your kernel-dynamiscizer to generate PASM compatible assembly)
Yes, and that's where the motivation came from. It actually generates a complete .Spin file with a Spin wrapper ( for debugging, testing and as an includable object ) with the assembled bytecode and necessary tables embedded. I finally managed to get Propellent.Dll working as well so I can compile straight to .Binary/.Eeprom, although I could equally call any of the third-party compilers to do that.
Comments
It was just a thought anyway. Non-C people might be more confused by & than by @@@. I know I used to think & was an odd choice for address-of.
Anyone have suggestions for alternatives to @@@?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Michael Park
PS, BTW, and FYI:
To search the forum, use search.parallax.com (do not use the Search button).
Check out the Propeller Wiki: propeller.wikispaces.com/
Yep. On my Finnish keyboard shift-4 produces a symbol that looks like some kind of rocket coming straight at me.
It is this ¤
I don't even remember now if that exists on "normal" USA/UK keyboards.
Thing is it really looks like it's telling me that something is "at" this point. Perhaps you could be the first to create any kind of language compiler that uses that symbol.
Does anyone know what that symbol is called and/or what it is actually supposed to mean?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
In Swidish it is called a Sun (solen).
and if I remember it first come in ABC80 Swedish 8 Bit Z80 based computer.
Ps. Talar du svenska?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nothing is impossible, there are only different degrees of difficulty.
For every stupid question there is at least one intelligent answer
If you don't ask you wont know
If your gonna construct something, make it·as simple as·possible yet as versatile as posible
Sapieha
Post Edited (Sapieha) : 9/19/2008 7:00:44 PM GMT
Sounds perfect for the job at hand, but I don't know if those outside Scandinavia can generate it easily.
I'm actually English but I've been camped out here in Helsinki for some years and never found anyone who could tell me what that ¤ is. No svenska sadly and my Finnish is still "ei hyvä"
Any other Propeller users in Helsinki or around out there ?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
I have one question on /d.
In End of it Can You ad memory usage else after every obiect.
With to Big program....
Maybe compile that in adress range to big for Prop > 32Kb and generate Labels adresses But Not generate Binary image.
Example...
compiling altair_sim.spin
XXX Longs
compiling altair_cpu.spin
XXX Longs
compiling altair_mem.spin
XXX Longs
compiling altair_ios.spin
XXX Longs
compiling sdspiqasm.spin
XXX Longs
compiling PC_Keyboard.spin
XXX Longs
compiling VGA_Text.spin
XXX Longs
compiling vga.spin
XXX Longs
Too big by 150 longs
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nothing is impossible, there are only different degrees of difficulty.
For every stupid question there is at least one intelligent answer
If you don't ask you wont know
If your gonna construct something, make it·as simple as·possible yet as versatile as posible
Sapieha
Andy
Sapieha, I think I can add that.
Ariba, if we're going to do that, maybe we should use the Spin absolute value operator: @|| or ||@
Or heck, we could use math notation: |@|
Well, let's see if a consensus emerges. @@@ isn't that bad.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Michael Park
PS, BTW, and FYI:
To search the forum, use search.parallax.com (do not use the Search button).
Check out the Propeller Wiki: propeller.wikispaces.com/
Thanks.
It can be very handy to optimize objects to Fit in memory.
Not in al circumstances objects must have al PRI routines. And that can help to find them.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nothing is impossible, there are only different degrees of difficulty.
For every stupid question there is at least one intelligent answer
If you don't ask you wont know
If your gonna construct something, make it·as simple as·possible yet as versatile as posible
Sapieha
Post Edited (Sapieha) : 9/20/2008 1:02:49 AM GMT
In fact, the line in spin
x := long[noparse][[/noparse]@Label]
gives the correct data if
DAT
Label mov x,y
but
DAT
xyz wrlong zzz,@Label
does not unless you use
xyz wrlong zzz,(@Label+$10)
and the $10 may vary???
so maybe we could do
DAT
xyz wrlong zzz,@@Label
Any comments??
PS Iam grateful for anything that works
I like it more than the alternatives [noparse]:)[/noparse]
Using & would likely get confusing.
@@@ is ugly, but unique. Why not stick with it.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Pull my finger!
That is an interesting thought. Of course @@ works in Spin, as the interpreter does it for you. Perhaps just making @@ work in PASM as a constant and leaving the spin operator as is would do the job ?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Pull my finger!
Is that something you are possibly investigating adding? At the moment I can't compile about 90% of the files as they reference something in the Parallax standard library and homespun can't find them.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Pull my finger!
(It should be implementable with similar code to the unary - operator as well)
As long as you don't need the constant in a spin block..
ie..
PUB AAA | J[noparse][[/noparse]@@@fred]
.. and that'd be a very odd use, then I reckon @@ makes the most sense as it retains logical compatibility with the runtime behavior in Spin.
I just think using & is likely to get confusing for newbies if they do something dumb and the compiler does not kick and scream..
DAT
i long 123
aaaa long i & j
mov i, &j
I can just see potential for confusion when the code refuses to do what is expected of it because the operator has been used as a unary instead of binary (or vice versa).
At least with @@ it's less likely to happen, and the behaviour in DAT will be effectively identical to the behaviour in Spin.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Pull my finger!
Yes, for sure. I was thinking environment variable rather than compiler option, but whatever. Do people have a preference?
I like what you were saying in another thread about multiple search directories and doing away with the "full pathname" incompatibility. I think that's definitely the way to go.
Hi Owen,
In your assembler you use @ to mean what we're calling @@@. Did you ever consider using & instead of @?
My preference is for a command line option. Environment variables are rarely properly portable across operating systems. In addition a command line option makes it easier for those that want to script the compiler into an IDE.
On another note, I've managed to duplicate your @@@ behaviour in my compiler. Because I'm a terrible programmer and an awful software architect it took a lot of massaging to make it work! I dunno how many LOC you have in Homespun, but I've cracked 9.2k here now..
My automated regression test compiles nearly 800 spin files at the moment. If you can get a library path option in there I can run homespun against the same set of files..
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Pull my finger!
If you want to talk about bad code and architecture, I think Homespun will give you a run for your money. There's a reason I'm not sharing source code!
What does your library path option look like? Something along these lines? /lib dir1;dir2;dir3
(I don't know if that's even legal; maybe it needs quotes.)
I'm a pretty horrid architect. I've had to re-write the code generator twice after painting myself into a corner. But then I've never written a tokeniser/parser before either.
I dunno how you implemented the @@@ operator, but I ended up completely sequentially re-compiling my DAT and SPIN blocks until they stop moving about as the PBASE on each object changes. It's ugly but it works.
Yeah, I've not fleshed out the lib path on Windows yet.. but my linux and MacOS paths are separated with colons.
/home/brad/lib1:/opt/ParallaxLib:/tmp/lib
Which is perfectly legal on Linux..
I guess it'd have to be ';' on Windows. I've got a long flight coming up in a fortnight, so I'll have plenty of time to play with windows oddities.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Pull my finger!
No. While I could have done it, I did @ since the original definition of @ could not be supported by PASM (It's very hard to find the offset from the start of a Spin object which doesn't exist
My choice of & over @@@ is mainly because @@@ is overly long.
PLink does pretty much the same thing when it's linking object files. It lays out all of the code into the buffer, which PASM has generated using the smallest size instructions it can generate (This only applies to LMM and VMM modes), then points all the symbols, before pointing all the relocations. If relocations don't fit, it enlarges the fragment and the instruction within and then repeats the process.
As for library paths, my preference would be to do both an env var and an option. The environment variable would probably be soemthing like SPINLIB, and the option something like -Lpath, which may be repeated as many times as needed (This is how I intend to do it in PLink)
Oh, brilliant.. I'd never even thought of that.. far easier than futzing about with os dependent delimiters!
I guess it'll be -L on *nix and /L on Windows..
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Pull my finger!
(The -L syntax comes from pretty much every Unix' ld by the way)
I'm in the midst of the third re-write of the tools to handle C bytecode from LCC which is why it's all gone quiet on that front
I'd also argue for command line options over environment variables; makes it so much easier for people to write simple and 'thrown together' IDE's using Visual Basic etc using "Shell" to call it without having to get into incredibly complex stuff for people who aren't experts.
Most of my re-write has been driven by making that as simple as possible and better dividing up the tool components.
Post Edited (OwenS) : 9/20/2008 6:46:23 PM GMT
It's quite straight forward, two main categories; multi-byte constant loads ($80-$8F), single byte operations which work on the stack ($C0-$FF). On top of that single byte opcodes $00-$7F are optimised constant loads and $9x, $Ax and $Bx are additional optimised constants.
There is some complexity though. Operations are dynamically allocated opcode values and both variables and constant load instructions can be automatically aligned to suitable word/long addresses to get the speed up. The kernel is dynamically built depending on what the needs of the bytecode is.
More than anything it's a matter of being in the right frame of mind to document it.