• Federico (3/3) Jul 30 2002 Does anyone know how to make a linker different than OPTLINK work with D...
• Walter (4/7) Jul 30 2002 DMC?
• Federico (5/6) Jul 31 2002 I tried Borland Tlink 5.0, Blinker 5.1 and Alink 1.6. Each one complains...
• Walter (5/9) Jul 31 2002 or
• Federico (13/15) Jul 31 2002 I agree, but it fails as soon as the data declared at file scope exceed ...
• Walter (10/20) Jul 31 2002 MB
• Federico (112/113) Aug 01 2002 Please, find below outputs of Alink, Blinker, Tlink. The latter gives no
• Jan Knepper (5/120) Aug 01 2002 What about the DM Linker???
• Federico (18/21) Aug 02 2002 Thanks Jan, you are obviously write (and I'm a stupid :-( ). Your messag...
• Jan Knepper (4/12) Aug 02 2002 Well, I guess that answers your question about blinker...
• Federico (8/12) Aug 03 2002 A dialog box appears. The title is:
• Jan Knepper (4/18) Aug 03 2002
• Federico (6/8) Aug 04 2002 Yes. I'm not used to hide information to people helping me... ;-)
• Walter (40/155) Aug 01 2002 1) Record type BC is a COMDAT record - perfectly valid. Bug in Alink.
• Federico (4/13) Aug 02 2002 I never said "SNN.LIB causes problems".
• Walter (3/4) Aug 02 2002 You're right, you did not. I apologize.
• Federico (9/9) Aug 03 2002 Thanks to everyone who replied. Now that I solved the problem and I'm ha...
• Jan Knepper (3/6) Aug 03 2002 I thought it is currently being sold for $50???
• Federico (6/7) Aug 04 2002 http://www.digitalmars.com/shop.html says $25, PayPal charged me $25 + $...
• Heinz Saathoff (14/22) Jul 31 2002 Why not allocating a big buffer on startup? It shouldn't make much
• Federico (39/45) Aug 01 2002 Sorry, it does.
• Jan Knepper (4/12) Aug 01 2002 Could you give an example in 'code' of what you are doing and how static...
• Federico (217/219) Aug 03 2002 Well, today I had some time to look at generated assembler and I happene...
• Federico (4/13) Aug 04 2002 Should someone be interested in, I forgot to mention compiler options. I...
• Walter (8/12) Aug 01 2002 (if
• Heinz Saathoff (27/40) Aug 02 2002 Do you do the matrix multiply in a function taking the matrices as
• Federico (10/21) Aug 03 2002 Look at the codes I sent, please.

Federico <Federico_member pathlink.com> writes:

Does anyone know how to make a linker different than OPTLINK work with DMC?
Thanks
Federico

"Walter" <walter digitalmars.com> writes:

"Federico" <Federico_member pathlink.com> wrote in message
news:ai6u1h$13c6$1 digitaldaemon.com...
 Does anyone know how to make a linker different than OPTLINK work with

DMC?
 Thanks
 Federico

Any linker that works with standard omf files should work.

Federico <Federico_member pathlink.com> writes:

In article <ai76ug$1i17$2 digitaldaemon.com>, Walter says...
Any linker that works with standard omf files should work.

I tried Borland Tlink 5.0, Blinker 5.1 and Alink 1.6. Each one complains or
aborts with an error.

Any idea?
Federico

"Walter" <walter digitalmars.com> writes:

"Federico" <Federico_member pathlink.com> wrote in message
news:ai82eo$304b$1 digitaldaemon.com...
 In article <ai76ug$1i17$2 digitaldaemon.com>, Walter says...
Any linker that works with standard omf files should work.

 I tried Borland Tlink 5.0, Blinker 5.1 and Alink 1.6. Each one complains

or
 aborts with an error.

If optlink links the code successfully, I don't understand what the problem
is. Optlink is far and away the best linker ever written.

Federico <Federico_member pathlink.com> writes:

In article <ai84un$2s6$1 digitaldaemon.com>, Walter says...
If optlink links the code successfully, I don't understand what the problem
is. Optlink is far and away the best linker ever written.

I agree, but it fails as soon as the data declared at file scope exceed 40 MB
total.
As you maybe remember, we had this discussion a few months ago: DMC produces
very fast executables, better then any competitor. However, if I use dynamic
memory allocation, speed degrades by 30 percent. Still better than other
compilers using dynamic allocation, but worse than other compiler on huge static
data.
I'm trying to find a way out of the problem.

BTW. If I declare the big arrays 'static', Blinker does not complain anymore on
the .obj, but has problems with SNN.LIB. The same happens with Borland Tlink.

Any clue?

Federico

"Walter" <walter digitalmars.com> writes:

"Federico" <Federico_member pathlink.com> wrote in message
news:ai9mrp$22dq$1 digitaldaemon.com...
 I agree, but it fails as soon as the data declared at file scope exceed 40

MB
 total.

Ok, I remember now.

 As you maybe remember, we had this discussion a few months ago: DMC

produces
 very fast executables, better then any competitor. However, if I use

dynamic
 memory allocation, speed degrades by 30 percent. Still better than other
 compilers using dynamic allocation, but worse than other compiler on huge

static
 data.
 I'm trying to find a way out of the problem.

 BTW. If I declare the big arrays 'static', Blinker does not complain

anymore on
 the .obj, but has problems with SNN.LIB. The same happens with Borland

Tlink.

What problems with snn?

Federico <Federico_member pathlink.com> writes:

In article <ai9qud$27he$1 digitaldaemon.com>, Walter says...
What problems with snn?

Please, find below outputs of Alink, Blinker, Tlink. The latter gives no
information, but the problem happens as soon as SNN.LIB is accessed.

Moreover, if the big arrays at file scope are not declared static, both
alink and blinker complains on the .obj generated from my source code.

Maybe I'm stuck in a stupid problem, I apologize but I'm not an expert in
linking under Win32.

Federico


-----------------Alink------------------------------

e:\eee\ramspeed\qq>alink -oPE -subsys con rs.obj USER32.LIB KERNEL32.LIB
ALINK v1.6 (C) Copyright 1998-9 Anthony A.J. Williams.

All Rights Reserved


Loading file rs.obj

Loading file USER32.LIB

Loading file KERNEL32.LIB

Loading file SNN.lib


Error in file at 000000EE - unknown object module record type BC

name count = 19

seg count = 8

extcount=10

grpcount=2

comcount=4

fixcount=18

impcount=0

expcount=0


e:\eee\ramspeed\qq>

--------------------Blinker-----------------------------

e:\eee\ramspeed\qq>blinker file rs.obj lib user32.lib lib kernel32.lib

BLINKER : 1115 : SNN.LIB(BUILDENV) : '__IMP__MULTIBYTETOWIDECHAR 24' :
unresolved external
BLINKER : 1115 : SNN.LIB(CLOCK) : '__IMP__GETTICKCOUNT 0' : unresolved external
BLINKER : 1115 : SNN.LIB(GETENV) : '__IMP__GETENVIRONMENTVARIABLEA 12' :
unresolved external
BLINKER : 1115 : SNN.LIB(ISATTY) : '__IMP__GETFILETYPE 4' : unresolved external
BLINKER : 1115 : SNN.LIB(LOCTIME) : '__IMP__GETTIMEZONEINFORMATION 4' :
unresolved external
BLINKER : 1115 : SNN.LIB(SEMLOCK) : '__IMP__CLOSEHANDLE 4' : unresolved external
BLINKER : 1115 : SNN.LIB(SEMLOCK) : '__IMP__CREATESEMAPHOREA 16' : unresolved
external
BLINKER : 1115 : SNN.LIB(SEMLOCK) : '__IMP__WAITFORSINGLEOBJECT 8' : unresolved
external
BLINKER : 1115 : SNN.LIB(SEMLOCK) : '__IMP__RELEASESEMAPHORE 12' : unresolved
external
BLINKER : 1115 : SNN.LIB(SETMBCP) : '__IMP__GETACP 0' : unresolved external
BLINKER : 1115 : SNN.LIB(SETMBCP) : '__IMP__GETOEMCP 0' : unresolved external
BLINKER : 1115 : SNN.LIB(SETMBCP) : '__IMP__GETCPINFO 8' : unresolved external
BLINKER : 1115 : SNN.LIB(SETNTERR) : '__IMP__GETLASTERROR 0' : unresolved
external
BLINKER : 1115 : SNN.LIB(TIME) : '__IMP__GETLOCALTIME 4' : unresolved external
BLINKER : 1115 : SNN.LIB(TOLOWER) : '__IMP__LCMAPSTRINGA 24' : unresolved
external
BLINKER : 1115 : SNN.LIB(XCFILTER) : '__IMP__UNHANDLEDEXCEPTIONFILTER 4' :
unresolved external
BLINKER : 1115 : SNN.LIB(WCTOMB) : '__IMP__WIDECHARTOMULTIBYTE 32' : unresolved
external
BLINKER : 1115 : SNN.LIB(SBRK) : '__IMP__VIRTUALALLOC 16' : unresolved external
BLINKER : 1115 : SNN.LIB(SBRK) : '__IMP__VIRTUALFREE 12' : unresolved external
BLINKER : 1115 : SNN.LIB(ISCTYPE) : '__IMP__GETSTRINGTYPEA 20' : unresolved
external
BLINKER : 1115 : SNN.LIB(LCAPI32) : '__IMP__COMPARESTRINGW 24' : unresolved
external
BLINKER : 1115 : SNN.LIB(LCAPI32) : '__IMP__COMPARESTRINGA 24' : unresolved
external
BLINKER : 1115 : SNN.LIB(LCAPI32) : '__IMP__GETLOCALEINFOW 16' : unresolved
external
BLINKER : 1115 : SNN.LIB(LCAPI32) : '__IMP__GETLOCALEINFOA 16' : unresolved
external
BLINKER : 1115 : SNN.LIB(LCAPI32) : '__IMP__GETSTRINGTYPEW 16' : unresolved
external
BLINKER : 1115 : SNN.LIB(LCAPI32) : '__IMP__LCMAPSTRINGW 24' : unresolved
external
BLINKER : 1115 : SNN.LIB(FIND) : '__IMP__FINDNEXTFILEA 8' : unresolved external
BLINKER : 1115 : SNN.LIB(FIND) : '__IMP__FINDCLOSE 4' : unresolved external
BLINKER : 1115 : SNN.LIB(FIND) : '__IMP__FILETIMETODOSDATETIME 12' : unresolved
external
BLINKER : 1115 : SNN.LIB(FIND) : '__IMP__FINDFIRSTFILEA 8' : unresolved external
BLINKER : 1115 : SNN.LIB(IO) : '__IMP__GETSTDHANDLE 4' : unresolved external
BLINKER : 1115 : SNN.LIB(IO) : '__IMP__CREATEFILEA 28' : unresolved external
BLINKER : 1115 : SNN.LIB(IO) : '__IMP__MOVEFILEA 8' : unresolved external
BLINKER : 1115 : SNN.LIB(IO) : '__IMP__DELETEFILEA 4' : unresolved external
BLINKER : 1115 : SNN.LIB(IO) : '__IMP__SETHANDLECOUNT 4' : unresolved external
BLINKER : 1115 : SNN.LIB(IO) : '__IMP__SETFILEPOINTER 16' : unresolved external
BLINKER : 1115 : SNN.LIB(IO) : '__IMP__GETFILEATTRIBUTESA 4' : unresolved
external
BLINKER : 1115 : SNN.LIB(SETARGV) : '__IMP__GETMODULEFILENAMEA 12' : unresolved
external
BLINKER : 1115 : SNN.LIB(W32FATER) : '__IMP__WRITECONSOLEA 20' : unresolved
external
BLINKER : 1115 : SNN.LIB(W32FATER) : '__IMP__MESSAGEBOXA 16' : unresolved
external
BLINKER : 1115 : SNN.LIB(CONSTART) : '__IMP__GETMODULEHANDLEA 4' : unresolved
external
BLINKER : 1115 : SNN.LIB(CONSTART) : '__IMP__GETCOMMANDLINEA 0' : unresolved
external

BLINKER : 0 Warning error(s), 42 Fatal error(s)

RS.EXE (not created) (0.1 seconds)

e:\eee\ramspeed\qq>

-----------------------Tlink------------------------

e:\eee\ramspeed\qq>ilink32 -Lc:\progra~1\dm\lib\
rs.obj,,,user32.lib+kernel32.lib
Turbo Incremental Link 5.00 Copyright (c) 1997, 2000 Borland

Warning: Unable to perform incremental link - performing full link...

Fatal: Unable to open file 'SNN.OBJ'

e:\eee\ramspeed\qq>ilink32 -Lc:\progra~1\dm\lib
rs.obj,,,snn.lib+user32.lib+kernel32.lib
Turbo Incremental Link 5.00 Copyright (c) 1997, 2000 Borland

Fatal: Error detected (IMP1807)

Fatal: Access violation.  Link terminated.

Warning: Unable to perform incremental link - performing full link...

Fatal: Error detected (IMP1807)

Fatal: Access violation.  Link terminated.


e:\eee\ramspeed\qq>

Jan Knepper <jan smartsoft.cc> writes:

What about the DM Linker???

It seems to me like you have to throw an option for blinker to prevent it from
capitalizing the function names, that might fix one problem.

Jan



Federico wrote:

 In article <ai9qud$27he$1 digitaldaemon.com>, Walter says...
What problems with snn?

 Please, find below outputs of Alink, Blinker, Tlink. The latter gives no
 information, but the problem happens as soon as SNN.LIB is accessed.

 Moreover, if the big arrays at file scope are not declared static, both
 alink and blinker complains on the .obj generated from my source code.

 Maybe I'm stuck in a stupid problem, I apologize but I'm not an expert in
 linking under Win32.

 Federico

 -----------------Alink------------------------------

 e:\eee\ramspeed\qq>alink -oPE -subsys con rs.obj USER32.LIB KERNEL32.LIB
 ALINK v1.6 (C) Copyright 1998-9 Anthony A.J. Williams.

 All Rights Reserved

 Loading file rs.obj

 Loading file USER32.LIB

 Loading file KERNEL32.LIB

 Loading file SNN.lib

 Error in file at 000000EE - unknown object module record type BC

 name count = 19

 seg count = 8

 extcount=10

 grpcount=2

 comcount=4

 fixcount=18

 impcount=0

 expcount=0

 e:\eee\ramspeed\qq>

 --------------------Blinker-----------------------------

 e:\eee\ramspeed\qq>blinker file rs.obj lib user32.lib lib kernel32.lib

 BLINKER : 1115 : SNN.LIB(BUILDENV) : '__IMP__MULTIBYTETOWIDECHAR 24' :
 unresolved external
 BLINKER : 1115 : SNN.LIB(CLOCK) : '__IMP__GETTICKCOUNT 0' : unresolved external
 BLINKER : 1115 : SNN.LIB(GETENV) : '__IMP__GETENVIRONMENTVARIABLEA 12' :
 unresolved external
 BLINKER : 1115 : SNN.LIB(ISATTY) : '__IMP__GETFILETYPE 4' : unresolved external
 BLINKER : 1115 : SNN.LIB(LOCTIME) : '__IMP__GETTIMEZONEINFORMATION 4' :
 unresolved external
 BLINKER : 1115 : SNN.LIB(SEMLOCK) : '__IMP__CLOSEHANDLE 4' : unresolved
external
 BLINKER : 1115 : SNN.LIB(SEMLOCK) : '__IMP__CREATESEMAPHOREA 16' : unresolved
 external
 BLINKER : 1115 : SNN.LIB(SEMLOCK) : '__IMP__WAITFORSINGLEOBJECT 8' : unresolved
 external
 BLINKER : 1115 : SNN.LIB(SEMLOCK) : '__IMP__RELEASESEMAPHORE 12' : unresolved
 external
 BLINKER : 1115 : SNN.LIB(SETMBCP) : '__IMP__GETACP 0' : unresolved external
 BLINKER : 1115 : SNN.LIB(SETMBCP) : '__IMP__GETOEMCP 0' : unresolved external
 BLINKER : 1115 : SNN.LIB(SETMBCP) : '__IMP__GETCPINFO 8' : unresolved external
 BLINKER : 1115 : SNN.LIB(SETNTERR) : '__IMP__GETLASTERROR 0' : unresolved
 external
 BLINKER : 1115 : SNN.LIB(TIME) : '__IMP__GETLOCALTIME 4' : unresolved external
 BLINKER : 1115 : SNN.LIB(TOLOWER) : '__IMP__LCMAPSTRINGA 24' : unresolved
 external
 BLINKER : 1115 : SNN.LIB(XCFILTER) : '__IMP__UNHANDLEDEXCEPTIONFILTER 4' :
 unresolved external
 BLINKER : 1115 : SNN.LIB(WCTOMB) : '__IMP__WIDECHARTOMULTIBYTE 32' : unresolved
 external
 BLINKER : 1115 : SNN.LIB(SBRK) : '__IMP__VIRTUALALLOC 16' : unresolved external
 BLINKER : 1115 : SNN.LIB(SBRK) : '__IMP__VIRTUALFREE 12' : unresolved external
 BLINKER : 1115 : SNN.LIB(ISCTYPE) : '__IMP__GETSTRINGTYPEA 20' : unresolved
 external
 BLINKER : 1115 : SNN.LIB(LCAPI32) : '__IMP__COMPARESTRINGW 24' : unresolved
 external
 BLINKER : 1115 : SNN.LIB(LCAPI32) : '__IMP__COMPARESTRINGA 24' : unresolved
 external
 BLINKER : 1115 : SNN.LIB(LCAPI32) : '__IMP__GETLOCALEINFOW 16' : unresolved
 external
 BLINKER : 1115 : SNN.LIB(LCAPI32) : '__IMP__GETLOCALEINFOA 16' : unresolved
 external
 BLINKER : 1115 : SNN.LIB(LCAPI32) : '__IMP__GETSTRINGTYPEW 16' : unresolved
 external
 BLINKER : 1115 : SNN.LIB(LCAPI32) : '__IMP__LCMAPSTRINGW 24' : unresolved
 external
 BLINKER : 1115 : SNN.LIB(FIND) : '__IMP__FINDNEXTFILEA 8' : unresolved external
 BLINKER : 1115 : SNN.LIB(FIND) : '__IMP__FINDCLOSE 4' : unresolved external
 BLINKER : 1115 : SNN.LIB(FIND) : '__IMP__FILETIMETODOSDATETIME 12' : unresolved
 external
 BLINKER : 1115 : SNN.LIB(FIND) : '__IMP__FINDFIRSTFILEA 8' : unresolved
external
 BLINKER : 1115 : SNN.LIB(IO) : '__IMP__GETSTDHANDLE 4' : unresolved external
 BLINKER : 1115 : SNN.LIB(IO) : '__IMP__CREATEFILEA 28' : unresolved external
 BLINKER : 1115 : SNN.LIB(IO) : '__IMP__MOVEFILEA 8' : unresolved external
 BLINKER : 1115 : SNN.LIB(IO) : '__IMP__DELETEFILEA 4' : unresolved external
 BLINKER : 1115 : SNN.LIB(IO) : '__IMP__SETHANDLECOUNT 4' : unresolved external
 BLINKER : 1115 : SNN.LIB(IO) : '__IMP__SETFILEPOINTER 16' : unresolved external
 BLINKER : 1115 : SNN.LIB(IO) : '__IMP__GETFILEATTRIBUTESA 4' : unresolved
 external
 BLINKER : 1115 : SNN.LIB(SETARGV) : '__IMP__GETMODULEFILENAMEA 12' : unresolved
 external
 BLINKER : 1115 : SNN.LIB(W32FATER) : '__IMP__WRITECONSOLEA 20' : unresolved
 external
 BLINKER : 1115 : SNN.LIB(W32FATER) : '__IMP__MESSAGEBOXA 16' : unresolved
 external
 BLINKER : 1115 : SNN.LIB(CONSTART) : '__IMP__GETMODULEHANDLEA 4' : unresolved
 external
 BLINKER : 1115 : SNN.LIB(CONSTART) : '__IMP__GETCOMMANDLINEA 0' : unresolved
 external

 BLINKER : 0 Warning error(s), 42 Fatal error(s)

 RS.EXE (not created) (0.1 seconds)

 e:\eee\ramspeed\qq>

 -----------------------Tlink------------------------

 e:\eee\ramspeed\qq>ilink32 -Lc:\progra~1\dm\lib\
 rs.obj,,,user32.lib+kernel32.lib
 Turbo Incremental Link 5.00 Copyright (c) 1997, 2000 Borland

 Warning: Unable to perform incremental link - performing full link...

 Fatal: Unable to open file 'SNN.OBJ'

 e:\eee\ramspeed\qq>ilink32 -Lc:\progra~1\dm\lib
 rs.obj,,,snn.lib+user32.lib+kernel32.lib
 Turbo Incremental Link 5.00 Copyright (c) 1997, 2000 Borland

 Fatal: Error detected (IMP1807)

 Fatal: Access violation.  Link terminated.

 Warning: Unable to perform incremental link - performing full link...

 Fatal: Error detected (IMP1807)

 Fatal: Access violation.  Link terminated.

 e:\eee\ramspeed\qq>

Federico <Federico_member pathlink.com> writes:

In article <3D49ACB6.963DE854 smartsoft.cc>, Jan Knepper says...

What about the DM Linker???

Look at the other messages, it fails.

It seems to me like you have to throw an option for blinker to prevent it from
capitalizing the function names, that might fix one problem.

Thanks Jan, you are obviously write (and I'm a stupid :-( ). Your message
prompted me to better study the horrible on line documentation of Blinker
DEMO version, and I happened to write the correct script and definiton files
to produce a Win32 executables, just to discover that:

----------------------------blinker ouput---------------------------
e:\eee\ramspeed\qq>blinker  blrs
__   __

(®¯) (®¯)       BLINKER DOS Extender and Windows Linker 5.10



___                 Blink and you'll miss it !!


Copyright (c) Assembler Software Manufacturers, Inc. 1990-99

All Rights Reserved * Demo * www.blinkinc.com 1-804-784-2347


BLINKER : 1000 : This demo version will not create 32 bit Windows programs
---------------------------------------------------------------------

Maybe that explains Blinker complaints.

Federico

Jan Knepper <jan smartsoft.cc> writes:

What about the DM Linker???

 Look at the other messages, it fails.

I meant, the messages the linker gives you. You give a report for all the other
linkers I can not help you with.

It seems to me like you have to throw an option for blinker to prevent it from
capitalizing the function names, that might fix one problem.

 Thanks Jan, you are obviously write (and I'm a stupid :-( ). Your message
 prompted me to better study the horrible on line documentation of Blinker
 DEMO version, and I happened to write the correct script and definiton files
 to produce a Win32 executables, just to discover that: [ ... ]

Well, I guess that answers your question about blinker...

Jan

Federico <Federico_member pathlink.com> writes:

In article <3D4B044D.97C0BB2E smartsoft.cc>, Jan Knepper says...
What about the DM Linker???

 Look at the other messages, it fails.

I meant, the messages the linker gives you. You give a report for all the other
linkers I can not help you with.

A dialog box appears. The title is:
"Unexpected OPTLINK termination at EIP=0043E29C"

The body contains a red circle with a white X in it, and says:
"EAX=00000000 EBX=0046C7A0 ECX=00001000 EDX=000008DF
ESI=00000000 EDI=00004056 EBP=006BFF78 ESP=006BFE10
First=00430000"

Federico

Jan Knepper <jan smartsoft.cc> writes:

Federico wrote:

 In article <3D4B044D.97C0BB2E smartsoft.cc>, Jan Knepper says...
What about the DM Linker???

 Look at the other messages, it fails.

I meant, the messages the linker gives you. You give a report for all the other
linkers I can not help you with.

 A dialog box appears. The title is:
 "Unexpected OPTLINK termination at EIP=0043E29C"

 The body contains a red circle with a white X in it, and says:
 "EAX=00000000 EBX=0046C7A0 ECX=00001000 EDX=000008DF
 ESI=00000000 EDI=00004056 EBP=006BFF78 ESP=006BFE10
 First=00430000"

<g>
That's all?!

Jan

Federico <Federico_member pathlink.com> writes:

In article <3D4C0358.45137DD6 smartsoft.cc>, Jan Knepper says...
<g>
That's all?!

Yes. I'm not used to hide information to people helping me... ;-)

Walter said it is a problem in OPTLINK he cannot fix.
BTW, I'm running WinME, but I had the same problem with different versions and
on different systems.

Federico

"Walter" <walter digitalmars.com> writes:

1) Record type BC is a COMDAT record - perfectly valid. Bug in Alink.
2) These externs should be defined in whatever operating system .lib file
you're linking with - not a problem with SNN.LIB.
3) Identifying the problem as being with SNN.OBJ (when the name of the file
is SNN.LIB) indicates a bug in ilink32, not SNN.
4) Access violations when ilink32 is run is a bug in the linker, not SNN.


