-
Notifications
You must be signed in to change notification settings - Fork 601
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Move libultra functions and variables to libultra headers #1468
base: main
Are you sure you want to change the base?
Conversation
Not sure where to start reviewing but I noticed |
In the three MIPS cross compilers I have installed ( Supposedly |
INC := -Iinclude -Iinclude/libc -Isrc -Ibuild -I. | ||
build/src/libultra/%.o: INC := -Iinclude/libc -Iinclude/ultra64 -Isrc/libultra |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I can't say I'm a fan of the include path not being the same throughout the repo
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it's just more correct than using ultra64/...
paths in libultra files, and libultra files ideally shouldn't see any headers from the base include dir (although unfortunately as I mentioned I still couldn't get rid of two headers yet)
It may be better if we moved src/libultra
to say lib/libultra
with it's own makefile or something, but that's a bit too far of a departure from what I wanted to achieve for now (but I think doing this later may be good)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah I understand the appeal when looking at libultra specifically/separately and I agree libultra should be completely cut off from the rest, my beef is mostly/only that it's confusing when navigating the repo
It would be nice to document this somewhere other than "self-documenting" in the Makefile. I wouldn't be opposed to a README
file in src/libultra and include/libultra but idk if that would be a popular suggestion
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@@ -1,11 +1,10 @@ | |||
#include "global.h" | |||
#include "ultra64/internal.h" | |||
#include "osint.h" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
#include "osint.h" | |
#include "internal.h" |
(This is the least-stuff-inside meaningful header, right?)
@@ -34,4 +37,12 @@ | |||
#define VINTR(v) v | |||
#define HSTART START |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should the OSViMode
related macros be in vi.h instead ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm hesitant to do this since we know what should be in vi.h
(os_vi.h
), but we don't have a reference viint.h
so we can put just about whatever we like in there.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Forgetting about the original headers, I think it makes more sense for them to be with the OSViMode
definition,
but I'll leave it up to you and the "follow the original headers" stance
@@ -1,4 +1,4 @@ | |||
#include "global.h" | |||
#include "guint.h" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
#include "guint.h" | |
#include "gu.h" |
Note I don't know what you're going for with includes
I assume they should be minimal?
But for example would a
#include "guint.h"
->
#include "ultratypes.h"
#include "gu.h"
be better if something didn't need what guint.h itself contains?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've mostly been using the *int
headers for each libultra module, since I believe that's how it was originally based on mdebug includes, but maybe a more minimal approach is just better idk. Though note that as I mention below the minimal set of includes must also contain the prototype for the functions in the file, not just the necessary external declarations that the function(s) uses.
@@ -1,4 +1,5 @@ | |||
#include "global.h" | |||
#include "rcp.h" | |||
#include "rdp.h" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
#include "rdp.h" |
?
and dpgetstat
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
rdp.h
contains the prototype for osDpSetStatus
, the header containing the prototype needs to be included so the compiler can warn/error if the prototype does not match the function itself
Very interesting last set of changes! |
So far I've only been removing the ultratypes from libc files/functions, since libc shouldn't know anything about libultra. Otherwise I have no current plans to start removing them elsewhere |
#define OS_DCACHE_ROUNDUP_ADDR(x) (void*)(((((u32)(x) + 0xf) / 0x10) * 0x10)) | ||
#define OS_DCACHE_ROUNDUP_SIZE(x) (u32)(((((u32)(x) + 0xf) / 0x10) * 0x10)) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
#define OS_DCACHE_ROUNDUP_ADDR(x) (void*)(((((u32)(x) + 0xf) / 0x10) * 0x10)) | |
#define OS_DCACHE_ROUNDUP_SIZE(x) (u32)(((((u32)(x) + 0xf) / 0x10) * 0x10)) | |
#define OS_DCACHE_ROUNDUP_ADDR(x) (void*)(((((u32)(x) + 0xF) / 0x10) * 0x10)) | |
#define OS_DCACHE_ROUNDUP_SIZE(x) (u32)(((((u32)(x) + 0xF) / 0x10) * 0x10)) |
u32 osAiGetLength(void); | ||
s32 osAiSetFrequency(u32); | ||
s32 osAiSetNextBuffer(void*, u32); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Curious was it deliberate to leave out the arg names here, and just use types?
#define GU_PI 3.1415926 | ||
|
||
#define ROUND(x) (s32)(((x) >= 0.0) ? ((x) + 0.5) : ((x) - 0.5)) | ||
|
||
void guMtxIdent(Mtx*); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Relating to the arg question again, some functions here have arg names and some don't. Any particular reason why?
|
||
// Static/compile-time assertions | ||
|
||
#if defined(__GNUC__) || (__STDC_VERSION__ >= 201112L) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Wouldn't just
#if defined(__GNUC__) || (__STDC_VERSION__ >= 201112L) | |
#if (__STDC_VERSION__ >= 201112L) |
be enough / make more sense? (unless gcc did have the macro way before C11)
#ifndef ISVIEWER_H | ||
#define ISVIEWER_H | ||
|
||
#include "ultra64.h" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should this include be in the .c only? It's not needed by the .h, I think
// Load cart callback set by __osSetHWIntrRoutine | ||
lui $t1, %hi(__osHwIntTable) | ||
addiu $t1, %lo(__osHwIntTable) | ||
lw $t2, (OS_INTR_CART*HWINT_SIZE+HWINT_CALLBACK)($t1) | ||
lw $t2, (OS_INTR_CART*HWINT_SIZE+HWINT_HANDLER)($t1) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
since HWINT_CALLBACK
-> HWINT_HANDLER
, should references to "callback" in sentences be changed too?
#include "global.h" | ||
#include "internal.h" | ||
|
||
s32 osAfterPreNMI(void) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So per the comment about includes #1468 (comment)
should this include system.h
? (with the osAfterPreNMI
prototype)
The same kind of comment seems to apply to other files
void bzero(void* __s, size_t __n); | ||
int bcmp(const void* __sl, const void* __s2, size_t __n); | ||
void bcopy(const void* __src, void* __dest, size_t __n); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The original libultra headers use int
instead of size_t
. Why deviate from the original headers here?
Also, why the __
prefix on the arguments?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
IIRC int
is required for matching anyway. Currently in HEAD it's
#ifdef __GNUC__
void bzero(void* __s, unsigned int __n);
int bcmp(const void* __sl, const void* __s2, unsigned int __n);
void bcopy(const void* __src, void* __dest, unsigned int __n);
#else
void bzero(void* __s, int __n);
int bcmp(const void* __sl, const void* __s2, int __n);
void bcopy(const void* __src, void* __dest, int __n);
#endif
idk what this entails but theres also the "modern n64 sdk" which includes the entirety of libultra. the legality is murky at best. |
We'll eventually need at least part of this PR revived for header cleanup. The goals with libultra should be clarified: align with ultralib? if not, which includes in .c files (IWYU ?) ? |
Not totally happy with this, since
macros.h
and the newstack.h
are not libultra headers but are still used in some libultra files for now, however this is the bulk of the changes and further improvements will inevitably be found.