Gpc June 1997

gpc@gnu.de

25 participants
172 discussions

Re: OOP
by The African Chief 11 Jun '97

11 Jun '97

On Tue, 10 Jun 1997 15:04:55 +0200 Frank Heckenbach <heckenb(a)mi.uni-erlangen.de> wrote: > >The African Chief wrote: > >> >As Pierre said: string comparison are less efficient than integer compares, >> >and generally I think *internal* things (i.e. things that must only be read >> >by computers, not by humans) should use integers rather than strings when >> >there's no real need for strings. Resource files, AFAIK, are binary files, >> >anyway, so what good would it be to have some strings scattered in them? >> >> Resource files (at least Windows resource files) can also hold strings in >> string tables. Most Windows programmers cannot do without these string >> tables. How would you represent the strings with integers? You need to >> store the actual strings in the resource file. > >That's something different! These strings (if I understood string tables >correctly) are actually to be read (or typed) by humans. Correct. > There's no question >that they must be stored as strings (unless, of course, one intentionally >wants to encrypt and/or compress them to make them unreadable in the binary). True. >But e.g. the IDs of the strings would be numerical (just as they are in >WinAPI/OWL, AFAIR). True. >> Would there be a problem if two or more programmers (unknown to each other) >> just happened to choose the same ID? [...] >If different programmers really happened to choose the same ID, it could >matter if they wanted to combine their sources (however, the compiler would >(should) notice this, so they could change the IDs, and they'd just have to >recompile everything once), or when they exchanged or shared data files >with these IDs in them (which, however, seems strange unless the sources >are combined, too). Suppose they put their code in dynamic linked libraries (meaning that any application that can load functions from such libraries can use the code) ? Best regards, The Chief Dr Abimbola A. Olowofoyeku (The African Chief, and the Great Elephant) Author of: Chief's Installer Pro v3.60 for Win16 and Win32. Homepage: http://ourworld.compuserve.com/homepages/African_Chief/ E-mail: laa12(a)cc.keele.ac.uk

1 0

Re: Enumerated types
by Frank Heckenbach 10 Jun '97

10 Jun '97

Phil Nelson wrote: > Another problem ... it will make pred() and succ() harder if they must > do succ(Greater) => Strange and pred(Strange) => Greater. I think setting > the initial value would be reasonable, but not allowing a jump in the values. Another possibility would be to let succ (and inc) just increase the ordinal value by 1, then test (with the generic range checking procedure) if it's a valid ordinal value. I'm not sure if succ/inc are supposed to work this way or the other, what does the standard say? -- Frank Heckenbach, Erlangen, Germany heckenb(a)mi.uni-erlangen.de Turbo Pascal: http://www.mi.uni-erlangen.de/~heckenb/programs.htm Internet links: http://www.mi.uni-erlangen.de/~heckenb/links.htm

1 0

Re: OOP
by Frank Heckenbach 10 Jun '97

10 Jun '97

The African Chief wrote: > >As Pierre said: string comparison are less efficient than integer compares, > >and generally I think *internal* things (i.e. things that must only be read > >by computers, not by humans) should use integers rather than strings when > >there's no real need for strings. Resource files, AFAIK, are binary files, > >anyway, so what good would it be to have some strings scattered in them? > > Resource files (at least Windows resource files) can also hold strings in > string tables. Most Windows programmers cannot do without these string > tables. How would you represent the strings with integers? You need to > store the actual strings in the resource file. That's something different! These strings (if I understood string tables correctly) are actually to be read (or typed) by humans. There's no question that they must be stored as strings (unless, of course, one intentionally wants to encrypt and/or compress them to make them unreadable in the binary). But e.g. the IDs of the strings would be numerical (just as they are in WinAPI/OWL, AFAIR). > Would there be a problem if two or more programmers (unknown to each other) > just happened to choose the same ID? As I described elsewhere, one could use some bits of the ID as a "programmer ID" and make it at least very improbable that ever two programmers would choose the same bits. Unless this would happen, all IDs by all programmers would automatically be different. > I am just asking, because I am not sure > whether this will affect anything else or not (it may very well not affect anything). If different programmers really happened to choose the same ID, it could matter if they wanted to combine their sources (however, the compiler would (should) notice this, so they could change the IDs, and they'd just have to recompile everything once), or when they exchanged or shared data files with these IDs in them (which, however, seems strange unless the sources are combined, too). -- Frank Heckenbach, Erlangen, Germany heckenb(a)mi.uni-erlangen.de Turbo Pascal: http://www.mi.uni-erlangen.de/~heckenb/programs.htm Internet links: http://www.mi.uni-erlangen.de/~heckenb/links.htm