"Federico" <Federico_member pathlink.com> wrote in message
news:aic9qt$d1o$1 digitaldaemon.com...
 In article <ai9qud$27he$1 digitaldaemon.com>, Walter says...
What problems with snn?

 Please, find below outputs of Alink, Blinker, Tlink. The latter gives no
 information, but the problem happens as soon as SNN.LIB is accessed.

 Moreover, if the big arrays at file scope are not declared static, both
 alink and blinker complains on the .obj generated from my source code.

 Maybe I'm stuck in a stupid problem, I apologize but I'm not an expert in
 linking under Win32.

 Federico


 -----------------Alink------------------------------

 e:\eee\ramspeed\qq>alink -oPE -subsys con rs.obj USER32.LIB KERNEL32.LIB
 ALINK v1.6 (C) Copyright 1998-9 Anthony A.J. Williams.

 All Rights Reserved


 Loading file rs.obj

 Loading file USER32.LIB

 Loading file KERNEL32.LIB

 Loading file SNN.lib


 Error in file at 000000EE - unknown object module record type BC

 name count = 19

 seg count = 8

 extcount=10

 grpcount=2

 comcount=4

 fixcount=18

 impcount=0

 expcount=0


 e:\eee\ramspeed\qq>

 --------------------Blinker-----------------------------

 e:\eee\ramspeed\qq>blinker file rs.obj lib user32.lib lib kernel32.lib

 BLINKER : 1115 : SNN.LIB(BUILDENV) : '__IMP__MULTIBYTETOWIDECHAR 24' :
 unresolved external
 BLINKER : 1115 : SNN.LIB(CLOCK) : '__IMP__GETTICKCOUNT 0' : unresolved

