Openoffice-os4 May 2005

openoffice-os4@samfundet.no

17 participants
9 discussions

realloc()
by Rene W. Olsen 25 Jun '05

25 Jun '05

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

3 6

Getting involved
by Thomas Frieden 08 Jun '05

08 Jun '05

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

7 18

A general question
by Thomas Frieden 06 Jun '05

06 Jun '05

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

6 15

Update time
by Mark Bond 31 May '05

31 May '05

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)

9 11

My Email has changed
by Martin Merz 17 May '05

17 May '05

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...

1 0

My Email has changed
by Martin Merz 17 May '05

17 May '05

1 0

...
by Info - Amigaplatform 13 May '05

13 May '05

Hi to all, what about amiga openoffice ? Is the porting delayed ? Cancelled o stopped ? The mailing list is empty of news... Regards

6 12

Re: [OO.org-OS4] Getting involved - coding
by Belxjander Serechai 03 May '05

03 May '05

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

5 5

Re: [OO.org-OS4] Re: Getting involved - coding
by Belxjander Serechai 02 May '05

02 May '05

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

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

Openoffice-os4 May 2005