TIP: Click on subject to list as thread! ANSI
echo: rberrypi
to: THE NATURAL PHILOSOPHER
from: JOHN RUMM
date: 2019-02-25 02:53:00
subject: Re: Rre: C is not a low l

On 24/02/2019 14:41, The Natural Philosopher wrote:
> On 24/02/2019 13:23, John Rumm wrote:

>>> That was the beauty of C. Years ago I was handed a ghastly hack of
>>> TurboPascal that needed to read a ram disk clock, and decide whetheer
>>> it was a FAT, File entry,  or a data block. Based on the first few
>>> bytes it might be almost anything.
>>>
>>> It proved quicker to write it in C where the data block could be read
>>> as an array of words, then depending on the value of some works, cast
>>> into an array of something else or a struccture...
>>>
>>> ...I spent an entire Sunday rewriting the whole program in C in a
>>> hotel room in Orleans...
>>
>> More a demonstration of a lack of experience with turbo pascal than
>> anything else. It will go low down and dirty if you want and give you
>> raw memory access, untyped pointers etc.
>>
>
> Never found out how to in the four hours I spent reading the manual

Yeah the manuals and built in help improved massively with later
versions, but were a bit sparse for the early versions.

There was s significant improvement with V4 IIRC (although the footprint
of the development system got *much* larger as well - V3 always amazed
me in that it included editor, compiler, linker, run time system etc all
in a single 50K executable!).

The neatest way to do that in TP was usually to create a "Packed"[1]
Variant Record data structure (like a union in C), with whatever fields
you want, and then have variants that treat the data in other ways -
something like a straight array of bytes. E.g:

var buffer [0..BuffSize] of byte ;

(or if you want it true C style just make the array a single byte long
and then index off the end of it - the compiler did not range check
unless you explicitly told it to)

[1] Using a packed record stopped the compiler padding the structure for
efficiency - say moving byte wide fields onto word boundaries)

Then when you create in instance of that record, you could map it to an
absolute memory location using the "absolute" keyword and specifying the
address.

There was also a predefined array called mem that simply mapped to memory.


>>> I love the fact that C will gently ask whether you really meant to
>>> treat an integer as a pointer to a string, and assume that oince you
>>> explicitly cast it so, you are clever enough to mean it.
>>>
>>> Only once has C let me down. In Assembler it is trivial to set up a
>>> call table - an arraye of address of subroutines that are called
>>> depending on an indexz value in te accumultaor. You take the base
>>> address of te aqrray into one regsiter, add the left shifted (on an 8
>>> bit mnicro) accumulator to it and call te address ponted to by that
>>> register.
>>
>> You mean like having an array of function pointers in C, and calling
>> the one at a certain index?
>>
>>> And array of pointers to functions was beyond my ability to specify,
>>> and the crude 6809 compiler to understand anyway.
>>
>> You can get lame compilers for pretty much any language IME!
>>
>>> So I wrote it as an 'if then... else if..' chain...
>>
>> No "switch" statement?
>>
> There was, but on a 6809 the code was simply horrible.
>
> I only had IIRC three possibles.
>   so     if then
>      else if
>      then else
>
> was pretty compact.

Yup gets the job done, and in code terms is not usually going to be any
worse that a switch.

--
Cheers,

John.

/=================================================================\
|          Internode Ltd -  http://www.internode.co.uk            |
|-----------------------------------------------------------------|
|        John Rumm - john(at)internode(dot)co(dot)uk              |
\=================================================================/

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | FidoUsenet Gateway (3:770/3)

SOURCE: echomail via QWK@docsplace.org

Email questions or comments to sysop@ipingthereforeiam.com
All parts of this website painstakingly hand-crafted in the U.S.A.!
IPTIA BBS/MUD/Terminal/Game Server List, © 2025 IPTIA Consulting™.