Sweet. I just put Ubuntu on my iBook, this could make me that much coler to open-sourcing everything. Ah, well. If only it could dual-boot.

<<Ah, well. If only it could dual-boot.>>

PedroM (or Ubuntu)? I wrote a dual-booter some time ago (actually a tool to boot PedroM from AMS), Pedrhum (link above, in French). But it would need to be ported to the newer versions.

PedroM (Ubuntu I've already got setup alternate the MacOS).

I love Ubuntu. I'm running it right now... on my other machine, that is.

"Just", heh? ^^

Aren't you one of those whining whenever I say something like that? "Do as I say, not as I do", to quote Lionel Debroux.

I'm not insulting and provocating as you are.
I'm not telling "website X has reported the new d days, h hours, m minutes and s seconds before you do".
I'm fully aware the staff from ticalc was speaking of the uploaded archive more than the effective release.

Provocate is not a word.

You're back!!! I have grammar backup!!! FINALLY!!!

Sorry for that, but I think everybody understood what I wanted to say.

1 entry found for provocate.
Main Entry: provocate
Part of Speech: verb
Definition: to provoke

Source: Webster's New Millennium™ Dictionary of English, Preview Edition (v 0.9.6)
Copyright © 2003-2005 Lexico Publishing Group, LLC

Pix in file page borked.
Great, this is an excellent step towards leaving behind the inefficiently-design TI-OSes!

I wish it was a bigger step though PedroM is quite limited compared to AMS

Hmm... Should I replace?

I have a patched version of PedroM on my site which:
1. is built with the TIGCC linker (ld-tigcc), not with an obsolete "maketib" hack,
2. is really fully GPL. PpHd's build includes non-Free components.

http://p080.ezboard.com/ ftichessteamhqfrm10. showMessage?topicID=186.topic
(remove the spaces)

I should add that my build of PedroM is the one included in TiEmu as the default ROM (so it's at least of some use out of the box, since we can't include AMS with TiEmu), though the current TiEmu snapshot doesn't include the latest PedroM yet (it includes a RC, the next snapshot will have the latest).

Moreover, you need flashos.a if you want to compile it yourself:
http://www.tigen.org/kevin.kofler/ ti89prog/flashosa.zip
(remove the space)

Why do you call maketib a hack ?

Because it's not a real linker, it only takes 1 object file, it doesn't process relocations properly (hence you have to RORG right in the assembler, ld-tigcc knows and computes the absolute addresses by itself - RORG/ORG, or .org in GNU as, is a hack and shouldn't be supported by assemblers at all, it's the linker's job to compute runtime addresses!) and it lacks pretty much all the other features of a linker (not just the 2 core ones I listed).

Linkers are not required to compile asm programs. I've already used assemblers generating brute binary for 68000-based system, and ORG/RORG were part of the standard commands.
Anyway, a limited linker remains a linker, even if *you* didn't write it.
And GNU as is a hack since it uses a non standard assembly syntax (I can troll too).

> Linkers are not required to compile asm programs. I've already used assemblers generating brute binary for 68000-based system, and ORG/RORG were part of the standard commands.

A linker is required to compile ANY program. Compiling something without using a linker is per definition a hack. The normal process is compiler->assembler->linker. The compiler-> part is not required for assembly because the input language happens to already be assembly, but there's no reason to dump the linker.

> Anyway, a limited linker remains a linker,

A "linker" which doesn't actually LINK (i.e. COMBINE several object files together) is not a linker!

> even if *you* didn't write it.

Strawman argument. What on Earth does this has to do with the discussion?

> And GNU as is a hack since it uses a non standard assembly syntax (I can troll too).

How is that a hack? You don't seem to have understood my point at all, or even that it wasn't a troll contrary to your pointless reply.

>A "linker" which doesn't actually LINK (i.e. COMBINE several object files together) is not a linker!

So is maketib a linker or not? I am quite confused by your replies. maketib uses one and only one object file with only one section.

Maketib is used where a linker would normally be used, but it isn't actually a linker, making it a hack.

Or to keep it short: It's a hack because it is used as a linker without actually being a linker.

Hmmm, each time I think of something more I should have added (and sorry, there will be 2 posts because of the size limit):

The maketib hack is the main reason why PedroM is constructed in the horrible, non-scalable way it is built, i.e. including all source files into the main source file. Normally, you'd use separate compilation, but that means using more than one object file and hence requires a real linker. Due to that design, together with the lack of linker optimization support, PedroM has come to rely on the order of source files in the top-level source at several places (mainly through the use of .w or .b references to external symbols) making it really hard to change anything, which is why I'm saying the approach doesn't scale. And I know what I'm talking about! I tried to adapt PedroM for separate compilation more than once, and each time I ran into issues like that. Even just separating the startup section from the main section (a Flash OS naturally has 2 sections due to TI's memory layout) turned out to require so many changes (which PpHd refused to merge) that I dropped it once A68k's line limit was no longer an issue (I made the change so the files would stay below the line limit, and was successful at that).

You forgot to say that 'maketib' was the only one linker available to produce a TIB when I start working on PedroM. ld-tigcc's TIB support was introduced 1.5 year latter.
So when I write maketib, I make a program which is as simple as it could be, but not more, so that I can start working on the really important part: PedroM.
As I said before, I would use 'ld-tigcc' as soon as you introduce flashos.a in tigcc.

> You forgot to say that 'maketib' was the only one linker available to produce a TIB when I start working on PedroM. ld-tigcc's TIB support was introduced 1.5 year latter.

It was introduced that late because you refused to code it (despite the small amount of work it represented compared to ld-tigcc itself). So Billy Charvet and me had to do all the work. Otherwise, it could have been there months earlier.

> So when I write maketib, I make a program which is as simple as it could be, but not more, so that I can start working on the really important part: PedroM.

Given that there was no infrastructure, you should have worked on the infrastructure first, rather than choosing the "quick hack" solution which lead to the "include" mess PedroM is now.

> As I said before, I would use 'ld-tigcc' as soon as you introduce flashos.a in tigcc.

See my answer below.

Have you looked at maketib.c? It is very small and simple. I didn't know anything about ld-tigcc complex scheme, so I would have lost much more time trying to understand how it works.

Have you looked at exp_os.c? http://tinyurl.com/dv7oa

Now admittedly, there's some logic at the point where sections are merged too:
#ifdef FLASH_OS_SUPPORT
// In Flash OS mode, if we are merging the startup and normal parts, pad the
// startup part to 32 KB.
if ((Program->Type == PT_FLASH_OS) && Dest->StartupNumber && (!(Src->StartupNumber)))
OrigSizePadded = 0x8000;
#endif /* FLASH_OS_SUPPORT */
...
#ifdef FLASH_OS_SUPPORT
// In Flash OS mode, the maximum size for the startup part is actually 8 KB less.
if ((Program->Type == PT_FLASH_OS) && Dest->StartupNumber && (!(Src->StartupNumber)))
MaxSize -= 0x2000;
#endif /* FLASH_OS_SUPPORT */

But this isn't any larger than maketib.c, because we get to re-use the object file import and linking routines already in ld-tigcc. We don't have to read the AmigaOS objects because ld-tigcc does it for us. We don't have to resolve references (something maketib doesn't support at all) because ld-tigcc does it for us. And we don't have to hardcode the Flash OS header because the startup code (which is automatically imported by the global import mechanism of ld-tigcc) does it for us. All we have to do is to relocate all absolute relocs (which maketib doesn't do either, it has the assembler do its job).

You forgot to mention all the stuff in flashos.a. And maketib is still simple to understand.

Flashos.a (in its current state) is all data, not a single line of code.

Really, the ld-tigcc port I did was just the easy part, the real work would be to redesign PedroM so it actually makes use of ld-tigcc's features, i.e. to compile each .asm file separately, and to stop hardcoding reference sizes and rely on linker optimization instead. Unfortunately, I don't think we can expect much (if any) support from PpHd for that. He doesn't care about his programs being easy to modify, indeed I think he'd rather we didn't modify them, despite the licensing. So everything is harcoded. He knows how big each reference should be (and even that isn't true, ld-tigcc caught some references in PreOs that should have been optimized, he might have fixed that since though), so he expects everyone else to know that too, rather than having the linker decide it automatically (and with separate compilation and section reordering, only the linker can know the correct size anyway).

