New Atari Compiler Dev

[+Gemintronic]

Who are the intended users? I think assembly programmers get annoyed with compiled code inefficiencies. I also think batari BASIC users would need a huge incentive to move to a C-like language.

 

Just my initial thoughts. Any new 2600 compiler development is awesome!

[Gip-Gip]

Who are the intended users? I think assembly programmers get annoyed with compiled code inefficiencies. I also think batari BASIC users would need a huge incentive to move to a C-like language.

 

Just my initial thoughts. Any new 2600 compiler development is awesome!

AtaC is being made for those who want a C-like experience when programming for the Atari. What I mean is:

 

* More recognizable/clean code

* Efficient code generation(for a high-level language)

* Masked multi-instruction operations

* (semi)Hidden code placement

* Abstracted variable creation

 

AtaC will have verbose arguments that allow the user to see how many clocks a statement takes up, and you will be able to integrate assembly code into files.

 

Just to answer the question directly, AtaC is aimed for assembler programmers(like myself) who want cleaner code and code placement, without the inefficiency of batari basic(along with the fixed variables, basic syntax etc).

 

I hope I explained this well enough, but please tell me otherwise if so.

Edited April 19, 2016 by Gip-Gip

[Thomas Jentzsch]

Are you working together with some developers who check you ideas, provide their own feedback and test your compiler? Else you might miss the requirements.

[Gip-Gip]

Are you working together with some developers who check you ideas, provide their own feedback and test your compiler? Else you might miss the requirements.

Not at the current moment, but I probably should. I'll think about releasing the source code early, even though at the current moment it's only good at giving me messages.

 

(Btw if anyone wants to help with development just tell me)

Edited April 20, 2016 by Gip-Gip

[Mr SQL]

AtaC is being made for those who want a C-like experience when programming for the Atari. What I mean is:

 

* More recognizable/clean code

* Efficient code generation(for a high-level language)

* Masked multi-instruction operations

* (semi)Hidden code placement

* Abstracted variable creation

 

AtaC will have verbose arguments that allow the user to see how many clocks a statement takes up, and you will be able to integrate assembly code into files.

 

Just to answer the question directly, AtaC is aimed for assembler programmers(like myself) who want cleaner code and code placement, without the inefficiency of batari basic(along with the fixed variables, basic syntax etc).

 

I hope I explained this well enough, but please tell me otherwise if so.

 

Very clear Gip-Gip, AtaC is geared for advanced programmers who already know Assembly.

 

C is very high level and being able to use a pure C-like environment goes along with abstacting the hardware and making bank switching and page alignment transparent as talked about earlier on this thread.

 

Different schools of thought here too, my ASDK Abstract Assembly model renders bank switching, page boundries and cycle counting largely transparent to Assembly developers while bB requires BASIC programmers to know about (after tripping over) the low level minutia.

 

Transparency and isolation are some of the things I tried to enhance upon with Virtual World BASIC, I think it is advantageous to high level programmers; imo the number of threads with BASIC programmers encountering these obstacles with bB suggests that removing them could result in more awesome games and more programming fun.

 

Perhaps AtaC while allow optional low level access while isolating the programmer from it in C like fashion

[Thomas Jentzsch]

Too much overdue tasks in RL and hobby.

 

Sorry!

[Mr SQL]

Who are the intended users? I think assembly programmers get annoyed with compiled code inefficiencies. I also think batari BASIC users would need a huge incentive to move to a C-like language.

 

Just my initial thoughts. Any new 2600 compiler development is awesome!

 

Great point Loon, batari BASIC users need a huge incentive to try even another Tiny BASIC!

 

Maybe beating C64, ZX-81, Speccy and MSX BASIC will do it

 

 

Are you working together with some developers who check you ideas, provide their own feedback and test your compiler? Else you might miss the requirements.

 

Why not provide feedback and help check ideas based on the BoulderDash programming language you are developing?

[Gip-Gip]

Too much overdue tasks in RL and hobby.

 

Sorry!

No problem! I meant it as a general statement, so it wasn't intentionally aimed at you.

[Gip-Gip]

I have uploaded a very simple edition of the frontend to GitHub that has a stub parse function for debugging purposes. I am uploading this so you guys can catch anything weird I'm doing and put me in the right direction(it's also so you can get used to my coding style).

 

(in case you were wondering, I had to re-write a bit of code as it was getting out of control)

Edited April 21, 2016 by Gip-Gip

[ZackAttack]

It would probably be a good idea to test with bad source in addition to good source. Two things that will severely a compilers reputation are misleading errors and failing to detect errors. Nothing is worse than debugging a problem for hours only to realize that the source code is invalid and the compiler generated bad code instead of flagging the error in the source.

 

Also, I still strongly recommend you study modern compiler design theory further before you write any more code. Implementing the lexing, parsing, and compiling as a big group of nested if statements and state flags is going to become difficult to maintain as you try to implement the entire language. I posted some good resources to start with in a previous post.

[Kylearan]

After a quick look at your sources, I can only echo ZackAttack here. Compiler architecture and design is a very well researched area with decades of experience in the community, and there are tried and proven methods as well as mature libraries and tools already out there which might save you a lot of hassle. You say one of your design goals for your language is clean code, so maybe doing a clean compiler underneath would be a good start.

 

(I realize doing everything yourself from the get go can be a fun learning experience in itself and a nice hobby project, but from your vision statement it looks like that might come back and haunt you later on...)

[Mr SQL]

Excellent comp-sci perspectives from Zack and Kylearan.

 

Equally fair what Torvalds would do - implement the lexing, parsing, and compiling as a big group of nested if statements and state flags.

 