external
 BLINKER : 1115 : SNN.LIB(GETENV) : '__IMP__GETENVIRONMENTVARIABLEA 12' :
 unresolved external
 BLINKER : 1115 : SNN.LIB(ISATTY) : '__IMP__GETFILETYPE 4' : unresolved

external
 BLINKER : 1115 : SNN.LIB(LOCTIME) : '__IMP__GETTIMEZONEINFORMATION 4' :
 unresolved external
 BLINKER : 1115 : SNN.LIB(SEMLOCK) : '__IMP__CLOSEHANDLE 4' : unresolved

external
 BLINKER : 1115 : SNN.LIB(SEMLOCK) : '__IMP__CREATESEMAPHOREA 16' :

unresolved
 external
 BLINKER : 1115 : SNN.LIB(SEMLOCK) : '__IMP__WAITFORSINGLEOBJECT 8' :

unresolved
 external
 BLINKER : 1115 : SNN.LIB(SEMLOCK) : '__IMP__RELEASESEMAPHORE 12' :

unresolved
 external
 BLINKER : 1115 : SNN.LIB(SETMBCP) : '__IMP__GETACP 0' : unresolved

external
 BLINKER : 1115 : SNN.LIB(SETMBCP) : '__IMP__GETOEMCP 0' : unresolved