1 0

Re: Inline Assembler Problems
by PredatorZeta 10 Jun '97

10 Jun '97

> A description of GPC's inline assembler was recently posted to this list > by somebody who calls himself "Predator Zeta". Hello boyz!! Do you want call me with my real name? :)) Well, is "Dario Angelo Anzani". Predator came from some Quake deadmatch that I did. ZzzZ stay for sleeper...8-))) >"StOp GrInNiNg AnD dRoP yOuR lInNeN...", so maybe you did not identify it >as something about assembler. ;-) In case you have lost that mail, you can I reveal the mystery: StOp GrInNiNg AnD dRoP yOuR lInNeN is a quote from an AC/DC song entitled "Shake a Leg". [album: Back In Black] There are no way to identify it as something about assembler, but I really like it.8-))) But OK, in the next release, the subject will be something like this: "Please read this message because I wrote an assembler doc and if you read it you can learn more about assembler. " This would be nice for those that push cancel BEFORE read the contents of message 8-X Here there is the snag corrected: > Var > TheArray : Array[0..99] Of Integer; {32-bit} > Begin > Asm(" > ... Code ... > movl _Index, %esi (*you must double % if you use Ext. Asm*) > movl $_TheArray(,esi,4), %eax > ... Code ... > "); > End. Cya. PrZ. -- [<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<] | Codename: PrEdAtOr~Z; Sex: Male; Status: Free coder | * E-mail: predatorzeta(a)geocities.com * | URL: http://www.geocities.com/SiliconValley/Vista/6573 | [>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>]

1 0

Re: Enumerated types
by Jakob Heinemann 09 Jun '97

09 Jun '97

Phil Nelson wrote: > > >type TComparisonResult=(Less value -1, Equals, Greater, Strange value 10); > > > >i.e. Ord(Less)=-1, Ord(Equals)=0, Ord(Greater)=1, Ord(Strange)=10. > > Another problem ... it will make pred() and succ() harder if they must > do succ(Greater) => Strange and pred(Strange) => Greater. I think > setting the initial value would be reasonable, but not allowing a > jump in the values. Only allowing to set the initial offset would make this kind of fetaure useless. Implementing succ and pred functions using a simple table will not cause much trouble. Imagine this (for me very actual) problem: Type assembler_instructions = ( add_x, sub_y, mul_a_x) ; (* course more complex*) register_type = ( ax, bx, dx, bc, de, hl ); objectfile = record ai : assembler_instruction; p1, p2 : register_type; end; (* using some ada-style for making the example *) for assembler_instructions use ( add_x => 27, sub_y => 37, mul_a_x => 127); for register_type use ( ax => 12, bx => 22, dx => 32, bc => 01, de => 17, hl => 33); The ord-function will, assuming you order the register-names in a simple index only cause code to extract the real ord number from a table, i.e. ord_values : array (.enumeration_type.) of integer; (* the array keeping the values*) Just suggesting :) /Jakob :) mailto:Jakob.Heinemann@ericsson.com Ericsson Saab Avionics AB Linköping +46 13 284249

1 0

Re: Inline Assembler Problems
by Peter Gerwinski 09 Jun '97

09 Jun '97

