What Needs Fixed In Huc?

[TheOldMan]

Moved discussion from 'MSR is finished" to here.
................

Stuff I would want to see:

-Fix array access (as above)

Dunno about that. No really good way to do indexing, especially with the need to manage pages....
But I'll think on it some more.

-"Auto-backpacking" (as above too)

Please explain. Are we talking about packing the code pages better? It should be doable, but I haven't checked out how pceas (yes, that's where it's done) decides which page to use. I -think- it just uses the current one; to pack them, it might have to insert some mapping code, which could be a nightmare..

-Remove the utterly useless gfx plotting routines (already did this here)
-Remove the broken sound code that just wastes space in hucard building

I'll go one farther. Split the library up so if you need something, you can turn it 'on', and if you don't, you can turn it 'off'. So when you don't need the gfx stuff, you don't get it included.

-Optimize scroll()

I'm shooting for integrating the new magickit scroll first. Optimization is a pita. But possibly we can write a tool to do something like that. (ie, optimizations)

-Better mapper functions that support more than 256 unique tiles
-Getting rid of scan_map_table() and making the mapper support height/width greater than 256

I'm not even touching that, except to possibly make it optional. It should be doable, though.

-Add ACD and SGX capabilities to hulib (Tom did this already)
-Modify compiler/assembler to take advantage of the extra 24KB of SGX work RAM

Don't know anything about the sgx. Probably would be better to clone Huc/Magickit for it, though.

-More intelligent verbose code output (backslashes screw it up at present)
-struct support

Yeah. Not likely, the way the code is set up. Would take some fairly serious work for structs....

-C++ style comments (would help with verbose output, I think)

Have that.

-goto keyword (being forced to do this in assembly is lame)

But then you run into problems jumping to different pages. Besides, my CS professors always told me you don't need to use gotos... and so far, I haven't.

-Expansion of the overlay table (50 is fine until you get serious)
-The addition of a 24 bit variable type for addressing (there's one internally but it's not exposed)
-Much more intelligent use of zero page
-ADPCM streaming (Tom coded one, so I have it in my hulib)

The expanded pointer, I could see. Expanding the overlay table would require a complete re-write of the cd init stuff. (Believe it or not, parts of it have to be in specific places. Especially the overlay stuff, which has a minor bug in it.)

I probably have more but this is about all I can think of for now. I've tried to fix things myself but it's just a nightmare... the code is a mess and things aren't done optimally.

LOL. It started out as a student project, so I don't expect much from it. I would like to do some re-naming of the functions, just so I can figure out wtf is going on.

[Arkhan]

Dunno about that. No really good way to do indexing, especially with the need to manage pages....
But I'll think on it some more.

I *might* have an answer for that, I'll dig through the book or let you borrow it since I don't have tons of free time til December...

I'll go one farther. Split the library up so if you need something, you can turn it 'on', and if you don't, you can turn it 'off'. So when you don't need the gfx stuff, you don't get it included.

Stop making so much sense!    Removing the broke-as-hell sound code that is in HuC already might be a good idea in the first place though.  If we remove all traces of it and replace it with our proven-to-be-working library, that may be nice.  It will force people to use Squirrel/MML, but hey, tough shit.  It's not like Squirrel and MML are hard to use. 

Don't know anything about the sgx. Probably would be better to clone Huc/Magickit for it, though.

It's basically 2x the PCE. You know alot about it without realizing it, .  There are some super grafx things floating around.  I think wasting time supporting the Super grafx and it's 10 owners who give a damn isn't really worth the effort.   What about you?   There are more pressing things to fix in HuC

Yeah. Not likely, the way the code is set up. Would take some fairly serious work for structs....

Yep, and besides, ghetto-structs work.  Insanity is living proof.

But then you run into problems jumping to different pages. Besides, my CS professors always told me you don't need to use gotos... and so far, I haven't.