1. I would use ld-tigcc when flashos.a is a part of tigcc , and not an external file to install.
2. I do a much better job than the linker in order to reduce branch size.
3. Except the C files, which I don't want to modify (That's the references ld-tigcc is able to optimize).
4. I don't think it is hard to modify. Just modify. If the assembler failed due to a branch size problem, just edit the source, and reassemble. Not so hard.
5. I don't know how big the reference are, but I know a68k complains if it is too small.

> 1. I would use ld-tigcc when flashos.a is a part of tigcc , and not an external file to install.

Why is that so important? Is it so hard to download a ZIP file? I'm not planning to include flashos.a with TIGCC because 99.9% of our users will never need it. And if it ever grows (due e.g. to hardware initialization startup code which could be imported with one line of ASM), it will mean users would have to get a large file they'd never use. Why force them to download something they won't use?

> 2. I do a much better job than the linker in order to reduce branch size.

I doubt that! The linker reduces all branch types to the minimum possible with a certain ordering (well, almost... it's actually the minimum possible without optimizing more than one branch at once, but that rarely matters), and it can even reorder the sections (of course, this assumes there is more than one, i.e. you'd have to add section separators to your sources and/or separate them into several object files) to achieve a better ordering (not 100% optimal because that would require exponential (even superexponential in my computations) effort, but probably better than you'll ever be able to). As I said, ld-tigcc already caught some suboptimal references in PreOs at some point.

>And if it ever grows (due e.g. to hardware initialization startup code which could be imported with one line of ASM),
Why do you plan to include such a thing? It seems a bad idea. An OS is not a program: it must do its initialization stuff itself!

>Why force them to download something they won't use?
So, could you please remove this IDE I never used in tigcc? It is far bigger than flashos.a

>I doubt that!
Well, I do function reordoning, and function merging, what the linker can't do, first. I use more hacks to allow branch size reduction that the linker do (and some are not usable at link time).

>As I said, ld-tigcc already caught some suboptimal references in PreOs at some point.
Are you talking about PreOS or PedroM?

>ot 100% optimal because that would require exponential (even superexponential in my computations) effort, but probably better than you'll ever be able to
Are you sure you can't use a better algorithm than a superexponential?

>but probably better than you'll ever be able to
Prove it.

> >And if it ever grows (due e.g. to hardware initialization startup code which could be imported with one line of ASM),
> Why do you plan to include such a thing? It seems a bad idea. An OS is not a program: it must do its initialization stuff itself!

To make OS development easier. All non-buggy OSes have to do a certain amount of initializations, it would be nice to have this by default. There could also be defaults for the interrupt vectors, or at least a startup section with pointers to interrupt vector symbols which then have to be defined in "user" code. My ideal is that everything which absolutely does require assembly is provided as a startup section, making it possible to write a Flash OS entirely in C.

> >Why force them to download something they won't use?
> So, could you please remove this IDE I never used in tigcc? It is far bigger than flashos.a

:-)
What about KTIGCC (the Linux IDE)? Will you use that one?