According to Bernhard Tschirren: > > I've hit a little snag - I cant convert one type of Intel instruction to the > AT&T format. Take a look at the example below: > [...] > I couldnt figure out how to code the memory reference! A description of GPC's inline assembler was recently posted to this list by somebody who calls himself "Predator Zeta". (The subject was "StOp GrInNiNg AnD dRoP yOuR lInNeN...", so maybe you did not identify it as something about assembler. ;-) In case you have lost that mail, you can retrieve it in the GPC Mailing list archive at ftp://agnes.dida.physik.uni-essen.de/gnu-pascal/misc/gpc-list.1997.gz but you can also directly download the information from ftp://agnes.dida.physik.uni-essen.de/gnu-pascal/contrib/gpcasm.zip Your problem is discussed in chapter 3 (snippet below). Hope this helps, Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski(a)uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal [970510] - http://home.pages.de/~gnu-pascal/ [970125] 8< --------------------------------------------------------------------------- - 3. Memory addressing - Intel: SELECTOR : [BASE + INDEX*SCALE + DISPLACEMENT] AT&T: SELECTOR : DISPLACEMENT (BASE, INDEX, SCALE) If you are able to decypher the scheme above, you are perfectly able to master memory addressing. If you couldn't grasp the meaning, go on reading this short explanation: -The SELECTOR, for both formats, must be in the first position. The SELECTOR is expressed by means of a segment register(CS,DS,ES,SS,GS or FS) and CANNOT be an immediate value. If the selector used by the instruction is the default one(ES for StoS, SS for stack opcodes, DS/ES for MovS and DS for all the other one), you must omit both the register AND the colon. -The BASE value is, for example, the address of the first element of an array. In the Intel format it is placed as the first element into the square braces. Can be any one of the general purpose registers. -The INDEX value represents, to continue the previous example, the index of an array. BASE + INDEX gives the address in memory of the INDEXth element of the array starting at BASE. INDEX should also be any one of the general purpose registers and can be modified by a scaling factor... -The SCALE is an immediate value, choosen from 2, 4 or 8. When computing the address, INDEX is multiplied by SCALE, so that if our beloved array has elements made up of 2, 4 or 8 bytes, we can address them directly. -The DISPLACEMENT, at last, is a costant immediate value to be added to the final address. Usually, the most common addressing schemes involve BASE & DISPLACEMENT or BASE & INDEX: it's very unlikely to find all of them in one opcode. Mov EAX, DWord PTR FS:[EBX] <===> MovL %FS:(%EBX), %EAX Mov EDI, DWord PTR [ECX+EBX*2] <===> MovL (%ECX,%EBX,2), %EDI Mov EAX, DWord PTR [12345678h] <===> MovL 0x12345678, %EAX Mov EBX, DWord PTR GS:[EDX*2] <===> MovL %GS:(,%EDX,2), %EBX Mov EAX, DWord PTR [ECX+12345h] <===> MovL 0x12345(%ECX), %EAX Mov EDI, DWord PTR ES:[12345h] <===> MovL %ES:0x12345, %EDI Mov BX, Word PTR [_MyVar] <===> MovW (_MyVar), %BX Now for some highlights: Have a look at the third example: did you notice that in the AT&T syntax there is no dollar sign("$") preceding the value 0x12435678? That's perfectly right... if you look at the Intel syntax, you'll notice that it is a memory reference, not an immediate value: _In AT&T syntax, __EVERY__ immediate value WITHOUT a dollar sign preceding it is considered a memory reference_ Now, what about the forth example? Is that comma in the right place? The answer is YES, and it is very important to understand why. In this opcode the BASE is null. If we omitted the comma, the assembler would have guessed wrong and would have produced this: Mov EBX, DWord PTR GS:[EDX] <===> MovL %GS:(%EDX,2), %EBX The "2", mistaken for a scale, would have been discarded and EDX would have been the only register to be considered... a BAD error indeed! __ALWAYS__ put 3 commas between the braces, whatever you want to do!

1 0

Re: Enumerated types
by Frank Heckenbach 09 Jun '97

09 Jun '97

