[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Potential modifications to COBOL relative to IEEE 754

Defining the two DFP encodings as explicitly different types is overkill
in my opinion, for the reasons I've stated repeatedly, but it should work,
because exported data must (presumably) already define their record field
types, and that definition now identifies the encoding as well.

I'm curious however how a programmer would write their code to run with
best performance on either BID or DPD platforms when that program deals
primarily wil local data (so the issue of import/export conversions does
not arise).  Will there be a means to declare the arithmetic to be the
platform-preferred STANDARD-DECIMAL, in a *portable* manner?  This could
be an enquiry function that describes the execution environment, or could
be handled by omission if each platform has a suitable default setting.

You see, unlike other arithmetic choices, this one is guaranteed to have
no effect at all on results, other than performance.

Perhaps COBOL could then take the additional step of making Endianness
explicit!  I've often wanted that capability in languages like C that are
used to write low-level programs, e.g. programs that access the PCI bus
on a Big-Endian machine, or programs that deal with network packets on
a Litte-Endian machine, WITHOUT the need to invoke explicit conversions,
as the compiler could take care of it automatically.  IBM's assemblers for
example have this capability for character encoding (but not for Endianness)
by having separate types for native, Ascii, or Ebcdic character literals.

(Sorry -- I was dreaming -- this domain is waaay outside the application
domain of COBOL.  I'm still curious however how COBOL implementations deal
with the issue of Endianness and character encodings in exported data.)

---Sent: 2011-02-26 17:38:39 UTC

754 | revision | FAQ | references | list archive