imo the best approach to implement your vision of AtaC is the method that motivates you the most

 

One benefit to not reviewing compiler architecture and design is that you won't be influenced by it.

 

Alternative study suggestion for compiler design:

Text adventure parser design, Eliza parser design.

[gauauu]

imo the best approach to implement your vision of AtaC is the method that motivates you the most

 

 

There's some truth to that -- if it's not fun, you won't do it.

 

One benefit to not reviewing compiler architecture and design is that you won't be influenced by it.

 

But I have no idea how that's a benefit. People have studied this for years and years, do you really think you'd come up with something better by dumb luck?

 

[Gip-Gip]

I will re-write the compiler with a method which is compact and non-repetitive.

[Mr SQL]

 

There's some truth to that -- if it's not fun, you won't do it.

 

 

But I have no idea how that's a benefit. People have studied this for years and years, do you really think you'd come up with something better by dumb luck?

 

 

No not by dumb luck, by the creative nature of programming; infinite solutions.

 

A programmer, having used languages and compilers already has those things as examples of the inputs and the outputs from which to start so we're weighing reverse engineering the different concept examples vs studying the internal code design.

 

In this case, the concrete examples are the end result of many years of compiler and language design and study and the programmer is already using them hands on.

 

Reverse engineering may be easier as well and is often used to optimize performance, but it doesn't necessarily have to be better.

[Gip-Gip]

I'm thinking of a branching assembly-line compiler, where functions are called based on what they do and the detected perimeters. Please give me any other methods as I'm not exactly sure what to research.

[ZackAttack]

I'm not sure what you're asking Gip-Gip. If you are talking about how to implement the assembler, you should be able to just use dasm or another existing one. Perhaps just compile everything to assembly and then run the whole thing through dasm at once. I believe this is how batari basic works. The basic is converted to assembly and combined with pre made kernels and other assembly files and then assembled.

[Gip-Gip]

I'm not sure what you're asking Gip-Gip. If you are talking about how to implement the assembler, you should be able to just use dasm or another existing one. Perhaps just compile everything to assembly and then run the whole thing through dasm at once. I believe this is how batari basic works. The basic is converted to assembly and combined with pre made kernels and other assembly files and then assembled.

 

I was talking about code flow/processing

 

Here's a simplified example:

 

 

Key:

 

"-" = call

"|" = possible branch

"<" = return

Edited April 22, 2016 by Gip-Gip

[Mr SQL]

 

I was talking about code flow/processing

 

Here's a simplified example:

 

 

Key:

 

"-" = call

"|" = possible branch

"<" = return

 

I'm thinking of a branching assembly-line compiler, where functions are called based on what they do and the detected perimeters. Please give me any other methods as I'm not exactly sure what to research.

 

Gip-Gip, with this model are you referring to building a dynamic library for the runtime?

 

Virtual World BASIC works similar to what Zack described for bB, the BASIC is compiled dynamically into Assembly and linked to the Assembly runtime; most of the functions are calls to the static runtime (graphics, etc), though a couple of dynamic functions are added on-the-fly if needed; I thought that was what you might be getting at.

[Gip-Gip]

 

 

Gip-Gip, with this model are you referring to building a dynamic library for the runtime?

 

Virtual World BASIC works similar to what Zack described for bB, the BASIC is compiled dynamically into Assembly and linked to the Assembly runtime; most of the functions are calls to the static runtime (graphics, etc), though a couple of dynamic functions are added on-the-fly if needed; I thought that was what you might be getting at.

 

What I am planning to do is make a standalone compiler(it generates binary code in the end), as that keeps the compiler dependency-less. It will result in larger code, but this also helps further simplify installation(granted, not by much).

[ZackAttack]

You can do both. DASM is Open Source Software (OSS) under GPLv2. So you can embed the parts of the DASM source that you need and still have robust assembler support fully integrated into a single binary without having to write it yourself. Then you can focus your effort on AtaC.

[Gip-Gip]

I made a simple logo and redid the code structure to the current idea in mind(it's still a stub though). Again, tell me if there is anything that seems set up for failure.

Edited May 5, 2016 by Gip-Gip

[Gip-Gip]

Now were at v4.2016! There is slow progress, as it is still just a very limited debug stub. If you have any complaints/rejections I need to hear it now!

 

Also if you notice any bugs please tell me. This is a good time to fix them.

 

If you have a GitHub account any contributions would be greatly appreciated!

 

The project's link is in my signature.

[Gip-Gip]

You can do both. DASM is Open Source Software (OSS) under GPLv2.

 

AtaC is under the conflicting ISC license. No can do.

Edited May 7, 2016 by Gip-Gip

[DanOliver]

Way late to suggest anything but just in general I prefer not using tried and true methods. For example I know almost nothing about compiler development, but I do know it's been around a long time. Been taught and re-taught for several generations. That kind of lineage often means a narrowing of thinking. "Don't reinvent the wheel" is the motto of the champions for status quo. It makes me think how compilers are designed could indeed be overthrown. For example it blows me away that compilers are not near instant builds. We're still using text files for crying out loud.

 

I wrote an instant 6502 assembler and used it to create a 2600 game. What a huge difference. Changed how I created games. A couple of us wrote instant 65816 assembler at Apple too for GS development.

 

Current compilers I'll bet are based on limited CPU and memory and no concept of the Internet. When you have 18 CPU cores, 8TB of RAM and ability off load tasks to thousands of computers on the internet the possibilities become a little more interesting than current compiler method I think. I'm guessing you could do some really dumb brute force stuff that could result in something wonderful.