Peter Gerwinski wrote: > If everybody agrees that there should be an extension like this in GPC: > It's probably not so hard to implement. Suggestions for the syntax? > Objections against it? Why not? If it's not too much work to do. Could it be a problem if Ord(EnumVal)<0 ? I don't see any. Suggestion: type TComparisonResult=(Less value -1, Equals, Greater, Strange value 10); i.e. Ord(Less)=-1, Ord(Equals)=0, Ord(Greater)=1, Ord(Strange)=10. Disadvantage: Range checking will get more difficult. -- Frank Heckenbach, Erlangen, Germany heckenb(a)mi.uni-erlangen.de Turbo Pascal: http://www.mi.uni-erlangen.de/~heckenb/programs.htm Internet links: http://www.mi.uni-erlangen.de/~heckenb/links.htm

2 1

Re: Enumerated types
by Dr E. Buxbaum 09 Jun '97

09 Jun '97

> > Is it possible to specify the value of an enumerated type? I was trying > to > > port a C header file which did something like this: > > > > typedef enum hello_everybody { > > hello_error = -1, > > hello_first = 0, > > hello_second, > > hello_third > Can this be done with GPC? I am noot quite sure what you whant to do here. Under Pascal you can write: type Hello_Everybody = (Hello_error, Hello_first, Hello_second, Hello_third); and then use the ORD function to get their numerical value. ORD(Hello_Error) would be 0, ORD(Hello_First) 1 and so on. This would be an enumerated type. The other option would be a record (similar to a C struct): type Hello_Everybody = record Hello_Error, Hello_First, Hello_Second, Hello_Third : integer; end; In this case you could assign any integer value you like to any of the records field, while in the case of enumeration types the ORD-value is given by the order of definition. Hope that helps

2 1

Inline Assembler Problems
by Bernhard Tschirren 09 Jun '97

09 Jun '97

I am -trying- to port a program to GPC which uses some inline INTEL assembler. Its protected mode already so it should be easy to port... Well, that what I thought!!! I've hit a little snag - I cant convert one type of Intel instruction to the AT&T format. Take a look at the example below: Var TheArray : Array[0..99] Of LongInt; {32-bit} Begin Asm ... Code ... mov esi,Index mov eax,[TheArray+esi*4] { THIS is the offending opcode } ... Code ... End; End. I couldnt figure out how to code the memory reference! I cannot move the address of 'TheArray' into a register and use that because I dont have any available registers - the code is already written (not by me) and I DO NOT want to rewrite it. The current code copiles OK using TMT Pascal (ugh). So Im positive that its not an illegal memory reference. Could somebody please help me... Thanks ________________________ | _) | | e-mail: bernie(a)icenet.com.au |___)ernhard |_|schirren ptschirrenb(a)cc.curtin.edu.au www: www.geocities.com/CollegePark/Quad/8070/

1 0

CygWin32 and BPCompat
by The African Chief 09 Jun '97

09 Jun '97

Hi all, I have just succeeded over the weekend to compile SYSTEM.PAS, STRINGS.PAS, AND OBJECTS.PAS with CygWin. This has required some $IFDEFs and the addition of some new functions, just for CygWin - (so, AFAIK, the SYSTEM unit in BPCompat now compiles correctly under DJGPP, EMX, Linux, and CygWin - any other successes?) One thing which I am missing is the Win32 API in Pascal. Has anyone translated any of the CygWin32 C headers (esp. any Win32 API calls) to GPC? I would like to start a collection of these. Better still, is anyone willing to write a program that will parse a CygWin32 C headers and generate a GPC unit from it? Thanks. PS: I have found that many things are different under CygWin from the rest (e.g., the "stat" structure; the "errno", which is implemented as a macro); and many things which are in standard C headers are missing (e.g., strlwr(), strupr(), stricmp, etc.). Best regards, The Chief Dr Abimbola A. Olowofoyeku (The African Chief, and the Great Elephant) Author of: Chief's Installer Pro v3.60 for Win16 and Win32. Homepage: http://ourworld.compuserve.com/homepages/African_Chief/ E-mail: laa12(a)cc.keele.ac.uk

2 1

← Newer
1
...
9
10
11
12
13
14
15
...
18
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

1997

1996

1995

Gpc June 1997