> >I doubt that!
> Well, I do function reordoning, and function merging, what the linker can't do, first.

The linker can do function reordering if you define a section per function as GCC does (with -ffunction-sections, which is now set by default in the IDE for new projects and recommended as a command-line option, along with -fdata-sections). The section reordering algorithm does that. You're right that it can't do any sort of code factoring (such as what you call "function merging") though.

> I use more hacks to allow branch size reduction that the linker do (and some are not usable at link time).

Hacks are bad. ;-)

>All non-buggy OSes have to do a certain amount of initializations, it would be nice to have this by default.
But it may change due to HW change.

>My ideal is that everything which absolutely does require assembly is provided as a startup section, making it possible to write a Flash OS entirely in C.
It is a non sense. At least, the Flash part, the battery part, the extinction part need to be written in assembly.

>What about KTIGCC (the Linux IDE)? Will you use that one?
emacs and uedit32 rulez.

>Hacks are bad. ;-)
It is called hack, but it is very safe, and easy to understand.

> >All non-buggy OSes have to do a certain amount of initializations, it would be nice to have this by default.
> But it may change due to HW change.

That's exactly the point, stuff which may change with a hardware change should be in the common startup code rather than requiring each and every OS to be updated. If it's in flashos.a, just rebuild with the new flashos.a and you're all set.

