🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: comp.lang.modula2
Article #2777

TopSpeed and assembler

#2777
From: Marco van de Voort
Date: Wed, 30 Aug 1995 06:37
37 lines
2531 bytes
Hallo Martin!

Saturday August 26 1995 13:19, Martin Tom Brown wrote to All:

 >> [Background: we're talking here about the problem of including
 >> CPU-specific code in TopSpeed assembler.  The problem is: is there
 >> any mechanism in the TopSpeed project system that will let us use
 >> assembler conditionals that check which processor model the project
 >> is being compiled for; that is, is there any way to read back the
 >> current setting of the "optimize" pragma?]

I think I'll make a own central include file (like corelib.inc) for all projects, and add a directive there..... Ugly, but possible. This is not a problem, the problem is that the assembler simply lacks the mnemonics, and that you'll have to do it with db!.

I have some processorspecific code(386+), e.g in the detection of the processortype, and it's an ugly bunch of db's, and the disassembler can't handle it.

 MTB> Sadly you are right, I only had a quick look and thought I had
 MTB> found the right place to change. Oops!
 MTB> You could still define your own memory model to set _mycpu486

The *REAL* problem is the lack of mnemonics-opcode support of the assembler, does anybody found the lists of mnemonics opcodes in a textfile?

 >> I'm still convinced that there's something in the project system
 >> which allows the current value of "cpu" to be interrogated.
 >> I've tried some of the more obvious possibilities, but with no
 >> luck so far.

I doubt it, since the mnemonics aren't there. The disassembler only implements
the mnemonics/opcodes which are used by the compiler. The multiprocessor support of TopSpeed is a lot worse than I thought before I started to study it.

 MTB> I'd also be interested to know. It isn't so much of a problem for me.
 MTB> I can safely assume a minimum of 486 for almost all my own work,
 MTB> and I don't have to ensure backwards compatibility to 80x86, x<3.
 MTB> After all they would have a *really* tough time running OS/2!

My products are made for BBS-machines, and often these are 286's, sometimes even less. I could make 286+ as a prerequisite without much problems, but not more.

Marco  (M.W.T.J.v.d.Voort@stud.tue.nl or MarcoV@stack.urc.tue.nl)
Technical Details
Message-ID: <810267632.AA09453@puddle.fidonet.org>
Path: arc1-ca.pugleaf.net!usenet.eel.ufl.edu!psgrain!puddle!internet

Show Full Headers
Complete Article Headers
From: Marco.van.de.Voort@p18.f402.n284.z2.fidonet.org (Marco van de Voort)
Path: arc1-ca.pugleaf.net!usenet.eel.ufl.edu!psgrain!puddle!internet
Newsgroups: comp.lang.modula2
Subject: TopSpeed and assembler
Message-ID: <810267632.AA09453@puddle.fidonet.org>
Date: Tue, 29 Aug 1995 22:37:01 -0800
X-FTN-To: Martin Tom Brown