include directive

[rustyoz]

i'm guessing that there will be a lot of projects started that use some kind of core / linking / make file that use include directives

to get Atlas to build properly i have to split up the kernel file and have the files correctly ordered in the project folder.

[kierenj]

Interesting. The build system is self-contained, so could be modified to work in that way. You shouldn't have to order files particularly - using segments and the project property page's "compile this file first" you should be set. If that doesn't do the trick, #includes might be an option. But I see them as a bit of a throwback to C/C++, with poor language and compiler design, something I wanted to avoid if possible.

[dekay9001]

Is there actually a reliable way to get the address of end of the code? I want to pass that address to a routine to tell it where the heap starts. With this directive it would easily be possible.

[kierenj]

Yes, by default there is a segment called heap with a high priority. This will do it:

segment heap

:lbl

On Tue, Jun 5, 2012 at 8:45 PM, dekay9001 < reply@reply.github.com

wrote:

Is there actually a way to get the address of end of the code? I want to pass that address to a function to tell it where the heap starts. With this directive it would easily be possible.

---

Reply to this email directly or view it on GitHub: https://github.com/kierenj/0x10c-DevKit/issues/175#issuecomment-6134600

[rustyoz]

its just that for Atlas it copies the API jump table to 0x1000. currently with using organic or toolchain this can be accomplished using includes and a dat block of spaces.

its just that there is no way (i think) of predictably compiling code into a certain location in the memory.

[kirinyaga]

by the way, is there a list of the #directives and their format somewhere ?

[kierenj]

kirinyaga - Yes, in the online manual.

bungao - it sounds like you're yearning for the .org directive? Includes and dat blocks sound like a bad way of doing an .org to me?

[rustyoz]

.org would be useful too.

[kierenj]

I'll open another issue for .org. Given that files in the project are built already, is there any need for #include?

[rustyoz]

i think it would be useful.

for instance you might have a project that goes something like

SET PC, start

include librarycode

:start do something blah blah. JSR something (in library)

include file

sure the files are built one after the other but you can't reorganise the the order in which they are built. includes just make it certain where stuff is built to. having an include and org directive would make code organisation a lot easier

[kierenj]

You can use #segments with a priority to do it, andt he reason I think #include would fit less is because if you put the file in the project, it will be built - use #include and it will be included/built twice. Unless we said that #included files aren't built separately if any #include is detected with them in?

But it adds some complexity where there's an existing solution with #segments (and maybe .org) - E.g. at the top of each file, you can do #segment whatever 520, and that code will go into the output file in a segment called 'whatever', at priority 520.

Humm I am coming around to the idea of #include, where if a file is #included its not build again separately. In terms of .org though, I would appreciate your opinion - should .org (or maybe #org) set the offset within the segment you are in, or should it be saying 'ignore segments, go to this overall location', or maybe you can define a segment as starting at a particular address, like #segment callTable @0x0002 etc? (I quite like the last idea but it's quite different from existing .org directives)?

[rustyoz]

the last idea might work. since you could define a #segment apitable @0x1000 with the priorities anything below the api table's priority would go after it

[kierenj]

Tackling this in the same issue that's handling .org - so closing this one