external
 BLINKER : 1115 : SNN.LIB(SETMBCP) : '__IMP__GETCPINFO 8' : unresolved

external
 BLINKER : 1115 : SNN.LIB(SETNTERR) : '__IMP__GETLASTERROR 0' : unresolved
 external
 BLINKER : 1115 : SNN.LIB(TIME) : '__IMP__GETLOCALTIME 4' : unresolved

external
 BLINKER : 1115 : SNN.LIB(TOLOWER) : '__IMP__LCMAPSTRINGA 24' : unresolved
 external
 BLINKER : 1115 : SNN.LIB(XCFILTER) : '__IMP__UNHANDLEDEXCEPTIONFILTER 4' :
 unresolved external
 BLINKER : 1115 : SNN.LIB(WCTOMB) : '__IMP__WIDECHARTOMULTIBYTE 32' :

unresolved
 external
 BLINKER : 1115 : SNN.LIB(SBRK) : '__IMP__VIRTUALALLOC 16' : unresolved

external
 BLINKER : 1115 : SNN.LIB(SBRK) : '__IMP__VIRTUALFREE 12' : unresolved

external
 BLINKER : 1115 : SNN.LIB(ISCTYPE) : '__IMP__GETSTRINGTYPEA 20' :

unresolved
 external
 BLINKER : 1115 : SNN.LIB(LCAPI32) : '__IMP__COMPARESTRINGW 24' :