> >My ideal is that everything which absolutely does require assembly is provided as a startup section, making it possible to write a Flash OS entirely in C.
> It is a non sense. At least, the Flash part, the battery part, the extinction part need to be written in assembly.

Which is all common (independent of the actual OS), hardware-interfacing stuff that should be in flashos.a.

Do you plan to add a wizard to build an OS in less than 10 clicks, too?

LOL, no, M$-style app wizards aren't exactly a good way to get high-quality, diversified apps (they can only generate the same crappy skeleton for everyone), I don't think an OS wizard would be any more useful.

There's a difference between putting common code in libraries and trying to write a wizard to generate a full working OS.

I could write a simple OS (something on the functionality level of WORMHOLE's OpenOS, maybe even less) in C as an example for the library code at some point though. But first I need to write the library code, and I'm not even sure I'll have time for that, there's higher-priority stuff to do.

> >As I said, ld-tigcc already caught some suboptimal references in PreOs at some point.
> Are you talking about PreOS or PedroM?

PreOs. It finds potentially suboptimal references in PedroM too, but I don't know yet how many are caused by stuff which needs to be absolute because it is copied into RAM (and which should be explicitly marked ".l" to avoid the optimization!) and how many are genuinely suboptimal.

> Are you sure you can't use a better algorithm than a superexponential?

Maybe it's possible to do it "merely" in exponential time. I strongly doubt there is a polynomial algorithm for an optimal ordering, in fact I presume it is NP-hard, though I didn't prove it.
Sebastian's heuristic is fast and works pretty well (better than my slow one, which is now used only for startup sections because it can deal with the ordering constraints unlike Sebastian's, did).

> >but probably better than you'll ever be able to
> Prove it.

This is not something that can be proven mathematically, so I'll need some example to prove it empirically. Porting PedroM to use linker optimization to its full extent would be a lot of work. Do you have any suggestion for a smaller test case?

>Do you have any suggestion for a smaller test case?
No.

> 3. Except the C files, which I don't want to modify (That's the references ld-tigcc is able to optimize).

There are no C files in PreOs and still there were references which it could optimize.

> 4. I don't think it is hard to modify. Just modify. If the assembler failed due to a branch size problem, just edit the source, and reassemble. Not so hard.

That will still leave tons of references which just happen to fit with the current section ordering and will come back to bite you later. And besides, even that is tons of work. There's tons of bsr's or even bsr.b's to other source files in PedroM, and there's also the occasional x(pc,dn) addressing which is particularly annoying. With linker optimization, you just write jsr (or jbsr in GNU as), and ld-tigcc will figure the size out automatically. If you absolutely must have a jsr (e.g. because you're copying the code into RAM), write jsr (label).l and it will be honored (this has been like that since I added support for unoptimizable relocs - I'm not introducing TIGCC extensions into object file formats without a good reason!).

> 5. I don't know how big the reference are, but I know a68k complains if it is too small.

