Hello,
I don't know what realloc() does, the code looks like this
while (size > 0) {
interface->altsetting = realloc(interface->altsetting, sizeof(struct usb_interface_descriptor) *
(interface->num_altsetting + 1));
if (!interface->altsetting) {
if (usb_debug >= 1)
fprintf(stderr, "couldn't malloc interface->altsetting\n");
return -1;
}
....
}
So I was wonder is its extend or just allocating a new block of memory?
Kind regards
Rene W. Olsen
Hi,
To dispell the silence a bit (hehe, any D&D fans here ;), I thought I'd
write a mail here :)
Ok, the purpose is this: Since I now have more time, I would like to
become actively invovled (actively as in "I want to write some code").
Are there any projects up for grabs that I can look into ?
Regards,
--
Thomas Frieden <ThomasF(a)hyperion-entertainment.biz>
Hyperion Entertainment
- Naur dan i-deryg lhuin
Hi,
I'd like to ask a more general question regarding the porting effort. As
we all have seen, activity died down after an initial euphoria. This is
dangerous as it might lead to a complete standstill.
Therefore, the question is this: Currently, work is underway to get the
dependencies ported. But in the very early stages, some of them aren't
really needed. So theoretically, work could be started on the low-level
parts of OpenOffice itself, for example the build environment and SAL,
resolving dependencies as they come up, maybe even creating "dummies"
for seldom-used functionality (for example, I've never used any USB
stuff with OpenOffice).
Ok, that's just food for thought.
BTW, OOo builds via dmake, which we already ported (SNAP also builds
with dmake). It just depends on newlib V3 which will be in the next update.
Regards,
--
Thomas Frieden <ThomasF(a)hyperion-entertainment.biz>
Hyperion Entertainment
- Naur dan i-deryg lhuin
Hi All,
Its that time again...
Can everyone provide an update of their status please (ie no time anymore,
status of porting projects/tasks etc).
Regards,
Mark
(Assitant to Project Manager)
Hi All,
I've changed my ISP, and the old email address will expire in a view days.
Please use mason at masonicons.de to contact me.
Thanks in advance.
Kind Regards,
Martin "Mason" Merz
www.masonicons.de
I've seen things you people wouldn't believe...
Hi All,
I've changed my ISP, and the old email address will expire in a view days.
Please use mason at masonicons.de to contact me.
Thanks in advance.
Kind Regards,
Martin "Mason" Merz
www.masonicons.de
I've seen things you people wouldn't believe...
I can answer some questions about assembler...
as conversion from Assembler -> C is what appears
to be the case...
When it comes to the OS libcall mechanism thats fine
you't have to know the calls and arguments only
for the project internal functions...
re-compilation would be interesting but simplistic
as long as everything is accounted for
I don't have any style tips for code-layout
but suggest you break up the assembler and
check what sections are "re-usable"
reworking functions accordingly
--- Tony Wyatt <wyattaw(a)optushome.com.au> wrote:
> Hi Thomas,
>
> On 2/05/2005, you wrote:
>
> > Are there any projects up for grabs that I can
> look into ?
> >
> What about some advice on coding habits? I'd ask
> privately, but the answer
> will be of general interest anyway, both in the
> project I am currently
> working on and those in the future like OO and
> Kaffe.
>
> Much old 68k code is fast and efficient because it
> relies on parameters like
> library and structure pointers remaining persistent
> in allocated 68k
> registers, eg a2, a6 always point to particular
> structures. In a big
> module consisting of dozens if not hundreds of very
> small functions, only
> one or two registers are ever used for volatile
> data. Most parameters are
> passed in assumed registers, so loading of arguments
> is minimised.
>
> So what is a good way to maintain this register
> shortcut in a C version of a
> big program originally written in assembler?
> Obviously I can specify
> parameters to be passed in 68k registers, but I am
> trying to write this thing in
> a portable fashion, machine-independent.
>
> I have no experience with PPC code yet. Is there a
> way to ask gcc to use
> registers for certain parameters, in a
> platform-independent way? I want the
> C code to remain pure ANSI-compliant. It would be
> nice to leave the code
> unchanged from its present SAS/C environment to PPC
> and gcc.
>
> cheers
>
>
> _______________________________________________
> Openoffice-os4 mailing list
> Openoffice-os4(a)samfundet.no
>
https://lists.samfundet.no/mailman/listinfo/openoffice-os4
>
Find local movie times and trailers on Yahoo! Movies.
http://au.movies.yahoo.com
Faster to convert the M680x0 assembler directly
to PowerPC assembler
conversion to C is a different skill and keeping
fixed registers for the lifetime of the program
whomever wrote that code has created issues for
anyone trying what you want... as registers don't
map properly outside assembler
--- Tony Wyatt <wyattaw(a)optushome.com.au> wrote:
> Hi Belxjander,
>
> Maybe I didn't describe it very well. The project is
> to convert 68k
> assembler into C that can be compiled on the A1 to
> native PPC code. But
> there are some other implied requirements, for
> example, it must run like
> greased lightning and be portable code that can be
> easily recompiled for the
> next platform that AOS is ported to.
>
> I have translated most of the 68k assembler into
> ANSI C, and I use SAS/C to
> compile it into 68k binary. That binary runs on my
> A4000 and on the A1
> (emulated) exactly the same way as the original
> assembler version. When the
> translation and debugging of the C version is
> complete, I will use GCC to
> compile it for PPC on the A1.
>
> The 68k code depends on a2, a3, a6 always pointing
> to particular structures.
> That makes it quick to call a function, because
> those registers do not have
> to be set up before the call. In C, though, I have
> to pass the pointers as
> function arguments each time. I *could* define a
> proto that uses 68k
> registers, but that would be useless when I
> recompile the C code for the
> PPC. Meantime I am stuck with having to load
> arguments onto the stack for
> the simplest function call, which in the 68k
> assembler case, might not have
> to load any registers at all. Bloody slow.
>
> So the question is really: is there a
> platform-independent way to
> allocate some registers as permanent pointers,
> persistent over the whole
> program? Has this problem come up elsewhere in OS4?
> What have other
> developers done?
>
> cheers
>
>
> _______________________________________________
> Openoffice-os4 mailing list
> Openoffice-os4(a)samfundet.no
>
https://lists.samfundet.no/mailman/listinfo/openoffice-os4
>
Find local movie times and trailers on Yahoo! Movies.
http://au.movies.yahoo.com