unresolved
 external
 BLINKER : 1115 : SNN.LIB(LCAPI32) : '__IMP__COMPARESTRINGA 24' :

unresolved
 external
 BLINKER : 1115 : SNN.LIB(LCAPI32) : '__IMP__GETLOCALEINFOW 16' :

unresolved
 external
 BLINKER : 1115 : SNN.LIB(LCAPI32) : '__IMP__GETLOCALEINFOA 16' :

unresolved
 external
 BLINKER : 1115 : SNN.LIB(LCAPI32) : '__IMP__GETSTRINGTYPEW 16' :

unresolved
 external
 BLINKER : 1115 : SNN.LIB(LCAPI32) : '__IMP__LCMAPSTRINGW 24' : unresolved
 external
 BLINKER : 1115 : SNN.LIB(FIND) : '__IMP__FINDNEXTFILEA 8' : unresolved

external
 BLINKER : 1115 : SNN.LIB(FIND) : '__IMP__FINDCLOSE 4' : unresolved

external
 BLINKER : 1115 : SNN.LIB(FIND) : '__IMP__FILETIMETODOSDATETIME 12' :

unresolved
 external
 BLINKER : 1115 : SNN.LIB(FIND) : '__IMP__FINDFIRSTFILEA 8' : unresolved

external
 BLINKER : 1115 : SNN.LIB(IO) : '__IMP__GETSTDHANDLE 4' : unresolved

external
 BLINKER : 1115 : SNN.LIB(IO) : '__IMP__CREATEFILEA 28' : unresolved

external
 BLINKER : 1115 : SNN.LIB(IO) : '__IMP__MOVEFILEA 8' : unresolved external
 BLINKER : 1115 : SNN.LIB(IO) : '__IMP__DELETEFILEA 4' : unresolved

external
 BLINKER : 1115 : SNN.LIB(IO) : '__IMP__SETHANDLECOUNT 4' : unresolved

external
 BLINKER : 1115 : SNN.LIB(IO) : '__IMP__SETFILEPOINTER 16' : unresolved

external
 BLINKER : 1115 : SNN.LIB(IO) : '__IMP__GETFILEATTRIBUTESA 4' : unresolved
 external
 BLINKER : 1115 : SNN.LIB(SETARGV) : '__IMP__GETMODULEFILENAMEA 12' :

unresolved
 external
 BLINKER : 1115 : SNN.LIB(W32FATER) : '__IMP__WRITECONSOLEA 20' :

unresolved
 external
 BLINKER : 1115 : SNN.LIB(W32FATER) : '__IMP__MESSAGEBOXA 16' : unresolved
 external
 BLINKER : 1115 : SNN.LIB(CONSTART) : '__IMP__GETMODULEHANDLEA 4' :

unresolved
 external
 BLINKER : 1115 : SNN.LIB(CONSTART) : '__IMP__GETCOMMANDLINEA 0' :