I agree, GOTO is the enemy. It doesn't belong in here.  Doing it with ASM if you absolutely need it isn't really hard anyway.  The amount of work spent during all the times youd possibly do it with ASM won't add up to how much effort it'd be to support it in HuC...

The expanded pointer, I could see. Expanding the overlay table would require a complete re-write of the cd init stuff. (Believe it or not, parts of it have to be in specific places. Especially the overlay stuff, which has a minor bug in it.)

It's like a house of cards.

LOL. It started out as a student project, so I don't expect much from it. I would like to do some re-naming of the functions, just so I can figure out wtf is going on.

I'd be willing to go one further with this and document the whole thing better.  The documents out there aren't very good (even has things in it like "Im too lazy / tired / or something to do documentation". 

[nodtveidt]

goto is just fine. Why is it going to be a big deal in HuC? It's just a jmp to a label. And you only ever do it inside a proc anyway... it's not like you can goto a label in another proc. And any CS professor that talks about "the evils of goto" is just parroting the same old tired and thoroughly debunked rant from the 70s.

[Arkhan]

goto is just fine. Why is it going to be a big deal in HuC? It's just a jmp to a label. And you only ever do it inside a proc anyway... it's not like you can goto a label in another proc. And any CS professor that talks about "the evils of goto" is just parroting the same old tired and thoroughly debunked rant from the 70s.

thoroughly debunked is debateable.  Goto removes the structure of the code and introduces all kinds of hopping around.  It can goon up maintainability.  It's like giving a chimp a loaded handgun.  He might be careful with it, or he might start shooting everyone in the knees.

BASIC is living proof that goto leads to a bad time.  It was a neccessary evil for BASIC.  With C, let the logic pull things around.  Any time you're using goto, there's probably another way to do it that uses no goto.


How often do you really need goto? I can't imagine you needing it super-often to the point where it's becoming so tedious to do that you really need built in support for it, lol.

from the 70s.

You know, he isn't called "TheOldMan" because hes young.

lol.

[nodtveidt]

It was a bitch to code parts of the menu in MSR without goto support. Without goto, you end up having to do something else instead, and the end result may not be as optimal. And if the generated code ends up being reduced to a jmp anyway, then you might as well just have had goto support in the first place. Say what you will about code readability and hopping around, but the CPU doesn't care about your code readability and it hops around all the time. If you can't follow program flow with goto, then you have other issues to resolve anyway.

A bad coder is a bad coder regardless of what language he's using, what compiler he's using, or what procedures he's using. It's not up to us to dictate good coding form. Some of my code, though it executes perfectly and is highly efficient, would make some CS majors cry... I don't follow any coding standards besides my own, and some of my techniques fly in the face of "accepted good form". f*ck "accepted good form".

But how often do you need goto? I don't know... but you could ask that question for anything, really. Like, when I didn't need the gfx_ procs in hulib, I just cut them out.

About the chimp with the loaded handgun... well, you can apply that to a lot of different scenarios. I remember a similar argument being made when MFC was new... everyone was suddenly afraid of armed chimps.

[TheOldMan]

Not debating whether goto is a good thing or a bad thing. In the wrong hands, it makes code a mess. In the right hands (which are few and far between), it makes things better. It depends on who is using it....

goto is just fine. Why is it going to be a big deal in HuC? It's just a jmp to a label. And you only ever do it inside a proc anyway... it's not like you can goto a label in another proc.

First, "just a jump to a label" means you have to recognize the label. As distinct from a leading name. So all that code would have to be inserted.

Second, all labels are global. You CAN jump to a label in another proc. But more seriously, you can jump into the middle of a section of code (ie, inside an if statement or loop) which would cause major problems with what the code expects.
Trying to enforce  'you can't do that' to prevent such things is way beyond the capabilities of HuC as it stands.
Not saying it -can't- be done, just placing it up there with structs: it would be nice, but not with the current state of the code


So, which of those fixes do you think would be easiest to do? And, aside from arrays (we all know that sux), which would be most important?

You know, he isn't called "TheOldMan" because hes young.

Too true. And I walked 5 miles uphill, barefoot in the snow to school.
Both ways

[nodtveidt]

A proper compiler knows that you can't goto a label outside of a function. It's the job of the compiler to ensure that labels outside of the proc are never jmp'd to. But anyway, it doesn't really matter... it's a minor thing. I wouldn't really miss it if it wasn't implemented. Of course, everything can be made a mess in the wrong hands...

As far as the most important bits... I would say bank optimization (top issue), library modularization (second most important issue), and 24 bit variables for addressing purposes. Whether or not any of these are easy is another story.

[Arkhan]

A proper compiler knows that you can't goto a label outside of a function. It's the job of the compiler to ensure that labels outside of the proc are never jmp'd to. But anyway, it doesn't really matter... it's a minor thing. I wouldn't really miss it if it wasn't implemented. Of course, everything can be made a mess in the wrong hands...

Right, but all of that checking/security/enforcement has to be put in place in the compiler lol... it sounds easy on paper until you start to implement it and realize all of the overhead...which is why doing it manually with assembly is less work.  Just stick it in where you need it.  You don't have to generalize it's use if you are manually doing it for your specific case that arose where you need a goto. 

[Keranu]

I have not understood a single word from this thread.

[Arkhan]

I have not understood a single word from this thread.

Blazing Lazers.

Happy?

[Keranu]

PERFECT, thank you!

[TheOldMan]

A proper compiler knows that you can't goto a label outside of a function

Are we still talking Huc here? BTW, I just checked in gcc, and I get one complaint, about the label not being defined. So yeah, I guess jumping to labels in other routines would be the compilers problem. But it would still involve adding code to recognize when you have a label, modifying the symbol table layout, etc. Doable, but not easy until the code gets cleaned up

As far as the most important bits... I would say bank optimization (top issue), library modularization (second most important issue), and 24 bit variables for addressing purposes.

I would swap the first two around: modularize the libraries first, then work on bank optimization.
Why? Because the libraries would need changed to use/respect the .proc/.endproc markers, otherwise they will still end up in one huge bank. My biggest problem there is that is definately going to break existing code - not that I care that much. The old version would still be available.

And, fwiw, it's a lot harder than it seems to modularize the libraries. Several of the routines are just wrapper calls that map things in, execute the code, and then restore the original mapping. Which wouldn't be too bad if the assembler code didn't flip-flop banks seemingly at random. I'm still tracking down exactly what code runs in what bank

I may look into bank optimization, though. I suspect it would require more than either of us think. To do it right, you would have to generate the code in a temp area, find the page it would fit 'best' in, and then go back and patch all the addresses... At least, that's what I -think- it would take.

[nodtveidt]

I may look into bank optimization, though. I suspect it would require more than either of us think. To do it right, you would have to generate the code in a temp area, find the page it would fit 'best' in, and then go back and patch all the addresses... At least, that's what I -think- it would take.

I would probably do something along those lines... generate each proc and account for the sizes, then starting from the largest, find smaller procs that would be the best fit for its bank. It's not easy, but hey, I'm not afraid of hard work.

[Arkhan]

And, fwiw, it's a lot harder than it seems to modularize the libraries. Several of the routines are just wrapper calls that map things in, execute the code, and then restore the original mapping. Which wouldn't be too bad if the assembler code didn't flip-flop banks seemingly at random. I'm still tracking down exactly what code runs in what bank

Yes, very annoying.  The flip flopping is irritating.



Keeping track of labels properly for goto'ing doesn't seem like it would really be worth the amount of time it would take to get it in and working properly.   

Rover, or Touko, do you have any C GOTO examples that would really sway my opinion here?

[nodtveidt]

Not really. It's just a matter of code generation. The output from a goto is going to be less than other methods, and every byte counts here. And furthermore, if someone were to try to goto a label outside of the function, f*ck 'em... they're a stupid coder anyway.