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

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

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

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

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

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

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

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>

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>