unresolved
 external

 BLINKER : 0 Warning error(s), 42 Fatal error(s)

 RS.EXE (not created) (0.1 seconds)

 e:\eee\ramspeed\qq>

 -----------------------Tlink------------------------

 e:\eee\ramspeed\qq>ilink32 -Lc:\progra~1\dm\lib\
 rs.obj,,,user32.lib+kernel32.lib
 Turbo Incremental Link 5.00 Copyright (c) 1997, 2000 Borland

 Warning: Unable to perform incremental link - performing full link...

 Fatal: Unable to open file 'SNN.OBJ'

 e:\eee\ramspeed\qq>ilink32 -Lc:\progra~1\dm\lib
 rs.obj,,,snn.lib+user32.lib+kernel32.lib
 Turbo Incremental Link 5.00 Copyright (c) 1997, 2000 Borland

 Fatal: Error detected (IMP1807)

 Fatal: Access violation.  Link terminated.

 Warning: Unable to perform incremental link - performing full link...

 Fatal: Error detected (IMP1807)

 Fatal: Access violation.  Link terminated.


 e:\eee\ramspeed\qq>

Federico <Federico_member pathlink.com> writes:

I never meant the problem was IN snn.lib, I said:

 BTW. If I declare the big arrays 'static', Blinker does not complain anymore
 on the .obj, but has problems with SNN.LIB. The same happens with Borland
 Tlink.

I never said "SNN.LIB causes problems".
Federico

In article <aicch8$ggd$1 digitaldaemon.com>, Walter says...
1) Record type BC is a COMDAT record - perfectly valid. Bug in Alink.
2) These externs should be defined in whatever operating system .lib file
you're linking with - not a problem with SNN.LIB.
3) Identifying the problem as being with SNN.OBJ (when the name of the file
is SNN.LIB) indicates a bug in ilink32, not SNN.
4) Access violations when ilink32 is run is a bug in the linker, not SNN.

"Walter" <walter digitalmars.com> writes:

"Federico" <Federico_member pathlink.com> wrote in message
news:aieu3p$5ki$1 digitaldaemon.com...
 I never said "SNN.LIB causes problems".

You're right, you did not. I apologize.

Federico <Federico_member pathlink.com> writes:

Thanks to everyone who replied. Now that I solved the problem and I'm happy,I
have to make two comments:

1) the C standard and DMC docs state no limit on statically allocated areas.
I know form past interactiosn that the (wonderful!) linker is not in Walter's
control, but that problem is not nice at all;

2) before solving the problem, I anyhow ordered the DM CD: it's a wonderful
product, I love it more than I loved Symantec C++ in the past, it's worth
really more than 25 bucks!

Federico

Jan Knepper <jan smartsoft.cc> writes:

Federico wrote:

 2) before solving the problem, I anyhow ordered the DM CD: it's a wonderful
 product, I love it more than I loved Symantec C++ in the past, it's worth
 really more than 25 bucks!

I thought it is currently being sold for $50???

Jan

Federico <Federico_member pathlink.com> writes:

In article <3D4C0399.A6578C4C smartsoft.cc>, Jan Knepper says...
I thought it is currently being sold for $50???

http://www.digitalmars.com/shop.html says $25, PayPal charged me $25 + $6 (S&H).

I'd pay $50 as well, it's worth even more, however in those days of poor
compilers available for free, and of people satisfied with those, keeping the
price low could be a good approach.

Federico

Heinz Saathoff <hsaat bre.ipnet.de> writes:

Federico schrieb...
 I agree, but it fails as soon as the data declared at file scope exceed 40 MB
 total.
 As you maybe remember, we had this discussion a few months ago: DMC produces
 very fast executables, better then any competitor. However, if I use dynamic
 memory allocation, speed degrades by 30 percent. Still better than other
 compilers using dynamic allocation, but worse than other compiler on huge
static
 data.
 I'm trying to find a way out of the problem.

Why not allocating a big buffer on startup? It shouldn't make much 
difference in access time if you change

  char big_buffer[big_size];
  // doing something with big_buffer

to

  char *big_buffer = new char[big_size];  // or malloc
  // doing somthing with big_buffer


There is only one dynamic memory allocation in this case. The rest is 
nearly the same. Ok, the static buffer can be accessed with immediate 
addresses where the dynamic buffer pointer must first be loaded to a 
register and offset addressed. But I would expect that this isn't a big 
performance degradation.

- Heinz

Federico <Federico_member pathlink.com> writes:

In article <MPG.17b2f9f4a1b121699896ae news.digitalmars.com>, Heinz Saathoff
says...
Why not allocating a big buffer on startup? It shouldn't make much 
difference in access time if you change

Sorry, it does.
I was able to reduce the problem to a simple and stupid matrix multiplication
of two NxN matrices into a third one (the original code is different and
much more sophisticated, but exhibits the very same pathology).

Please, look at those measures (dynamic means that memory is allocated
once at the very beginning):

N      Allocation      DMC 8.28      BC++ 5.5

500       static          2.45 s        2.70 s

500      dynamic          3.17 s        3.67 s

2000       static       link failed!   141.13 s

2000      dynamic        166.31 s      196.81 s


Not only is DMC better than other compiler in most respects (support of
accurate floating point computation is wonderful), it produces faster
executables too.
However, performance degradations resulting from the switch from static
to dynamic memory allocation are significant (actually deadly for my
application).

nearly the same. Ok, the static buffer can be accessed with immediate 
addresses where the dynamic buffer pointer must first be loaded to a 
register and offset addressed. But I would expect that this isn't a big 
performance degradation.

No, this is not a problem. There is not much difference between accessing
memory locations in an array and accessing memory locations in a malloc'ed
area, not with a barely decent optimizing compiler. I can prove that easily,
it is even more evident on RISC architectures and the progressive
RISC-ification of x86 processors made this true for them as well.

I had not time to look in detail to DMC generated assembler, but the one for
the computational core is much more verbose and lenghty for the dinamic
allocation version than for the static one.
This usually comes from the optimizer being more aggressive with static data,
as it can more easily check at compile time for aliasing problems, something
cannot be done easily for dynamically allocated areas and pointers to them.

With FORTRAN 77, which always assume no aliasing (if you don't use EQUIVALENCE,
of course), there is no difference if you pass to a subroutine a static data
area or a malloc'ed one. In FORTRAN 9X, which supports pointers, aliasing can
be an issue, and performance can degrades.