That only works as well as branch optimization in A68k works, which is even worse than in ld-tigcc! If you rely on that, there's no way you'll get a better result than just letting ld-tigcc do it. All references A68k can flag or optimize, ld-tigcc can flag and optimize too! And of course, the checks in A68k only work if the references are within the same file (yes, "include" counts as "in the same file", and no, doing this is not a good idea, that's what separate compilation is for). I think you're underestimating the power of linker optimization.

>There are no C files in PreOs and still there were references which it could optimize.
Which one? I know of a reference I can't optimize due to options (hw2tsr or not?).

>That will still leave tons of references which just happen to fit with the current section ordering and will come back to bite you later
Let's fix them when they came out. Not so hard.

>There's tons of bsr's or even bsr.b's to other source files in PedroM,
Are you sure? I don't think so.

>there's also the occasional x(pc,dn) addressing which is particularly annoying
What can I use instead in order to the linker to optimize it so that it is as small as x(pc,dn)?

>if you absolutely must have a jsr (e.g. because you're copying the code into RAM), write jsr (label).l
That's allready the case. Otherwise your ldtigcc's build wouldn't work.

>I think you're underestimating the power of linker optimization.
Well, GCC semms to change their mind, and wants to do all the compilation at link time to perform better optimization. Not so different that including all the source files inside one file and compile it. See GCC ML for details.

>That only works as well as branch optimization in A68k works,
I was talking about assembly failure, not the ability to a68k to optimize a branch.

> Which one? I know of a reference I can't optimize due to options (hw2tsr or not?).

That was at the time I was working on Iceberg, maybe it has been fixed since.

> Let's fix them when they came out. Not so hard.

I think that's not that good an idea, but it's probably the best we can do.

> >there's also the occasional x(pc,dn) addressing which is particularly annoying
> What can I use instead in order to the linker to optimize it so that it is as small as x(pc,dn)?

Well, don't use that across files (nor sections, if you start defining multiple sections per file). ;-)
If stuff has to be near in the object code, it'd better be near in the source code too!

> >if you absolutely must have a jsr (e.g. because you're copying the code into RAM), write jsr (label).l
> That's allready the case. Otherwise your ldtigcc's build wouldn't work.

I just turned off all the linker optimization because it broke things due to that issue. Maybe I should try to turn it on again. But it's not very useful anyway unless I turn on range cutting, which in turn forces me to fix your abuses of address differences (stuff like (label1-label2)/4).

> >I think you're underestimating the power of linker optimization.
> Well, GCC semms to change their mind, and wants to do all the compilation at link time to perform better optimization. Not so different that including all the source files inside one file and compile it. See GCC ML for details.

That only shows to me that they have realized how much the linker can do to optimize things. :-)

> I was talking about assembly failure, not the ability to a68k to optimize a branch.

Oh, sorry, I was assuming you're talking about a68k -f. Anyway, you can count on ld-tigcc to optimize branches properly (if you have branch optimization and range cutting turned on).

>Well, don't use that across files (nor sections, if you start defining multiple sections per file). ;-)
>If stuff has to be near in the object code, it'd better be near in the source code too!
Of course!

>which in turn forces me to fix your abuses of address differences (stuff like (label1-label2)/4).
That's the main failure of your linker. This syntax is very useful.

GCC never generates code like that and I've never used it in my own assembly programs. Still, this is an issue I haven't completely forgotten, it's just that I'm still wondering how to represent this best in the object code. I also must say I'm not very pleased by the idea of some more A68k hacking (support for address differences in A68k is already a horrible hack), but I also know that if I implement this in GNU as only, it won't make you happy (unless I get GNU as to eat A68k syntax, but there's lots of stuff to do to get there).

>GCC never generates code like that
Of course!
GCC doesn't even assume it has a working assembler.

Does the tigcc linker give any size improvement?

No, because PedroM doesn't support any linker optimization. :-(

I think KK talked about 20 jsr which could be translated to bsr, in a previous build of PedroM (only in the translated C files). So 40 bytes for a TIB of 128K... Not too much. Maybe he could confirmed?

>is really fully GPL. PpHd's build includes non-Free components.
You should have said that you have build it with the PedroM option 'GPL=-vGPL'. PedroM's license gives a little more freedom than the GPL since it allows linking with some GPL incompatible components. That's all.

I also deleted the non-Free source files and removed any references to them from the makefile (because otherwise it would still try to build them even though it doesn't actually use them).

This entire thread (It's not so much a thread anymore, but a mountain or a mountain range. Sierra?) is most educational. I now know more about compilers, linkers, how a compiler works, and assembly than I ever thought there was to know. I bow before both of your extreme knowledge.