Just looked quickly at the slang page, and just tought "wow, I've been thinking about this".
Looked at the examples and the languague reference and the output (assembler-code) and it looked quite nice. I will return to this site and read some more soon.
My thoughts about compilers so far have been about cross-compiler on a PC. One idea I've had it so define a "optimization language" that the compiler uses to make transformations on some type of intermediate code, so that it would be possible to "learn" the compiler more trixx.
Another idea (that is quite far of ...) is to include a 6502-emulator/driver into the compiler, and then by feeding the program test-data and having the compiler analysing the "emulator runs" and what happens in memory, allow the compiler to completly "rewrite" the program to make the actual computations and data-moves in the least expensive way.
Sorry, couldn't help myself, I just LOVE this subject.
//MH
Do you ever/always/never finish programs?
Yes, I've known about Slang for a while, but not considered its potential. Maybe I should look more closely and see how powerful it can be. At least the 4K mini-games should be possible to efficiently develop in Slang. If it generates assembly source, it should also be possible to hand optimize if required.
Anders Carlsson
No it doesn't seem to generate clear assemblycode, sorry
Sorry, I ment i read the disassebled code for the examples on the site.
While it's possible to hand-optimize a smaller project when disasembled, I figure it would be quite difficult to quickly get a grasp of how the code relates to the source if the project grows large.
While it's possible to hand-optimize a smaller project when disasembled, I figure it would be quite difficult to quickly get a grasp of how the code relates to the source if the project grows large.
Is the source for slang avaliable?
Is the sourcecode avaliable? I may be blind but I didn't see it at the mainpage.
What is it written in? ( cc65? )
What is it written in? ( cc65? )
As far as I can see and understand, the Slang compiler is written in 65816 assembler. The cross-platform xlang comes with a 65816 simulator written in C plus the object code for the Slang compiler, which also is available as assembly source if you insist.
The files needed to be changed to use Slang on VIC-20 should be at least SLANGDEF.E.S, but I am unsure if it needs a special (65816 compatible) assembler other than the normal 6502 cross-assemblers.
The files needed to be changed to use Slang on VIC-20 should be at least SLANGDEF.E.S, but I am unsure if it needs a special (65816 compatible) assembler other than the normal 6502 cross-assemblers.
Anders Carlsson
?Asm
Writing a compiler in assembler sounds difficult. Apart from the first compiler one would think that compilers should be written in compilers?
Sure Slang already exists, but extending a program this big, written in assembler could be a pain in the ass.
How about bootstrapping Slang in itself?
well thats another project.
Sure Slang already exists, but extending a program this big, written in assembler could be a pain in the ass.
How about bootstrapping Slang in itself?
well thats another project.If you have layouted all the rules, parser, lexical analysis and so on, I don't know if assembly code is many times more complex than a higher level language. It takes more time to develop it surely, but there is no overhead from the compiler's own bad compiler optimisations.
Considering this language is written on a platform which rarely sees a compiler (a few native C and Pascal compilers on C64), it doesn't surprise me that the compiler itself is written in the lowest form which also gives the smallest possible footprint.
Anyway, I'll try to find some time and get into the tutorial. To start with, I can make some C64 programs and when I have understood the syntax, it is time to make it work for other platforms too.
Considering this language is written on a platform which rarely sees a compiler (a few native C and Pascal compilers on C64), it doesn't surprise me that the compiler itself is written in the lowest form which also gives the smallest possible footprint.
Anyway, I'll try to find some time and get into the tutorial. To start with, I can make some C64 programs and when I have understood the syntax, it is time to make it work for other platforms too.
Anders Carlsson
>If you have layouted all the rules, parser, lexical analysis and so on, I
>don't know if assembly code is many times more complex than a higher
>level language. It takes more time to develop it surely, but there is no
>overhead from the compiler's own bad compiler optimisations.
Even if I know that this isn't what we where talking about i just wanted to mention:
<of_topic_warning>
Looking at modern compilers (VC++, intel and GCC) actually optimize very well. There are so many quirks and tricks used for some specific identified operations, that in some cases even an seasoned assembly programmer would have a hard time writing as efficient code as these compiler do. Even an assembly programmer often tries to layout the code in a way that is somewhat understandable, using some tricks here and there, but a compiler always take all the shortcuts it "knows" about. Have you heard about "supercompiling"? I seem to remember that GCC has some supercompile-sequences inside from a book on compiler construction I've read.
</of_topic_warning>
Anyway constructing a compiler in assembler is a lot of hard work just from a architecture/modular point of view. (I agree with you above).
Crosscompiling for old systems (VIC20) on PC novadays is intressting from another point of view:
One can make the compiler really perculate the intermediate code very much because of the extreme horsepower and memory of todays machines (as compared to the days ... ). If an analyse of an full AST has to visit tens of 1000's of nodes (large program) several 1000's times it can be done with a normal desktop PC of today. In the mid 80's that was just a CRAY-fantasy
>don't know if assembly code is many times more complex than a higher
>level language. It takes more time to develop it surely, but there is no
>overhead from the compiler's own bad compiler optimisations.
Even if I know that this isn't what we where talking about i just wanted to mention:
<of_topic_warning>
Looking at modern compilers (VC++, intel and GCC) actually optimize very well. There are so many quirks and tricks used for some specific identified operations, that in some cases even an seasoned assembly programmer would have a hard time writing as efficient code as these compiler do. Even an assembly programmer often tries to layout the code in a way that is somewhat understandable, using some tricks here and there, but a compiler always take all the shortcuts it "knows" about. Have you heard about "supercompiling"? I seem to remember that GCC has some supercompile-sequences inside from a book on compiler construction I've read.
</of_topic_warning>
Anyway constructing a compiler in assembler is a lot of hard work just from a architecture/modular point of view. (I agree with you above).
Crosscompiling for old systems (VIC20) on PC novadays is intressting from another point of view:
One can make the compiler really perculate the intermediate code very much because of the extreme horsepower and memory of todays machines (as compared to the days ... ). If an analyse of an full AST has to visit tens of 1000's of nodes (large program) several 1000's times it can be done with a normal desktop PC of today. In the mid 80's that was just a CRAY-fantasy
Too bad that modern gcc or VC++ for that matter does not have an active module for 6502 code generation. Gcc exists in a number of flavors, but mostly "currently useful" platforms. The cc65 is good, but nowhere as polished and optimizing, and it is the end compiler that makes the difference on the final result.
(soon we should split, move or start a new topic in the Programming section)
When it comes to extending the language, it seems the whole language is defined in the slangdef file (as macro assembler with references to Basic and Kernel ROMs thrown in), which the compiler compiles and uses as a library to link with your own programs. Therefore you would not need to worry about extendability unless you refer to new syntax to define the language, optimization and other matters.
You only need to know the memory map of VIC-20 to change the references, drop those keywords associated with VIC-II or SID and add some new keywords for VIC-I. The base of the language should remain the same, but the available keywords would be different, like how it had been if Commodore had developed a more friendly Basic for the C64 instead of making it backwards compatible with the VIC and earlier Basics.
(soon we should split, move or start a new topic in the Programming section)
When it comes to extending the language, it seems the whole language is defined in the slangdef file (as macro assembler with references to Basic and Kernel ROMs thrown in), which the compiler compiles and uses as a library to link with your own programs. Therefore you would not need to worry about extendability unless you refer to new syntax to define the language, optimization and other matters.
You only need to know the memory map of VIC-20 to change the references, drop those keywords associated with VIC-II or SID and add some new keywords for VIC-I. The base of the language should remain the same, but the available keywords would be different, like how it had been if Commodore had developed a more friendly Basic for the C64 instead of making it backwards compatible with the VIC and earlier Basics.
Anders Carlsson
Again, I find myself revisiting programs. I can never seem to declare a game to be done! There's always some feature to add. I always find a way to speed it up or crunch it to add more details.
The torture in making such changes is that I want to recall every existing version and replace it with the new one.
The torture in making such changes is that I want to recall every existing version and replace it with the new one.
I just find I get easily distrac...
..wow, look at that! Something new I could be doing!
But, I'm like a kid in a candy store. A lot of the stuff that most of you guys have known and done for several decades is new info to me. So, while I can understand there might be a point where doing new projects might not interest me anymore, I'm at the opposite end of the spectrum.
So I intend finishing my current project.. either that or Victragic mysteriously disappears and I sign up again under a new logon.
-G
..wow, look at that! Something new I could be doing!
But, I'm like a kid in a candy store. A lot of the stuff that most of you guys have known and done for several decades is new info to me. So, while I can understand there might be a point where doing new projects might not interest me anymore, I'm at the opposite end of the spectrum.
So I intend finishing my current project.. either that or Victragic mysteriously disappears and I sign up again under a new logon.
-G
3^4 is 81.0000001
To me, a "Finished" program is one that you can give or sell to someone, and the program does exactly what its creator intended it to do. Everything after that point is what I consider "Updates."
As someone who made his living as a computer programmer, it was imperative that I finished my programs; at first to graduate my 3 year program in Information Systems, then to get paid. These days, all the good programming jobs seem to have disappeared; perhaps to India.
In any case, for the record, I consider my Vic-20 Sudoku program to be the first "Finished" program I ever wrote for a Commodore machine; before then, I was like many others here; a lot of half-baked ideas that never reached fruitation. Like others here, I don't have a lot of spare time, but I do plan on doing more Commodore, and particularly Vic 20, programming in the future.
As someone who made his living as a computer programmer, it was imperative that I finished my programs; at first to graduate my 3 year program in Information Systems, then to get paid. These days, all the good programming jobs seem to have disappeared; perhaps to India.
In any case, for the record, I consider my Vic-20 Sudoku program to be the first "Finished" program I ever wrote for a Commodore machine; before then, I was like many others here; a lot of half-baked ideas that never reached fruitation. Like others here, I don't have a lot of spare time, but I do plan on doing more Commodore, and particularly Vic 20, programming in the future.