In FORTRAN 9X you can fine control the effect using the TARGET attribute (if
the compiler takes advantage of the information), C99 introduced the restrict
keyword with similar purposes, and using it can pay a lot with some compilers.
To my surprise, using __restrict with DMC had no effect.

Federico

Jan Knepper <jan smartsoft.cc> writes:

Federico wrote:

 In article <MPG.17b2f9f4a1b121699896ae news.digitalmars.com>, Heinz Saathoff
 says...
Why not allocating a big buffer on startup? It shouldn't make much
difference in access time if you change

 Sorry, it does.
 I was able to reduce the problem to a simple and stupid matrix multiplication
 of two NxN matrices into a third one (the original code is different and
 much more sophisticated, but exhibits the very same pathology).

Could you give an example in 'code' of what you are doing and how static v.s.
dynamic makes such a difference?

Jan

Federico <Federico_member pathlink.com> writes:

In article <3D49AD77.20CE8DA7 smartsoft.cc>, Jan Knepper says...
Could you give an example in 'code' of what you are doing and how static v.s.
dynamic makes such a difference?

Well, today I had some time to look at generated assembler and I happened to
solve the problem: now my code meets the deadline for the compuattion.
The dynamic allocation version was a poor performer because the pointers to the
data areas were allocated at file scope. If they are local to the function
using them (temporary variables or formal parameters) the resulting code is
more compact and faster as well (the codes are reported below, too bad that
I'm not allowed to publish the real code, just a different one exhibiting the
same problem).
The files:
rs.c           the original one, arrays defined at file scope
rsdyn.c        pointers defined at file scope, malloc'ed memory areas
rsdynb.c       pointers defined at function scope, malloc'ed memory areas
rsdynf.c       pointers defined at file scope, malloc'ed memory areas passed
as parameters to a function implementing the core computation
rsdynbf.c      pointers defined at function scope, malloc'ed memory areas
passed as parameters to a function implementing the core
computation

The fact that defining pointers at function scope with respect to file scope
makes such a difference is still puzzling to me, I'm not accustomed to that
on RISC architectures and find it a little bit strange.

Federico

---------------------------------rs.c------------------------------------
#include <math.h>
#include <stdio.h>
#include <stdlib.h>
#include <time.h>

#define N 2000


float a[N][N];
float b[N][N];
float derpo[N][N];

int main() {
int i, j, k;
float *pa, *pb, *pc;
float tot = 0.0;
clock_t start, stop;

fprintf(stderr,"Using %f MB of memory.\n", 3.0*N*N*sizeof(float)/1048576.0);

start = clock();

for(pa=a[0], pb=b[0], i=0; i<(N*N); ++i)
*pa++ = rand(), *pb++ = rand();

for(i=0; i<N; ++i) {
for(j=0; j<N; ++j)
derpo[i][j] = 0.0;
for(k=0; k<N; ++k)
for(j=0; j<N; ++j)
derpo[i][j] += a[i][k]*b[k][j];
}

for(pc=derpo[0], i=0; i<(N*N); ++i)
tot += *pc++;

stop = clock();

fprintf(stderr,"Total: %f, time: %fs.\n", tot, (1.0*stop-start)/CLOCKS_PER_SEC);

return 0;
}
---------------------------------rsdyn.c---------------------------------
#include <math.h>
#include <stdio.h>
#include <stdlib.h>
#include <time.h>

#define N 2000


float (*a)[N];
float (*b)[N];
float (*derpo)[N];

int main() {
int i, j, k;
float *pa, *pb, *pc;
float tot = 0.0;
clock_t start, stop;

a = malloc(N*N*sizeof(float));
b = malloc(N*N*sizeof(float));
derpo = malloc(N*N*sizeof(float));

if (!(a && b && derpo)) {
fprintf(stderr, "Failed to allocate memory!\n");
exit(1);
}

fprintf(stderr,"Using %f MB of memory.\n", 3.0*N*N*sizeof(float)/1048576.0);

start = clock();

for(pa=a[0], pb=b[0], i=0; i<(N*N); ++i)
*pa++ = rand(), *pb++ = rand();

for(i=0; i<N; ++i) {
for(j=0; j<N; ++j)
derpo[i][j] = 0.0;
for(k=0; k<N; ++k)
for(j=0; j<N; ++j)
derpo[i][j] += a[i][k]*b[k][j];
}

for(pc=derpo[0], i=0; i<(N*N); ++i)
tot += *pc++;

stop = clock();

fprintf(stderr,"Total: %f, time: %fs.\n", tot, (1.0*stop-start)/CLOCKS_PER_SEC);

return 0;
}
---------------------------------rsdynb.c--------------------------------
#include <math.h>
#include <stdio.h>
#include <stdlib.h>
#include <time.h>

#define N 2000

int main() {
int i, j, k;

float (*a)[N];
float (*b)[N];
float (*derpo)[N];

float *pa, *pb, *pc;
float tot = 0.0;
clock_t start, stop;

a = malloc(N*N*sizeof(float));
b = malloc(N*N*sizeof(float));
derpo = malloc(N*N*sizeof(float));

if (!(a && b && derpo)) {
fprintf(stderr, "Failed to allocate memory!\n");
exit(1);
}

fprintf(stderr,"Using %f MB of memory.\n", 3.0*N*N*sizeof(float)/1048576.0);

start = clock();

for(pa=a[0], pb=b[0], i=0; i<(N*N); ++i)
*pa++ = rand(), *pb++ = rand();

for(i=0; i<N; ++i) {
for(j=0; j<N; ++j)
derpo[i][j] = 0.0;
for(k=0; k<N; ++k)
for(j=0; j<N; ++j)
derpo[i][j] += a[i][k]*b[k][j];
}

for(pc=derpo[0], i=0; i<(N*N); ++i)
tot += *pc++;

stop = clock();

fprintf(stderr,"Total: %f, time: %fs.\n", tot, (1.0*stop-start)/CLOCKS_PER_SEC);

return 0;
}
---------------------------------rsdynf.c--------------------------------
#include <math.h>
#include <stdio.h>
#include <stdlib.h>
#include <time.h>

#define N 2000

float (*a)[N];
float (*b)[N];
float (*derpo)[N];

void MatrixMul(float *A, float *B, float *C)
{  // multiply NxN matrix A*B resulting in C
int i, j, k;
float *b;

for(i=0; i<N; ++i, C+=N, A+=N) {
for(j=0; j<N; ++j)
C[j] = 0.0;
for(k=0, b=B; k<N; ++k, b+=N)
for(j=0; j<N; ++j)
C[j] += A[k]*b[j];
}

}


