Author Topic: HACC (Read 23739 times)

JincS · « **Reply #45 on:** March 15, 2007, 10:26:00 pm »

Once we get a stable release with a basic library set up, we'll see what we can do. It should only be a matter of adding some application-defined parameters to the libraries to make it work right. But we'll see...

Halifax · « **Reply #46 on:** March 16, 2007, 12:55:00 am »

Ok take it like this. The only way we could get GCC to compile something for Flash capability is to rewrite the GCC compiler which isn't going to happen. The second is to study all of GCC and write a series of patches because GCC builds assembly with SMC. So adding flash capability would be severely hard ok

.

One thing you could do though is maybe write an ASM converter that converts the ASM to flash capable. That's pretty hard though too.

bfr · « **Reply #47 on:** March 16, 2007, 11:11:00 am »

OK. Sorry if I was being annoying, but I just wanted to know why we couldn't make Flash Applications with it, which I wouldn't think would be too difficult. Also, I know I've been asking a lot of questions lately (sorry, I know I'm probably getting annoying), but I'm still curious - why would you have to rewrite the GCC compiler?

Halifax · « **Reply #48 on:** March 16, 2007, 03:15:00 pm »

Ok. I will try to explain it so you understand this. GCC is basically built for computers right. And computers support SMC right. Ok then GCC was never meant to compile non-SMC code. That is why it would require a rewrite.

bfr · « **Reply #49 on:** March 16, 2007, 03:55:00 pm »

But that doesn't seem to make sense. It can compile SMC code, but can't compile non-SMC code? How is that even possible? Does it run through the code, checking to make sure it has some SMC code, and if it doesn't contain any SMC code, it doesn't work?

(Sorry if I'm being annoying, but this just doesn't seem to make sense)

Halifax · « **Reply #50 on:** March 16, 2007, 04:06:00 pm »

It makes what it seems is the most optimizable way to compile the program.

Jon · « **Reply #51 on:** March 16, 2007, 04:53:00 pm »

Meh, you could add a patch that makes GCC add the code to make an appvar, then mess with the pointers so that SMC is placed within the appvar.

Liazon · « **Reply #52 on:** March 17, 2007, 06:54:00 am »

QuoteBegin-bfr+16 Mar, 2007, 20:55-->

QUOTE (bfr @ 16 Mar, 2007, 20:55)

But that doesn't seem to make sense. It can compile SMC code, but can't compile non-SMC code? How is that even possible? Does it run through the code, checking to make sure it has some SMC code, and if it doesn't contain any SMC code, it doesn't work?

(Sorry if I'm being annoying, but this just doesn't seem to make sense)

Keep in mind that GCC was designed to compile computer programs. I don't know much about computers, but I'd guess that a lot of file I/O involves copying to RAM, since the bus? between HDD and processor would be really slow compared to processor and RAM. Thus, SMC (as in "variables" within the code that get modified, though I guess SMC executable is a possibility too) would be ideal, otherwise all variables have to be malloc'd in RAM or something

Halifax · « **Reply #53 on:** March 17, 2007, 12:05:00 pm »

Yes Liazon exactly, but for some of you I don't think you are getting an idea of how big GCC really is. So to write a patch for GCC you have to know what it is doing and when it is doing it and why. To write a backend all you need to do is take what GCC spits out. Patches are not ideal to the process and I think you guys should really just forget Applications.

bfr · « **Reply #54 on:** March 17, 2007, 03:14:00 pm »

OK. After talking more with Halifax and Kevin Kofler, I see why it would be hard to allow Z8-GCC to be used to create Flash Applications.

But is inline assembly and integration with raw assembly (for the IDE) still possible?

Halifax · « **Reply #55 on:** March 17, 2007, 04:27:00 pm »

As I have said before. Whatever GCC supports natively will be supported by z8-GCC. Which means inline assembly. And can you elaborate on what you mean by raw assembly.

bfr · « **Reply #56 on:** March 17, 2007, 04:41:00 pm »

Raw assembly, pure assembly, plain good old assembly. Like this:

or a
ret z

I don't mean hexidecimal or anything like that, though.

Jon · « **Reply #57 on:** March 17, 2007, 05:24:00 pm »

I think writing your own custom code that executes after GCC does its thing could work. Just have it look at all the variables used in the original .C file, and rewrite the pointers in the .ASM file that GCC created.

Halifax · « **Reply #58 on:** March 17, 2007, 05:56:00 pm »

oh bfr that's basically the same as inline assembly. And no Jon. For that you would have to write your on parser. As I have said before forget the applications. Its a feat even to get GCC to work with z80.

Delnar_Ersike · « **Reply #59 on:** July 31, 2007, 11:02:00 pm »

Me wants progress on this project for specific... reasons... :rainbowdevil:

Author Topic: HACC (Read 23739 times)

Liazon

Delnar_Ersike