int main() {
int i, j, k;

float *pa, *pb, *pc;
float tot = 0.0;
clock_t start, stop;

a = malloc(N*N*sizeof(float));
b = malloc(N*N*sizeof(float));
derpo = malloc(N*N*sizeof(float));

if (!(a && b && derpo)) {
fprintf(stderr, "Failed to allocate memory!\n");
exit(1);
}

fprintf(stderr,"Using %f MB of memory.\n", 3.0*N*N*sizeof(float)/1048576.0);

start = clock();

for(pa=a[0], pb=b[0], i=0; i<(N*N); ++i)
*pa++ = rand(), *pb++ = rand();

MatrixMul((float *)a, (float *)b, (float *)derpo);

for(pc=derpo[0], i=0; i<(N*N); ++i)
tot += *pc++;

stop = clock();

fprintf(stderr,"Total: %f, time: %fs.\n", tot, (1.0*stop-start)/CLOCKS_PER_SEC);

return 0;
}
---------------------------------rsdynbf.c-------------------------------
#include <math.h>
#include <stdio.h>
#include <stdlib.h>
#include <time.h>

#define N 2000

void MatrixMul(float *A, float *B, float *C)
{  // multiply NxN matrix A*B resulting in C
int i, j, k;
float *b;

for(i=0; i<N; ++i, C+=N, A+=N) {
for(j=0; j<N; ++j)
C[j] = 0.0;
for(k=0, b=B; k<N; ++k, b+=N)
for(j=0; j<N; ++j)
C[j] += A[k]*b[j];
}

}


int main() {
int i, j, k;

float (*a)[N];
float (*b)[N];
float (*derpo)[N];

float *pa, *pb, *pc;
float tot = 0.0;
clock_t start, stop;

a = malloc(N*N*sizeof(float));
b = malloc(N*N*sizeof(float));
derpo = malloc(N*N*sizeof(float));

if (!(a && b && derpo)) {
fprintf(stderr, "Failed to allocate memory!\n");
exit(1);
}

fprintf(stderr,"Using %f MB of memory.\n", 3.0*N*N*sizeof(float)/1048576.0);

start = clock();

for(pa=a[0], pb=b[0], i=0; i<(N*N); ++i)
*pa++ = rand(), *pb++ = rand();

MatrixMul((float *)a, (float *)b, (float *)derpo);

for(pc=derpo[0], i=0; i<(N*N); ++i)
tot += *pc++;

stop = clock();

fprintf(stderr,"Total: %f, time: %fs.\n", tot, (1.0*stop-start)/CLOCKS_PER_SEC);

return 0;
}

Federico <Federico_member pathlink.com> writes:

In article <aigqms$2li6$1 digitaldaemon.com>, Federico says...
The files:
rs.c           the original one, arrays defined at file scope
rsdyn.c        pointers defined at file scope, malloc'ed memory areas
rsdynb.c       pointers defined at function scope, malloc'ed memory areas
rsdynf.c       pointers defined at file scope, malloc'ed memory areas passed
as parameters to a function implementing the core computation
rsdynbf.c      pointers defined at function scope, malloc'ed memory areas
passed as parameters to a function implementing the core
computation

Should someone be interested in, I forgot to mention compiler options. I used
-WA -o+all -ff

Federico

"Walter" <walter digitalmars.com> writes:

"Federico" <Federico_member pathlink.com> wrote in message
news:aic9al$ceu$1 digitaldaemon.com...
 In FORTRAN 9X you can fine control the effect using the TARGET attribute

(if
 the compiler takes advantage of the information), C99 introduced the

restrict
 keyword with similar purposes, and using it can pay a lot with some

compilers.
 To my surprise, using __restrict with DMC had no effect.

__restrict is simply ignored by DMC at the moment, which is allowable
behavior under C99. Nevertheless, it can be made use of to generate better
code, and a future version of DMC may do this.

Heinz Saathoff <hsaat bre.ipnet.de> writes:

Federico schrieb...
Why not allocating a big buffer on startup? It shouldn't make much 
difference in access time if you change

 
 Sorry, it does.
 I was able to reduce the problem to a simple and stupid matrix multiplication
 of two NxN matrices into a third one (the original code is different and
 much more sophisticated, but exhibits the very same pathology).

Do you do the matrix multiply in a function taking the matrices as 
'pointer to double' parameters like

   void MatrixMul(int N, double *A, double *B, double *C)
   {  // multiply NxN matrix A*B resulting in C 
   }

and call this with static allocated matrix in one case and dynamic one 
in the other case? This should not result in different performance as 
the generated code for MatrixMul would be the same. 
What would make a difference is simulating a 2D array with pointers as 
in

  double **A = new double*[N];
  for(int i=0; i<N; ++i) A[i] = new double[N];
  // same for B and C

and writing MatrixMul as

  void MatrixMul(int N, double **A, double **B, double **C)
  { // do the multiply
  }

This would indeed involve a overhead.

Another point could be different alignment of static array and dynamic 
allocated array. We had this discussion in the group that 8-byte aligned 
doubles are faster than 4-byte aligned doubles.


 I had not time to look in detail to DMC generated assembler, but the one for
 the computational core is much more verbose and lenghty for the dinamic
 allocation version than for the static one.
 This usually comes from the optimizer being more aggressive with static data,
 as it can more easily check at compile time for aliasing problems, something
 cannot be done easily for dynamically allocated areas and pointers to them.

IMO this can only happen when the routines directly access the global 
static buffer and not taking the arguments as parameters.

But, as Jan said, a small example code for static and dynamic version 
may help to clarify where the difference is.

- Heinz 

Federico <Federico_member pathlink.com> writes:

In article <MPG.17b457435bb5f6899896af news.digitalmars.com>, Heinz Saathoff
says...
Do you do the matrix multiply in a function taking the matrices as 
'pointer to double' parameters like

   void MatrixMul(int N, double *A, double *B, double *C)

Look at the codes I sent, please.

What would make a difference is simulating a 2D array with pointers as 
in

  double **A = new double*[N];

I'm not so stupid or ignorant to do that.

Another point could be different alignment of static array and dynamic 
allocated array. We had this discussion in the group that 8-byte aligned 
doubles are faster than 4-byte aligned doubles.

That's obvious stuff I dind't mentioned, I'm using floats.

IMO this can only happen when the routines directly access the global 
static buffer and not taking the arguments as parameters.

This is the same conclusion I came to looking at assembly language compiler
output.
However, this is only true for DMC, try with BC++, or a compiler for RISC
architectures anf you'll find that this makes no difference (as it should be...)

Federico